Possible to bitbang a 9600baud UART on nRF51822?

RE: Possible to bitbang a 9600baud UART on nRF51822?

los — Tue, 01 Dec 2015 10:12:56 GMT

Now I'm advertising @40ms. I've not yet tested bit banging in connection. Now I'm trying to solve some issues. @9600bps, timeslot duration is 1240µs, I've just discovered duration between two bytes was ~2ms due to timeslot extension failure. Now I'm checking all runs fine and after I will test with with small connection intervals.

RE: Possible to bitbang a 9600baud UART on nRF51822?

Susheel Nuguru — Tue, 01 Dec 2015 06:14:19 GMT

Hi IOS, good to see that you proved the concept. Can I ask you what type of BLE activity was present at the time of testing UART big banging @9600 baudrate. I am guessing that you should not be using fast connection intervals.

RE: Possible to bitbang a 9600baud UART on nRF51822?

los — Mon, 30 Nov 2015 16:34:18 GMT

Hi Aryan,

Using soft device timeslot API to bit bang UART is funny! You will find code in my response from this post :

devzone.nordicsemi.com/.../

I only did buffered UART Tx, Tx bytes are buffered and then bit banged using Timer0. After 1 byte transmission, a timeslot extension is queried (querying a new timeslot also works). For timeslot length I added 200µs for processing time to byte transmission duration because I got some SoftDevice errors in soc_radio_timeslot.c l190 . You will find code here :

github.com/.../AltSoftSerial.cpp

github.com/.../timeslot.c

RE: Possible to bitbang a 9600baud UART on nRF51822?

RK — Thu, 21 May 2015 01:46:53 GMT

If that's what you need then regrettably you'll need another chip to help you out. Have you looked at any of the UART/SPI/I2C chips out there? I did a quick google and found some dual UARTs with TX/RX, 64-128 bytes of buffer onboard and a single SPI interface for 5-10 bucks a pop. NXP makes one, Maxim makes one, there's probably others. Unless I already had another component on-board I could use, I'd probably try one of those, should be very easy to interface up.

RE: Possible to bitbang a 9600baud UART on nRF51822?

Brendan Shanks — Wed, 20 May 2015 18:23:05 GMT

Thanks for the discussion but I also need to receive from both devices and there's no flow control, clearly this can't all be done on the nRF. Current plan is to use another microcontroller as sort of an I/O processor.

RE: Possible to bitbang a 9600baud UART on nRF51822?

Susheel Nuguru — Tue, 19 May 2015 11:36:52 GMT

I was answering thinking that the question is to achieve the max speed that is 9600 baud rate. The method you mentioned will work with a flow control enabled bit banging (for RX to work), but the bit rate achieved will be much less. There is a post for safe attainable baud rate while in connections to be 9600, and this uses hardware UART devzone.nordicsemi.com/.../ I agree with you RK, its doable, but could be tricky. @Brendan Shanks : Could I request you to post your progress in Github github.com/NordicSemiconductor If you succeed, this could prove useful to many.

RE: Possible to bitbang a 9600baud UART on nRF51822?

RK — Tue, 19 May 2015 10:56:43 GMT

I never suggested you needed to get a slot on a regular basis, nor did I suggest asking for a slot as short as 100us. You ask for a slot of 10ms (or similar) which gives you enough time to send around 8 entire characters at 9600 baud plus time to set up and tear down. When you get that slot you now have 10ms during which time you can do the multiple time-critical operations to bitbang out the characters without being interrupted. Then you stop and ask for another slot and when you get that, you send the next 8 characters, or however many fit in the slot.

Since it's a UART the important thing is once you send the start bit, you have to send the rest of the character to the stop bit with precise timing. Once you've sent the whole character it doesn't matter when you send the next one, you can have a gap waiting for the next timeslot. I reckon a 10ms timeslot would work ok.

RE: Possible to bitbang a 9600baud UART on nRF51822?

Susheel Nuguru — Tue, 19 May 2015 10:33:38 GMT

You can get a timeslot length of 100us, but you are not guaranteed to get this slot every 100us. I mean to say that timeslot length is not a problem, timeslot interval(periodicity) is. If the connection interval is slow like 100ms or so, then there can be 999 timeslots that can be allocated, but then the softdevice will reject any further request until it uses up its next 270us. If we are bitbanging flowcontrol and if the radio activity is very less (slow intervals), then MAYBE we can get close to that baudrate, does not seem impossible though

RE: Possible to bitbang a 9600baud UART on nRF51822?

RK — Tue, 19 May 2015 09:15:30 GMT

Really - the multiprotocol timeslot API section in the manual says the following

8.3 Timeslot length
The length of the timeslot is specified by the application in the request and ranges from 100 μs to 100 ms. Longer continuous timeslots can be achieved by requesting to extend the current timeslot. Successive extensions will give a timeslot as long as possible within the limits set by other SoftDevice activities, up to a maximum of 128 s.

Is that not true - can you not request a timeslot between 100us and 100ms? A 10ms timeslot would allow the OP time to bit-bang out around 8 characters.

RE: Possible to bitbang a 9600baud UART on nRF51822?

Susheel Nuguru — Tue, 19 May 2015 09:05:58 GMT

Hi, Even with timeslot I think 100us slot are very difficult to fulfill. The softdevice can take upto 270us and this would not be good for this case.

RE: Possible to bitbang a 9600baud UART on nRF51822?

RK — Tue, 19 May 2015 06:10:41 GMT

You can't bit bang it just by using interrupts, no, because indeed you'll be blocked randomly and will lose timing sync. At 9600baud however one character is just over 1ms, you could use the multiprotocol timeslot api to request a block of time and you get control over the hardware for that block. During that time you push out a number of complete characters, then ask for an extension or relinquish control and request another block and continue when you get more time allocated.

As long as your data is 'bursty' you should be able to send it out without it backing up on you.