I am trying to do DMX512 (protocol), I hope to help me, time is very urgent

[tony55723]

Hi，

DMX512 protocol is USITT（United States Institute for Theater Technology）Prescribed agreement

I want to follow this agreement to design

============ DMX512 protocol：

Baud：250K

Break：88us

MAB：8us

============ Data frame contains：

Start：1 bit

Data：8 bit

Stop：2 bit

Parity：None

I know that this design will still have errors.

I hope to give me some help, the project is urgent, thanks

Another stop bit need 2 bit, is it necessary to operate directly with registers?

（But the SDK is full of library operations？）

[Jørgen Holmefjord]

Hi,

Only UARTE peripheral support two stop bits, and this is only supported on nRF52840 and nRF52810 ICs. Unfortunatelu, there seems to be no support for setting this in the drivers. 

You can set two stop bits by writing the register directly after initializing the UARTE peripheral:

NRF_UARTE0->CONFIG |= (UARTE_CONFIG_STOP_Two << UARTE_CONFIG_STOP_Pos);

The UARTE peripheral have EasyDMA support, meaning transfers can happen in the background while CPU is busy handling BLE/softdevice events. If you frequently need to handle UART events with strict timing requirements, this will not work together with the softdevice.

Best regards,
Jørgen

[Jørgen Holmefjord]

I'm not familiar with the protocol details of DMX, but if it have strict timing requirements, an external MCU might be a better solution.

[Jørgen Holmefjord]

My comment from 4 months ago still stands. There is only one CPU core in the nRF52832. If using BLE, the softdevice will always have highest priority, the DMX protocol will have to wait, meaning that if there are strict timing requirements an external MCU might be better solution.

[awneil]

PM Bubblynet said:

if there is any news?

I don't think so - I think everything that's been said remains true.

[tony55723]

Maybe only the external MCU can solve, the channel has not been sent, and it is changed from uart to I/O (for the next break)

[awneil]

PM Bubblynet said:

any news?

I though both Jørgen Holmefjord  and I had already replied that the comments from 4 months ago still stand - but I can't see that in this thread any more?!

Strange.

EDIT

Oh - now they've reappeared!

The way this forum randomly hides certain posts is really unhelpful!

[PM Bubblynet]

Jesus this form... wrote a whole white paper and it didn't post it... not cool...

Anyways, short version:

Please define "strict" timing? :) DMX512 protocol is fairly simple, http://cdb.s3.amazonaws.com/ItemRelatedFiles/10191/dmx-101-handbook.pdf page 17, after that annoying break start, the info payload is divided on 512 slots with 11 bits each, 8 bit info, 1 bit start and 2 bit stop for each slot, each slot tells the intensity level 0-255, then the telegram gets repeated again and again for ever in some sort of persistent advertising... so its not a big deal if we miss few packages here and there... there will be 44 DMX per second and they will be the same most of the time... nothing fancy there... its transmitted at 250kHz... I guess the nRF52832 can handle that?? I cant see why an aditional MCU would be needed? DMX was not designed for full duplex comms, real time applications, error prevention or anything that fancy...

In summary has similar timing requirements that any asynchronous serial protocol... I cant say that it has anything specially strict...

As I mentioned before, I am just fishing around to see if and when a DMX to Bluetooth translator should be on our roadmap for Bluetooth Mesh lighting control system...

[awneil]

PM Bubblynet said:

this form...

Tell me about it!!

PM Bubblynet said:

Please define "strict" timing?

Exactly. These are just "finger in the air" feelings - not detailed timing analyses

Anyhow, it sounds like you are the DMX expert here - so you're probably the best one to try it and see!

The point is that the BLE stack does have some very strict timing requirements - so whatever you do for the DMX must not mess them up - or, maybe more important, must not be messed up by the stack grabbing the CPU.

So the thing with a separate MCU is that it's the safe option.

PM Bubblynet said:

its not a big deal if we miss few packages here and there

I think any issues are going to be with individual bit timings - rather than whole packages?

PM Bubblynet said:

similar timing requirements that any asynchronous serial protocol

But they are usually handled in hardware - by the UART.

From the initial postings, it looked like the nRF52 UART was not (quite) going to do what DMX requires?

PM Bubblynet said:

if and when a DMX to Bluetooth translator should be on our roadmap

If you're looking for help with that, drop me a PM ...

[PM Bubblynet]

I wouldn't call me a "DMX expert"... I am rather just a follower of our dark lord and savior all hail Google! :D

I went quickly though the UART docs https://www.nordicsemi.com/en/DocLib/Content/SDK_Doc/nRF5_SDK/v15-2-0/hardware_driver_uart cant see a reason why UART wouldn't be able to handle DMX? for example I am curious about:

Jørgen Holmefjord said:

Only UARTE peripheral support two stop bits, and this is only supported on nRF52840 and nRF52810 ICs. Unfortunatelu, there seems to be no support for setting this in the drivers. 

it seems odd that only the baby brother and the bigger brother "supports" 2 stop bits? its just me or this is part of the protocol / formatting layer and nothing to do with UART as a driver / hardware layer?...? it seems this would be just part of the formatting library of the telegram...?

a standard 250kbit/s UART shouldn't be enough? and even then this should be enabled 2 or 3 times per second... maybe? just in case we need resources for something else? again I apologize if I am missing something basic / obvious here... I should stop being lazy and study stuff before asking :D

[awneil]

But you clearly know more about it than me!

I'm just going from the opening post - but then it's not entirely clear that the poster really understood that.

Yes, the actual data frame looks to me like just a standard UART frame.

The potential problem areas seem to be in the initial "break", and the "mark after break". Possibly also the "inter-frame time".

The OP's code did that with inline delays - that is likely to get disrupted by the BLE stack ...

[PM Bubblynet]

hm.... that seems a bit weird idea to implement the "break"... anyways, found this: https://www.nxp.com/docs/en/application-note/AN3315.pdf

3.1 Software Implementation Because the protocol consists of an untyped byte stream produced by standard UARTs, the implementation can be easily adapted to work with any microcontroller supporting baud rates up to 250 kbps.

I would put my 5 bucks on the nRF52832 can do this... but I cant jump now to prototyping... need to finish a couple of things before holidays, will see after that how it goes...

[awneil]

If that is the case, then I'd agree with you.

It would also seem sensible that the spec writers would base their protocol on something that can be easily done with standard hardware ...