Skip to content

Understanding differences between CircuitPython versus Micropython - examples Uarts/SD(Teensy) #6276

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
KurtE opened this issue Apr 12, 2022 · 5 comments
Closed

Understanding differences between CircuitPython versus Micropython - examples Uarts/SD(Teensy) #6276

KurtE opened this issue Apr 12, 2022 · 5 comments
Labels
enhancement

Comments

@KurtE
Copy link

KurtE commented Apr 12, 2022

Sorry,

Not sure if this is best asked here or up on forum, Also lost first pass of typing this in, so will probably be more brief
which may not be a bad thing.

As @mjs513 and myself have been experimenting with CircuitPython and MicroPython, I am trying to understand the relationship between the code bases. From Github, my impression is that this is a fork of MicroPython so would expect a lot of basic stuff to be common.

Also I am mostly mentioning Teensy here as that is what I am working on and more familiar with, but a lot of this would mostly likely apply to other boards as well.

Things like:

Creating of UART Objects
Example wish to create two uart objects for what in Arduino are Serial1 and Serial4 on T4.1.

With MicroPython would do something like:

from machine import UART
uart1 = UART(1, 1000000)
uart4 = UART(4, 1000000)

With CircuitPython something like:

import busio, boardio
uart1 = busio.UART(board.TX, board.RX, baudrate=500000)
uart4 = busio.UART(board.D17, board.D16, baudrate=500000)

Or with current stuff pulled in the last one can be done like:

uart4 = busio.UART(board.TX4, board.RX4, baudrate=500000)

Why complete different? Both have pluses and minus.

Asynchronous UART output
More fundimental issue. As I mentioned in the issues: #6263 and #6254

Some code like:

uart1 = busio.UART(board.TX, board.RX, baudrate=1000000)
uart2 = busio.UART(board.IO17, board.IO16, baudrate=1000000)
uart1.write(b'uart1')
uart1.write(b'second part')
toggle_pin.value = True
uart2.write(b'uart2')
toggle_pin.value = False

The code waited for each write to complete before it continued, which was totally unexpected by me as I would hope
that the code could continue to do other things. Also there was a pretty large gap between each operation
image
But from 6254:

busio.UART() is synchronous. It waits for the sending to complete before returning.

When try something similar on MicroPython:

import machine
from machine import UART
import select
import sys
import time
loop_count = 0
uart1 = UART(1, 1000000)
uart4 = UART(4, 1000000)
led = machine.Pin(13, machine.Pin.OUT)
mp = machine.Pin(2, machine.Pin.OUT)
while True:
    mp.high()
    uart1.write("Uart1:")
    uart1.write("More data")
    uart4.write("Uart4!")
    mp.low()
    led.high()
    time.sleep(0.2)
    led.low()
    time.sleep(0.2)
    led.high()
    time.sleep(0.2)
    led.low()
    time.sleep(0.8)
    loop_count += 1
    if (loop_count & 0xf) == 0:
        print(str(loop_count))
    avail = select.select([sys.stdin], [], [], 0)
    if avail != ([], [], []):
        input_line = sys.stdin.readline().rstrip("\n")
        print("in:", input_line)

I see output that is more what I expected:
image

Teensy SDIO Support
Currently there is no code support within the ports for Teensy boards to support an SDIO, where as there is support within
MicroPython.

For example I have a Teensy 4.1 plugged in with an SDCard inserted within the built in SD slot.
For example with REPL I have:

>>> import os
['flash', 'sdcard']
>>> os.listdir('/flash')
[]
>>> os.listdir('/sdcard')
['System Volume Information', 'mtpindex.dat', 'odd1.wav', 'zarathustra.mp3', '2001', 'Audacity', 'FLAC', 'Candyman.aac', 'Dont Rain on My Parade.mp3', 'annie1.bmp', '111', '222', 'Small-Drake.jpg', 'Test', 'testImage.png', 'annie2.bmp', 'annie3.bmp', 'DSC00040.JPG', 'DSC00445.jpg', 'DSC01511.JPG', 'DSC03201.JPG', 'house.gif', 'Laiik-is-Tired.bmp', 'P3090005.JPG', 'Sharon Barn.bmp']

Looking to try to add SDIO support, but hard to know good starting point, a couple of options include:
a) try to copy and rewrite the code for STM to be IMXRT1062 based.
b) Try to start from the MicroPython code base, but your HAL/SDK code is significantly different.
c) Try to bypass most of it and start with Teensy SDFat like code.

DigitalIO
Sorry minor comment.

Turning an IO pin on and off is different.
MicroPython:

led.on()
led.off()

CircuitPython:

led.value = True
led.value = False

I can work with either, I do find the on() and off() to be more readable... But.

Again sorry, I am not sure if this is the appropriate place to ask and probably some/all of this
has been answered before.

Kurt
@ladyada
Copy link
Member

ladyada commented Apr 12, 2022

port-specific behavior is different between micropython and circuitpython. only core language elements are the same.
there's sdioio for STM32 and SAMD51, nobody has yet added support for iMX - someone could do so!
https://docs.circuitpython.org/en/latest/shared-bindings/sdioio/index.html
#4020

@dhalbert
Copy link
Collaborator

The core language part of CircuitPython is very close to MicroPython, and we merge regularly from upstream. However, the native modules to do I/O, etc. are different. We try to be consistent across ports, so that it's easy to move code. We may do this at the expense of exposing particular features of a particular chip family, unlike MicroPython, which is willing to expose chip-specific features more readily in the basic I/O modules. At the time we forked from MicroPython, there were different native modules to support different ports (pyb, etc.), and machine had not been as well fleshed out.

There is a somewhat longer discussion here: https://discord.com/channels/327254708534116352/327254708534116352/908084497176756274 and several other places Please join us in https://adafru.it/discord in #circuitpython-dev if you would like to discuss this more casually.

@dhalbert
Copy link
Collaborator

We have an open issue for SDIO on i.MX: #4020. See the tag mimxrt10xx iMX RT based boards such as Teensy 4.x for a number of "to do" issues for i.MX. You are welcome to add to those or comment.

@KurtE
Copy link
Author

KurtE commented Apr 12, 2022

@dhalbert @ladyada - Thanks for the quick responses.

Yes I noticed that there was an open issue on SDIO, Sorry I probably should have mentioned that in my opening post here.

Note: I did mention that there were a few options to implement it, sort of referred to it in my option a) by mentioning the STM implementation. Which would take a major rework, as it is all geared around the STM SDK...

In most of the other stuff I mentioned, I don't think most of it is mimxrt10xx hardware specific. But will check to see
what is up there.

As for making the user code consistent across ports, is a great goal, but tricky. For example, even simple things, like what do you call your IO pins in boards object? For some you have names like: IO2, where as Teensy boards it is D2, whereas MicroMod, it is names like G2... For Uarts, putting in specific pin numbers/names in for TX and RX is mostly hardware specific.

The more interesting questions have to do with things like overlapping IO and speed and consistency of speed of IO operations and the like. But that looks like something to be discussed elsewhere.

The main thing for me to decide now is... What do I want to do?

@dhalbert
Copy link
Collaborator

As for making the user code consistent across ports, is a great goal, but tricky. For example, even simple things, like what do you call your IO pins in boards object? For some you have names like: IO2, where as Teensy boards it is D2, whereas MicroMod, it is names like G2... For Uarts, putting in specific pin numbers/names in for TX and RX is mostly hardware specific.

Yes, for pins, people often have to change the pin names, because of restrictions on which peripherals can use which pins, or due to historical differences in pin numbering: Arduino style, ESP32 style, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@ladyada @KurtE @dhalbert