• State Not Answered
  • Locked Locked
  • Replies 11 replies
  • Subscribers 62 subscribers
  • Views 6919 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 107124
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Possible to bitbang a 9600baud UART on nRF51822?

Brendan Shanks

Is it possible to bit bang a 9600 baud UART on the nRF51822 while the BLE softdevice is running?

The reciprocal of 9600 baud is around 100 µs, so the interrupt handler will need to run about that often for the UART to work reliably. However, the S110 SDS specifies that the processor could be taken up by the highest-priority soft device interrupt for up to 400-500 µs.

It seems to me that would prevent the bit-bang timer interrupt from running, and would cause bits to be lost. Is this correct?

I need to communicate with two different devices (so 2 UARTs) using a protocol with 2 stop bits, so I cannot use the chip's hardware UART

  • 0

    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.

  • 0 in reply to RK

    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.

  • 0 in reply to RK

    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.

  • 0 in reply to RK

    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

  • 0 in reply to RK

    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.

Related

core_v2_widget.Hide()