[nRF52] Where is the umachines library module for the nRF52 boards? Does it even exist?

Discussion and questions about boards that can run MicroPython but don't have a dedicated forum.
Target audience: Everyone interested in running MicroPython on other hardware.
Post Reply
User avatar
WhiteHare
Posts: 58
Joined: Thu Oct 04, 2018 4:00 am

[nRF52] Where is the umachines library module for the nRF52 boards? Does it even exist?

Post by WhiteHare » Thu Oct 11, 2018 6:37 pm

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?

User avatar
dhylands
Posts: 2856
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: [nRF52] Where is the umachines library module for the nRF52 boards? Does it even exist?

Post by dhylands » Thu Oct 11, 2018 7:34 pm

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

User avatar
WhiteHare
Posts: 58
Joined: Thu Oct 04, 2018 4:00 am

Re: [nRF52] Where is the umachines library module for the nRF52 boards? Does it even exist?

Post by WhiteHare » Thu Oct 11, 2018 10:23 pm

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:

Code: Select all

>>> machine.mem32[0x50000748]=0x703
>>> machine.mem32[0x50000504]=0x1A0060
Thanks! :D :D :D :D :D

kak
Posts: 14
Joined: Fri Oct 05, 2018 11:35 am

Re: [nRF52] Where is the umachines library module for the nRF52 boards? Does it even exist?

Post by kak » Sat Oct 13, 2018 3:27 pm

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.

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)

kak
Posts: 14
Joined: Fri Oct 05, 2018 11:35 am

Re: [nRF52] Where is the umachines library module for the nRF52 boards? Does it even exist?

Post by kak » Sat Oct 13, 2018 4:15 pm

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:

Code: Select all

ptr32(0x5000050C)[0] = uint(0x80000000) # turn P0_31 on
p.s.: Short version for the REPL to switch LED 1 on:

Code: Select all

@micropython.viper 
def led1_out():
     ptr32(0x50000518)[0] = 0x2000
led1_out()
I like that @micropython.viper. Sounds creepy and dangerous. Uuuhhh. Only for experts, don't try this at home, kids. ;-)

User avatar
WhiteHare
Posts: 58
Joined: Thu Oct 04, 2018 4:00 am

Re: [nRF52] Where is the umachines library module for the nRF52 boards? Does it even exist?

Post by WhiteHare » Sun Oct 14, 2018 3:55 pm

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.

kak
Posts: 14
Joined: Fri Oct 05, 2018 11:35 am

Re: [nRF52] Where is the umachines library module for the nRF52 boards? Does it even exist?

Post by kak » Sun Oct 14, 2018 6:40 pm

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.

Post Reply