Repository navigation
Standardizing hardware access #1085
Description
stmhal has (undocumented) "stm" module which provides physical memory access. I'd like to propose to standardize it - under different name of course. As "stm" is not documented, moving mem* to a new module hopefully shouldn't be a big problem. I propose "physmem" as a module name. Alternatively, to save on modules, we can put it into uctypes (not sure that's ideal though).
Activity
dpgeorge commentedon Jan 24, 2015
I recall that you did not like so much the stm.mem* accessors. Did you have a suggestion to change how they work, or just want to move them as-is into physmem (or other module)?
Can uctypes be used to do the same thing, albeit in a slightly more round-about way? Note also that viper mode can access raw memory: p = ptr16(0x2000000); p[0] = 123
pfalcon commentedon Jan 27, 2015
Yep, I had, but I had to adjust - it's hard to argue it's easy to use and people use it, and I myself could use it for easy hack. So, just moving .mem* to physmem, leaving specific constants in "stm".
It can be, yes. But again, it's hard to argue against need to have something dead simple for quick hacks. (Just the same as uctypes can do much more than accessing untyped values in "raw memory").
OMG ;-)
dpgeorge commentedon Jan 28, 2015
Could use
micropythonmodule, but then that might end up being a ground for all ad-hoc functions.But I fear that
physmemis such a tiny module that it'll only even have these mem access functions.What about something that we can imagine having some broader functionality/scope in the future, something like
machinefor all low-level stuff?machine.mem8is very readable and understandable. Could haveport8etc methods for special port memory that is not memory mapped.dhylands commentedon Jan 29, 2015
Some other names to consider: mem and cpu (other than machine)
dhylands commentedon Jan 29, 2015
I think physmem is actually misleading, since from linux user space you can't actually access phymem, only virtual memory. You can use memmap to map some physical pages to a virtual memory space, but you still access using virtual addresses.
pfalcon commentedon Jan 29, 2015
And yet that's the intention of that module. So, Linux implementation will mmap /dev/mem underneath, etc.
pfalcon commentedon Jan 29, 2015
IMHO not, micropython is to control interpreter/implementation.
Yes, but it will be clean and pure. Other option mentioned is "uctypes". Light reasons against it is: 1) putting similar (competing) means into a single module; 2) as mentioned above, similarity is surface, actually 2 means deal with pretty different matters: hardware access (specifically, memory) vs foreign data structures access.
Well, with such formulation, it sounds like cleaned and purified refactor of "pyb". If we're ready for that, let's do it (but of course, carefully consider each piece added there).
dpgeorge commentedon Jan 30, 2015
I would prefer
machine. It would be a place for methods that are "board" agnostic. I guess only pyboards should have the pyb module.dpgeorge commentedon Feb 12, 2015
If we go with
machineI think we can put power-control modes in there:machine.sleep()ormachine.idle()- enter low power mode waiting for something to happen. On ST MCUs this is awfiinstruction. On machines that don't support this, it is a nop.machine.suspend()- halt the machine, waiting for a special wakeup event, and continue execution from this point after waking. On ST MCUs this is "stop mode".machine.standby()- halt the machine and go into a deep power saving mode. After waking up the machine resets.Also, we can add
hard_reset()to this module (perhaps renaming it to simplyresetorreboot).danicampora commentedon Feb 12, 2015
I think the
machinenaming is fine.I like
machine.sleep()better theidle():-), also, I like the idea of renaminghard_reset()to justreset()dpgeorge commentedon Feb 12, 2015
@danicampora does the CC3200 have low-power modes that these names/functions can be easily mapped to?
danicampora commentedon Feb 12, 2015
@dpgeorge Yes!
sleep()it'swfias wellsuspend()can be mapped to thedeep_sleep_modeof the CC3200standby()will be mapped tohibernate_modeActually, I would suggest to use something like
machine.hibernate()instead ofmachine.standby(), since I think it's more clear what the intention is.standbysounds more like whatsleep()oridle()would do (simply halting the processor).dpgeorge commentedon Feb 12, 2015
Ok. We should do a small survey of other MCUs to see if they can can map to these functions easily.
Does the CC3200 have backup RAM that does not get lost when waking from hibernate? Does hibernate reset the MCU upon waking? What events can trigger a wakeup from deep_sleep_mode and hibernate_mode?
danicampora commentedon Feb 12, 2015
Actually the CC3200 has a fourth low-power mode, I will explain them briefly:
Sleep(wfi)DeepSleep, which is likeSleepbut consumes a bit less. DMA does not work under deepsleep but it does under "normal" sleep.Low Power Deep Sleep. RAM retention is configurable, and the whole RAM can be retained if desired. SoC current consumption goes down to 700uA with WiFi enabled (and still connected to the AP). The chip can be configured to wake up and continue execution from any where. WiFi connectivity is not affected when entering and leaving this mode. GPIOs, timers, and also WiFi events can be used to wake up.Hibernate. No RAM retention, no WiFi enabled. After wake up, the machine resets. GPIOs and a special timer can be used as the wake up source.I was planning to use
Sleepformachine.sleep(),LowPowerDeepSleepformachine.suspend(), andhibernatefor the last mode.danicampora commentedon Feb 12, 2015
The ability to quickly wake up from
LowPowerDeepSleepwithout loosing the WiFi connection is one of the strong points of the CC3200.15 remaining items
dpgeorge commentedon Feb 22, 2015
This discussion regarding low-power modes is off-topic, but here is more fuel for the fire. Atmel's modes for the SAM3 family are:
That corresponds pretty much exactly to ST's sleep(=wfi/wfe), stop and standby modes.
danicampora commentedon Feb 22, 2015
Every manufacturer has its own naming, and some are less intuitive than others. I vote for:
By the way,
rebootsounds good to me.dpgeorge commentedon Feb 22, 2015
Atmel's AVR32 CPU has 1 generic "SLEEP" instruction that takes an argument to set the sleep mode. The different modes depend on the implementation of a given MCU. The UC3A has:
dpgeorge commentedon Feb 22, 2015
Fleescale Kinetis family has 11 low power modes:
"wait" looks to be similar to wfi/wfe. "stop" looks to be like a suspend. "VLPx" modes scale the clock down to 4MHz. "LLS" seems to be a low power version of "stop" where SRAM is still retained. "VLLSx" modes are like hibernate, in that the MCU goes through a reset upon waking, although some of them partially retain the SRAM.
dpgeorge commentedon Feb 22, 2015
I don't see how to provide a generic enough API in
machineto handle all these different cases. And it's not good enough to just provide 3 generic modes (eg idle, suspend, hibernate) and hope that an MCU can map them to something sensible. This is because in the case of low power you really want to squeeze the last microamp out, and therefore you need a full understanding of the MCU you're running on, as well as full and fine-grained control of all its low-power modes.Providing generic functions in
machinewill only lead us to provide additional MCU-specific functions in another module, in which case the genericmachineones will go unused.Could just have 1 single function
machine.sleep(...)with the arguments to this function unspecified, ie MCU-specific. But I don't think that's a good way to do it.pfalcon commentedon Feb 22, 2015
I don't see any problem with that, and would assume that's exactly what people using portable language like Python want.
danicampora commentedon Feb 22, 2015
I agree with that.
But...
Also with this other statement.
So, it is not easy to find the balance between a simple/friendly API, and one that gives full control over the hardware.
danicampora commentedon Feb 22, 2015
Even though most processors and SoCs support several low power modes, the great majority of applications only use 2 or 3, since handling sleep/wake cycles is tricky when the software becomes complex, specially when it involves stopping and re-initializing peripherals, preserving only a part of the RAM, and so on.
People using uPy most likely want a simple yet flexible API, so we need to find the balance to provide that. In my experience regarding low power modes, it boils down (most of the time) to 3 use cases:
It is our responsibility as developers of each port to select the low power modes of the platform that better map to those 3 uses cases, and implement them in a way that is transparent from the MicroPython perspective.
Just my 2 cents.
dpgeorge commentedon Feb 22, 2015
I understand the above points regarding relative simplicity, but it's been my/our experience that all the pyboard peripheral classes are moving towards exposing every little detail of the MCU. Eg I initially thought for pyb.Timer that simple counting and PWM would be enough, but now it has almost everything exposed including eg deadtime. And users are using the features. Other examples: I2C mem_read/write operations wanted memory width selection, SPI wanted DMA (and still wants callback when DMA is done), UART wants rx callbacks, CAN wants lots, DAC wants 12 bit support #1130, SPI wants callbacks #1124. All of these are useful things. Mome fit a generic model while others need very specific MCU support.
With low power modes, what happens when we need the wfe instruction? Where does it go? Do we make machine.idle take an option which selects the type of idle (wfi or wfe in Cortex-M case)? As I said above, I'm afraid we will soon outgrow the machine.{idle,suspend,deepsleep/hibernate} API and then it becomes unused legacy code.
Things like delay, udelay, millis, micros, elapsed_millis and elapsed_micros seem much more suited to generic machine functions.
danicampora commentedon Feb 22, 2015
Well, those are indeed very good points. I guess that if we want to expose every little detail of the MCU, we can not go for a generic API.
dpgeorge commentedon Apr 21, 2015
For reference to a real-life example where naming these things is important (pyb.wfi), see http://forum.micropython.org/viewtopic.php?f=2&t=656#p3758
danicampora commentedon Apr 22, 2015
I also commented on your recent commit that documents the RTC wake-up functionality. Maybe we should try to reach an agreement on a common generic API for all callbacks. I already implemented one version of this for the CC3200 that even allows the user to configure from which power mode(s) the interrupt can wake the device.
https://github.com/micropython/micropython/blob/master/cc3200/misc/mpcallback.c
It's quite flexible so I think we can work on top of that to make something that will suit stmhal and other platforms as well.
pfalcon commentedon May 6, 2015
"machine" module was introduced, with basic support for accessing (unprotected) physical memory. Per the discussion above, this ticket is kept open and renamed to "Standardizing hardware access".
vitiral commentedon Jun 13, 2015
just my 2c
I would have the
machinemodule do the general use cases (sleep, suspend, hibernate) and have specialized sleeping done in modules likepybor equivalent for the target platform. That way everyone has a standard way to do the standard things, but there is also room to expose more specialized features on different platforms.As for code like this:
Things like a RTC wakeups should be implemented in
machineor maybetime. Pin wakeup should be implemented in whatever module interfaces with pins (currentlypyb), and other wakeups should be implemented in their native modules (serial wakeup should be done in serial module, network/wifi in their respective modules, etc).pfalcon commentedon Jun 19, 2016
Done/further continued in #1430