nrf: implement busio.UART #1039

dhalbert · 2018-07-17T14:37:39Z

No description provided.

hathach · 2018-09-18T11:26:49Z

While working on uart, @arturo182 is it ok now if I remove the macro that use the jlink cdc instead of native cdc. That option is there for you only :)

arturo182 · 2018-09-18T15:07:47Z

Which cdc do you mean?

hathach · 2018-09-18T15:08:59Z

the jlink cdc that uses the hwuart on pca10056 CFG_HWUART_FOR_SERIAL
https://github.com/adafruit/circuitpython/blob/master/ports/nrf/supervisor/serial.c#L35

arturo182 · 2018-09-18T15:12:07Z

Yes, it's fine to remove that :)

hathach · 2018-09-18T18:09:38Z

anyone knows this function got called, or it is called by system board_uart
https://github.com/adafruit/circuitpython/blob/master/ports/nrf/board_busses.c#L108

hathach · 2018-09-18T18:22:51Z

ah ha, I figured it out, ~~it is the default constructor, sort of :D~~ It is used for default UART object, but not included yet by nrf port.

hathach · 2018-09-19T10:15:46Z

@dhalbert the default uart for pca10056 should be P0.8 and P0.6 instead of P1.1 & P1.2. It is connected to jlink cdc allow for quick testing. Furthermore if jlink cdc is not connected, those pins are in tri-state, which is safe to use with other device. Please let me know if I missed something.
https://github.com/adafruit/circuitpython/blob/master/ports/nrf/boards/pca10056/mpconfigboard.h#L49

hathach · 2018-09-19T10:28:41Z

Ah, I see, seem like you want to keep the pin compatible with Arduino layout :D . Sorry, didn't realize that until I check the pcb

dhalbert · 2018-09-19T12:53:44Z

@hathach right, exactly.

hathach · 2018-09-19T13:34:30Z

@dhalbert @tannewt should the self->buffer be freed in common_hal_busio_uart_deinit() , or we can just leave it to gc

https://github.com/adafruit/circuitpython/blob/master/ports/atmel-samd/common-hal/busio/UART.c#L217

dhalbert · 2018-09-19T13:46:23Z

Leave it to gc. It is allocated by gc_alloc() as a regular garbage-collectable object.

hathach · 2018-09-19T13:48:10Z

ah thanks, this new to me, I will just skip the free for nrf52 as well.

hathach · 2018-09-20T17:54:14Z

probably the same hw issue that I encountering. The first 2 irq uart request will fail miserably without real reason. UART is not too easy after all ~ . ~
https://devzone.nordicsemi.com/f/nordic-q-a/33677/nrf52840-pin-uart-rx-bug

dhalbert · 2018-09-20T18:18:05Z

@hathach that devzone post is very confusing. I wonder if that's the PDK board.

hathach · 2018-09-20T18:22:05Z

@dhalbert that is what I am seeing here as well with my board. At least I know why it doesn't work out the way I think. Using bare-metal is much easier for busio in comparison with the nrfx_uart. Though, I am getting it done by just ignoring first 2 irq error

hathach · 2018-09-20T18:25:53Z

@dhalbert If you have time, I could push the code for you test there before I clean them up.

dhalbert · 2018-09-20T18:27:55Z

i could try it with a GPS

hathach · 2018-09-20T18:33:49Z

You don't need extra hw to test since only the write() work now. The bug prevent me to do subsequent receiving since it failed at the beginning.

here is the code
https://github.com/hathach/circuitpython/blob/nrf52_uart_io/ports/nrf/common-hal/busio/UART.c#L75
board.UART() will call the first nrfx_uart_rx() which will trigger error 4 (frame error) ---> nrfx will cancel transfer internally.

Just run u.read() : this will printf the previous error and call nrfx_uart_rx() again.
Then call u.read() again to get the previous error of the 1st read which is 0x08 break error.
afterward no more error, call more will result in NRFX_BUSY code.

To test with u.write() you can hook up FTDI cable, it should work.

Adafruit CircuitPython 4.0.0-alpha-1079-g9c2530687-dirty on 2018-09-21; PCA10050
>>> import board                                                                
>>> u = board.UART()                                                            
>>> u.read()                                                                    
error = 0x00000004                                                              
rx count = 0x00000000                                                           
b''                                                                             
>>> u.read()                                                                    
error = 0x00000008                                                              
rx count = 0x00000000                                                           
b''                                                                             
>>> 
>>> u.read()                                                                    
rx count = 0x00000000                                                           
b''                                                                             
>>> u.read()                                                                    
rx count = 0x00000000                                                           
Traceback (most recent call last):                                              
  File "<stdin>", line 1, in <module>                                           
AssertionError: error = 0x0BAD000B

dhalbert · 2018-09-20T18:35:22Z

Are you using UART or UARTE?

dhalbert · 2018-09-20T18:39:12Z

I asked for more info in that DevZone case.

hathach · 2018-09-20T18:40:31Z

UART since the rest of repo use it. UARTE is just having DMA to move data into buffer, not really needed for cpy I guess. Also the DMA demands data must be on the SRAM, flash address (i.e global const [] ) won't work. I am not sure if cpy use any of those.

dhalbert · 2018-09-20T18:52:23Z

What exactly is the error you are getting? Is this relevant? https://devzone.nordicsemi.com/f/nordic-q-a/37521/nrf52840-usb_cdc_acm-uart/145013#145013

I saw one DevZone case that recommended using UARTE over UART in nrf52832, but now I can't find it again.

hathach · 2018-09-20T18:58:13Z

error 4 (frame ) then error 8 (break). oh way, I think I found my own error lol, let's me test a bit more.

hathach · 2018-09-20T19:00:52Z

facepalm, I just assign the txd 2 time :( . That is high price to pay here . . Working late is not good at all lol
https://github.com/hathach/circuitpython/blob/nrf52_uart_io/ports/nrf/common-hal/busio/UART.c#L108

Sorry for your time with my stupid mistake @dhalbert

dhalbert · 2018-09-20T19:01:52Z

no problem, but time to sleep!

hathach · 2018-09-20T19:04:22Z

Do you prefer UARTE to UART, I could upgrade it to UARTE. Though, you must make sure all data is in SRAM not flash, and we must malloc buffer if needed. I think it is not really gain much benefit, since the uart is slow, cpu time for moving data is not much at all.

dhalbert · 2018-09-20T19:06:05Z

No, I don't prefer, just thought that UARTE might not have the problem, and now it's moot.

hathach · 2018-09-20T20:54:25Z

uart io should be done, I will hook an GPS wing to test tomorrow. Phew, too much time for the easy uart. Hopefully there is no more bugs :D

dhalbert · 2018-09-21T00:38:00Z

I'm rethinking UARTE vs UART: Advantage of UARTE is that there are two instances on '840, so we can have more than one UART channel. I understand the issue of of EasyDMA not working from flash, though we can copy to RAM.

Also UART is deprecated, though I don't understand how significant that is. If there were a 58x0 after the 5840, maybe they'd drop UART?

hathach · 2018-09-21T07:13:07Z

No problems, I will make the switch. the flow is similar to what I am doing anyway. IRQ vs DMA only has diff that cpu must move the data manually. But I think I will test what I have first before switching. I will also update the serial.c as well. currently serial.c use polling method, so there should be no impact at all.

tannewt · 2018-09-21T16:56:26Z

DMA can be a bit faster even when we poll because it runs even when the cpu is handling an interrupt.

…

On Fri, Sep 21, 2018 at 7:13 AM hathach ***@***.***> wrote: No problems, I will make the switch. the flow is similar to what I am doing anyway. IRQ vs DMA only has diff that cpu must move the data manually. But I think I will test what I have first before switching. I will also update the serial.c as well. currently serial.c use polling method, so there should be no impact at all. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1039 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADNqbrQ7K8wYi3d_Kk4BNTMXXpXDtDBks5udJGEgaJpZM4VS-Px> .

hathach · 2018-09-21T18:03:25Z

@tannewt yeah, I am moving it to uarte now.

tannewt · 2018-09-21T20:49:18Z

Ok great!

…

On Fri, Sep 21, 2018 at 6:03 PM hathach ***@***.***> wrote: @tannewt <https://github.com/tannewt> yeah, I am moving it to uarte now. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1039 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADNqUL0aV9z9JozlgoucG6T0-u5eUl8ks5udSntgaJpZM4VS-Px> .

dhalbert · 2018-10-05T20:56:41Z

Still to implement:

Using both instances on nRF52840.
Add uart_init() to disable on soft restart.
Change _VERIFY_ERROR to be more user-friendly.

@hathach I will take these up later.

tannewt · 2019-01-11T01:31:00Z

This has been done right?

ladyada · 2019-01-11T01:55:23Z

its been solid so far, @jerryneedell has done the most testing

jerryneedell · 2019-01-11T02:03:05Z

It’s been working great on the particle boards

dhalbert · 2019-01-11T02:15:39Z

It only provides one UARTE, and there are two available. Not sure the uart_init() has been fixed either. See #1039 (comment) above.

dhalbert · 2019-01-11T02:17:12Z

Nope, no uart_init() yet.

jerryneedell · 2019-01-11T02:20:42Z

oops - sorry about the premature close...

tannewt · 2019-02-14T18:32:12Z

@dhalbert Can we close this now after #1541 ?

dhalbert · 2019-02-14T18:32:48Z

Yes, I thought it was going to get closed automatically.

tannewt · 2019-02-14T18:45:36Z

It's not super smart about how when it knows to close: https://help.github.com/articles/closing-issues-using-keywords/

dhalbert added the nordic label Jul 17, 2018

dhalbert added this to the 4.0 Beta milestone Jul 17, 2018

hathach self-assigned this Sep 18, 2018

hathach mentioned this issue Sep 25, 2018

Nrf52 uart io #1212

Merged

jerryneedell closed this as completed Jan 11, 2019

dhalbert reopened this Jan 11, 2019

tannewt modified the milestones: 4.0 Beta, 4.0.0 - Bluetooth Jan 21, 2019

dhalbert mentioned this issue Feb 13, 2019

nrf: Add second UARTE to busio.UART. Init uarts on startup. #1541

Merged

dhalbert closed this as completed Feb 14, 2019

nrf: implement busio.UART #1039

nrf: implement busio.UART #1039

Comments

dhalbert commented Jul 17, 2018

hathach commented Sep 18, 2018

arturo182 commented Sep 18, 2018

hathach commented Sep 18, 2018

arturo182 commented Sep 18, 2018

hathach commented Sep 18, 2018

hathach commented Sep 18, 2018 • edited Loading

hathach commented Sep 19, 2018

hathach commented Sep 19, 2018

dhalbert commented Sep 19, 2018

hathach commented Sep 19, 2018 • edited Loading

dhalbert commented Sep 19, 2018

hathach commented Sep 19, 2018

hathach commented Sep 20, 2018 • edited Loading

dhalbert commented Sep 20, 2018

hathach commented Sep 20, 2018

hathach commented Sep 20, 2018

dhalbert commented Sep 20, 2018

hathach commented Sep 20, 2018 • edited Loading

dhalbert commented Sep 20, 2018

dhalbert commented Sep 20, 2018

hathach commented Sep 20, 2018

dhalbert commented Sep 20, 2018

hathach commented Sep 20, 2018

hathach commented Sep 20, 2018 • edited Loading

dhalbert commented Sep 20, 2018

hathach commented Sep 20, 2018

dhalbert commented Sep 20, 2018

hathach commented Sep 20, 2018

dhalbert commented Sep 21, 2018

hathach commented Sep 21, 2018

tannewt commented Sep 21, 2018 via email

hathach commented Sep 21, 2018

tannewt commented Sep 21, 2018 via email

dhalbert commented Oct 5, 2018 • edited Loading

tannewt commented Jan 11, 2019

ladyada commented Jan 11, 2019

jerryneedell commented Jan 11, 2019

dhalbert commented Jan 11, 2019

dhalbert commented Jan 11, 2019

jerryneedell commented Jan 11, 2019

tannewt commented Feb 14, 2019

dhalbert commented Feb 14, 2019

tannewt commented Feb 14, 2019

hathach commented Sep 18, 2018 •

edited

Loading

hathach commented Sep 19, 2018 •

edited

Loading

hathach commented Sep 20, 2018 •

edited

Loading

hathach commented Sep 20, 2018 •

edited

Loading

hathach commented Sep 20, 2018 •

edited

Loading

dhalbert commented Oct 5, 2018 •

edited

Loading