mirror of
https://github.com/micropython/micropython.git
synced 2026-01-07 04:30:24 +01:00
Formatting
@@ -5,9 +5,9 @@ Discussion: https://github.com/micropython/micropython/issues/1430
|
||||
|
||||
The main aim is to provide Python modules/functions/classes that **abstract the hardware in a Pythonic way**.
|
||||
|
||||
The API should be Pythonic, obvious and relatively minimal. There should be a close mapping from functions to hardware and there should be as little magic as possible. The API should be as consistent across peripherals (Pin, UART, I2C, ADC, etc) as possible. There should usually be only one way to do something. A method name should do exactly what it says and no more (ie it shouldn't be heavily overloaded).
|
||||
The API should be Pythonic, obvious and relatively minimal. There should be a close mapping from functions to hardware and there should be as little magic as possible. The API should be as consistent across peripherals (Pin, UART, I2C, ADC, etc) as possible. There should usually be only one way to do something. A method name should do exactly what it says and no more (i.e. it shouldn't be heavily overloaded).
|
||||
|
||||
The existing pyb module already provides such abstraction but it is not as clean or consistent or general as it could be. The new hardware API will co-exist alongside the pyb module (only for stmhal port, eg pyboard) so that existing scripts still run. The pyb module will eventually be deprecated, but only after all functionality finds another home (which may be some time).
|
||||
The existing `pyb` module already provides such abstraction but it is not as clean or consistent or general as it could be. The new hardware API will co-exist alongside the `pyb` module (only for stmhal port, e.g. PyBoard) so that existing scripts still run. The pyb module will eventually be deprecated, but only after all functionality finds another home (which may be some time).
|
||||
|
||||
# Terminology
|
||||
|
||||
|
||||
Reference in New Issue
Block a user