• State Not Answered
  • Replies 29 replies
  • Subscribers 75 subscribers
  • Views 9961 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 212468
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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？）

Parents
  • 0

    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

  • 0 in reply to 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.

  • 0 in reply to awneil

    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

  • 0 in reply to PM Bubblynet

    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 ...

  • 0 in reply to awneil

    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...

  • 0 in reply to PM Bubblynet

    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 ...

  • 0 in reply to awneil

    I've been playing around with DMX.  I have DMX transmit pretty much working. One way to handle the initial Break - Mark is to change the baud to 115K and transmit a 00, then change it back to 250K.  I have a 513 byte DMX buffer and it needs to get sent in three pieces because of the DMA 255 byte limit.  If the SoftDevice interrupts in the middle it shouldn't be a problem because the DMX spec only requires that a frame gets completed within one second.  From past experience, many DMX devices will work fine if you just send 1 stop bit, but not all.  So if you need to be able to transmit to any DMX device you need 2 stop bits which means the nRF52832 is not an option.

    Doing a DMX receive looks like it will be more difficult.  It looks like the driver supports notification of a BREAK which can be used to initiate receive of the 513 byte frame.  The problem is if the SoftDevice causes a delay in the start of the receive you could start receiving data in the middle of the frame.  Also, due to the DMA 256 byte limit the receive needs to be split into multiple pieces which makes for more opportunities for errors.  

    Is there a good way to detect if a large delay has occurred or is there a way to chain several DMA operations together to allow a longer stream of uninterrupted data?

Reply
  • 0 in reply to awneil

    I've been playing around with DMX.  I have DMX transmit pretty much working. One way to handle the initial Break - Mark is to change the baud to 115K and transmit a 00, then change it back to 250K.  I have a 513 byte DMX buffer and it needs to get sent in three pieces because of the DMA 255 byte limit.  If the SoftDevice interrupts in the middle it shouldn't be a problem because the DMX spec only requires that a frame gets completed within one second.  From past experience, many DMX devices will work fine if you just send 1 stop bit, but not all.  So if you need to be able to transmit to any DMX device you need 2 stop bits which means the nRF52832 is not an option.

    Doing a DMX receive looks like it will be more difficult.  It looks like the driver supports notification of a BREAK which can be used to initiate receive of the 513 byte frame.  The problem is if the SoftDevice causes a delay in the start of the receive you could start receiving data in the middle of the frame.  Also, due to the DMA 256 byte limit the receive needs to be split into multiple pieces which makes for more opportunities for errors.  

    Is there a good way to detect if a large delay has occurred or is there a way to chain several DMA operations together to allow a longer stream of uninterrupted data?

Children
Related
Terms of service