I see machine but no umachine in the list of library module options in the mpconfigport.h.
Yet, from this: https://github.com/micropython/micropyt ... achine1.py
it seems like umachine should exist somewhere. Moreover, the mem8/mem16/mem32 functions that exist in umachine don't appear to exist in the machine library, and those are what I most want access to.
Am I confused, or have things changed, or is the umachine library module missing for some other reason?
[nRF52] Where is the umachines library module for the nRF52 boards? Does it even exist?
Re: [nRF52] Where is the umachines library module for the nRF52 boards? Does it even exist?
The u modules only exist for modules which have an equivalent in CPython.
For example, the utime module is a micro-implementation of the CPython time module.
See: http://docs.micropython.org/en/latest/l ... -libraries for a more detailed explanation.
Since there is no machine module in CPython, there is no need to create a umachine module.
See this post for details on how to add the mem8/16/32 accessors to the nrf machine module:
viewtopic.php?f=12&t=5372#p30947
For example, the utime module is a micro-implementation of the CPython time module.
See: http://docs.micropython.org/en/latest/l ... -libraries for a more detailed explanation.
Since there is no machine module in CPython, there is no need to create a umachine module.
See this post for details on how to add the mem8/16/32 accessors to the nrf machine module:
viewtopic.php?f=12&t=5372#p30947
Re: [nRF52] Where is the umachines library module for the nRF52 boards? Does it even exist?
Works like a charm! As proof, typing this at the REPL prompt will light up LED2 on the nRF52-DK board, just as it should:
Thanks!
Code: Select all
>>> machine.mem32[0x50000748]=0x703
>>> machine.mem32[0x50000504]=0x1A0060
Re: [nRF52] Where is the umachines library module for the nRF52 boards? Does it even exist?
Here's an example using the viper code emitter and pointers, to blink the LED1 on the nRF52840 DK.
It should work on all versions of Micropython, that have viper enabled.
Doesn't need machine.mem.
I tested it only on Circuitpython 4.0.0.
It should work on all versions of Micropython, that have viper enabled.
Doesn't need machine.mem.
I tested it only on Circuitpython 4.0.0.
Code: Select all
# Circuitpython 4.0.0
# Blink nRF52840 DK LED1 using direct register access
# nRF52840 Register addresses
# 0x50000000 GPIO P0 Base Address
# Offsets:
# DIRSET 0x518 Writing a 1 to a bit in that register sets the corresponding port pin as output
# OUTCLR 0x50C Writing a 1 to a bit in that register sets the corresponding port pin to 0
# OUTSET 0x508 Writing a 1 to a bit in that register sets the corresponding port pin to 1
# LED1: P0.13 LED1 is connected to P0.13, the corresponding bit is 1<<13 or 0x2000, or 0b10000000000000
from time import sleep
@micropython.viper # enables the viper code emitter, that has native data types and pointers
def led1_out():
ptr32(0x50000518)[0] = 0x2000 # write 0b10000000000000 to DIRSET register, setting P0.13 as output (LED1 will turn on, because output level is 0)
@micropython.viper # enables the viper code emitter
def led1_on():
ptr32(0x5000050C)[0] = 0x2000 # write 0b10000000000000 to OUTCLR register, setting P0.13 as 0 (LED 1 will turn on)
@micropython.viper # enables the viper code emitter
def led1_off():
ptr32(0x50000508)[0] = 0x2000 # write 0b10000000000000 to OUTSET register, setting P0.13 as 1 (LED 1 will turn off)
led1_out()
while True:
led1_on()
sleep(1)
led1_off()
sleep(1)
Re: [nRF52] Where is the umachines library module for the nRF52 boards? Does it even exist?
Oh, and BTW:
Viper seems to treat everything as signed integers by default, even constants.
So if you want to use constants bigger than 0x7fffffff, you have to enclose them in an uint().
Example:
p.s.: Short version for the REPL to switch LED 1 on:
I like that @micropython.viper. Sounds creepy and dangerous. Uuuhhh. Only for experts, don't try this at home, kids.
Viper seems to treat everything as signed integers by default, even constants.
So if you want to use constants bigger than 0x7fffffff, you have to enclose them in an uint().
Example:
Code: Select all
ptr32(0x5000050C)[0] = uint(0x80000000) # turn P0_31 on
Code: Select all
@micropython.viper
def led1_out():
ptr32(0x50000518)[0] = 0x2000
led1_out()
Re: [nRF52] Where is the umachines library module for the nRF52 boards? Does it even exist?
Kak,
Nice work! Thanks for posting it.
Since you mention it, what exactly is the difference between CircuitPython and MicroPython? How do you like it? What do you see as its benefits as well as downsides, if any?
Since this thread has already fulfilled its original purpose, I don't at all mind straying far from the original post. So, feel free.
The impression I have is that:
1. It's geared toward Adafruit products (not surprisely)
2. It appears to be very interested in supporting the nRF52840, though that is apparently (?) a work in progress and still early days. What would you say is already done versus yet to be done? If I could avoid re-inventing the wheel, I'd be interested.
Nice work! Thanks for posting it.
Since you mention it, what exactly is the difference between CircuitPython and MicroPython? How do you like it? What do you see as its benefits as well as downsides, if any?
Since this thread has already fulfilled its original purpose, I don't at all mind straying far from the original post. So, feel free.
The impression I have is that:
1. It's geared toward Adafruit products (not surprisely)
2. It appears to be very interested in supporting the nRF52840, though that is apparently (?) a work in progress and still early days. What would you say is already done versus yet to be done? If I could avoid re-inventing the wheel, I'd be interested.
Re: [nRF52] Where is the umachines library module for the nRF52 boards? Does it even exist?
I think the main motivation for circuitpython was to have a version of micropython, that is easier to use for beginners, and is better adapted to Adafruit's own boards, even the ones with very small microcontrollers.
Therefore, they're quick to adapt to new hardware, and add features, but they only implement what's necessary, and don't care so much about sophisticated language features.
I appreciate their controller support and the many drivers, but I don't like that many things will probably never be backported to micropython, and that their fork will maybe drift farther away.
It divides the developer community.
Therefore, they're quick to adapt to new hardware, and add features, but they only implement what's necessary, and don't care so much about sophisticated language features.
I appreciate their controller support and the many drivers, but I don't like that many things will probably never be backported to micropython, and that their fork will maybe drift farther away.
It divides the developer community.