RFC: linux RDM/DMX driver for 8250 compatible UART's

[mic...@cubic.org]

Hi,

as with the upcoming platforms like Raspberry Pi, Orange Pi, BeagleBone
and so we have a lot of cheap embedded Linux platforms with Ethernet and
on-chip UARTs.

What do you think of writing a linux driver for a series of UARTs that
implement DMX and RDM efficiently.

Best Regards
Michael

[Peter Newman]

Apologies Michael, I never replied to your email.

It sounds good to me. We've got lots of suitable code to do the DMX and RDM bits at the byte level, we just need to deal with the low level timing stuff.

I suspect it makes more sense, if possible, for it to just be a plugin rather than an actual Linux driver, as people will find that easier to use/install. But I guess there may be timing/interrupt requirements that mean it has to be a driver?

[mic...@cubic.org]

Hi,

> It sounds good to me. We've got lots of suitable code to do the DMX and
> RDM
> bits at the byte level, we just need to deal with the low level timing
> stuff.

> I suspect it makes more sense, if possible, for it to just be a plugin
> rather than an actual Linux driver, as people will find that easier to
> use/install. But I guess there may be timing/interrupt requirements that
> mean it has to be a driver?

I am a friend of userspace drivers whenever possible, because they are
easier to debug and are more independent of the os version. The biggest
problem with the Linux tty driver is, that we do not get events like break
and error inline with the data. You can not decide when the break happend,
just that it happened. I am very unhappy with the linux serial port
implementation, because it is more a tty driver than a serial port driver.

When we have a serial-port or uart implementation for linux, that gives us
events like break start, break end, framing error, parity error and so on
inline with the data, we can write the DMX/RDM part in userspace.

For a famous german lighting console I divided the driver up into three
parts:
- userspace interface (DMX-Frames)
- DMX/RDM statemachine
- low level uart driver

One problem is the time the context switch between userspace and
kernelspace takes. I would implement a uart driver that can be used from
kernelspace and have a userspace wrapper, like with spidev, that makes it
possible to use it from userspace. Thus we can have a DMX/RDM driver where
the userspace driver latency is to hight and have a userspace driver
where we need the kernel independence.

I could think of a stacking like this:

+----------------------------------------------+
| userspace / kernelspace DMX wrapper library |
+----------------------------------------------+
| userspace DMX/RDM | | userspace DMX adapter |
+-------------------+ +------------------------+
|UART-adapter | | kernel DMX/RDM driver |
+-------------------+-+------------------------+
| UART-Driver A | UART Driver B | UART Driver C|
+----------------------------------------------+


Michael

[Simon Newton]

+1 to doing as much as possible in userspace. I think you have the
right approach.

Simon

> --
> The Open Lighting Project: open-l...@googlegroups.com, #openlighting (irc.freenode.org)
> To unsubscribe from this group, send email to open-lightin...@googlegroups.com
> For more options, visit https://groups.google.com/groups/opt_out?hl=en

[Michael Stickel]

I would like to not reinvent about 73 uart drivers and use the linux
serial driver framework, but this is the truth about the linux serial
drivers:

http://www.stickel.org/uart-dmx-driver/

Most of the serial driver interrupt functions just handle rx-char and
tx-char interrupts.
But that is not enough for real live use with industrial io that is more
than a modem or a terminal.

We would need to start with one very popular hardware, improve it's
serial driver and then talk to the tty/serial-port maintainer.
This would be a big refactoring and would take at least two years
including the tests. A very good regression testing would be key, to not
break the current driver infrastructure. Another possible way could be
to write new uart drivers, for industrial io, for some of the uarts, in
parallel to the existing ones. Once they are tested a layer can be
plugged between the existing tty driver and the uart drivers (tty_uart).

This way it is possible to concentrate on a few uart drivers (maybe 3)
and work on a sound design and stable implementation. Once this is
completed, one serial driver after another could be ported.

Oh my, this sounds crazy.

[Peter Newman]

I was going to suggest you look at what the DMX4Linux guys did, but I see that's a bit redundant. :)

It all sounds great to me, I suspect it would be worth trying to target the Pi's UART initially if possible, given it's got such a wide install base and interest from people.

I wonder if it could be coded in such a way that the BBB PRU's could be used instead of the UART instead perhaps, for the low level comms?

>> To unsubscribe from this group, send email to open-lighting+unsubscribe@googlegroups.com

[Rowan Maclachlan]

Hey Michael,

I kind of have to stop and wonder why (besides just because) spend 2 years on this, when you can get a $2 micro controller to go inbetween the uart or spi and a 485 driver.  You need a circuit in most cases anyway to convert uart output to 485, why not spring for a PIC or Atmel to offload some work onto...  

Plus a lot (not all) of uarts might not have a clock source that divides into 250000 baud without hardware modification... meaning all sorts of buggery or compromise for errors.

Add to that, USB DMX/RDM devices are so cheap that any professional and most hobbyist applications could budget for.

15 years ago I would have been right behind this... but now days, just doesn't seem worth reinventing this particular wheel.

I'd like to make an FPGA driven 32 port RDM ethernet stage rack - have some plans, some verilog written... don't have 2 years to waste though :( 

Still, I wish you luck should you take a crack at this!

Cheers,

  Hippy

[Michael Stickel]

On 07.10.2017 02:12, Peter Newman wrote:
> I was going to suggest you look at what the DMX4Linux guys did, but I
> see that's a bit redundant. :)

Yes, I could ask myself, or I could ask Doj ;-)

But it's the experience with DMX4Linux that tells me the pro's and con's
of doing things in the kernel.

> It all sounds great to me, I suspect it would be worth trying to
> target the Pi's UART initially if possible, given it's got such a wide
> install base and interest from people.

Agree.
I would say RPi, BeagleBone, as I have some experience with the AU335x
from a custom design my company did.

> I wonder if it could be coded in such a way that the BBB PRU's could
> be used instead of the UART instead perhaps, for the low level comms?

I have some ideas on how to do that. I would implement a "rich uart",
which feeds not only the octets, but also events into a queue.
These events can be break detected, frame error, parity error, rx
timeouts, tx fifo ready, transimmer empty and so on.
The DMX/RDM statemachine can then be very straight forward and even be
implemented in userspace.

[Peter Newman]

Hippy does have a point. Two years of work would easily fix the remaining Number 1 features (significantly less time I'd hope), giving a dual port device which could work on Linux, Mac AND Windows (making it appear in the OS is all we're missing on the latter). That's potentially a lot more powerful than something that only works on *nix. Although I guess there is something nice to be said for a RS485 daughter board for a Pi that then turns the device into a simple, compact DMX/RDM system, rather than dangling USB cables everywhere.

On Saturday, 7 October 2017 03:09:11 UTC+1, Hippy wrote:

Hey Michael,

I kind of have to stop and wonder why (besides just because) spend 2 years on this, when you can get a $2 micro controller to go inbetween the uart or spi and a 485 driver.  You need a circuit in most cases anyway to convert uart output to 485, why not spring for a PIC or Atmel to offload some work onto...  

Plus a lot (not all) of uarts might not have a clock source that divides into 250000 baud without hardware modification... meaning all sorts of buggery or compromise for errors.

Add to that, USB DMX/RDM devices are so cheap that any professional and most hobbyist applications could budget for.

15 years ago I would have been right behind this... but now days, just doesn't seem worth reinventing this particular wheel.

I'd like to make an FPGA driven 32 port RDM ethernet stage rack - have some plans, some verilog written... don't have 2 years to waste though :( 

Still, I wish you luck should you take a crack at this!

Cheers,

  Hippy

[Michael Stickel]

Hi,

On 07.10.2017 04:09, Rowan Maclachlan wrote:

I kind of have to stop and wonder why (besides just because) spend 2 years on this, when you can get a $2 micro controller to go inbetween the uart or spi and a 485 driver.  You need a circuit in most cases anyway to convert uart output to 485, why not spring for a PIC or Atmel to offload some work onto... 

I have an RDM USB implementation for an STM32 and it is cheap and you need a PCB anyhow but:
You have to write, test and maintain the firmware. No one else will do it for you, as you see with the Number 1.
You need tools to flash the firmware. At least some application that flashes the uC over a UART. On a RPi you only have one UART you can use for that. If you flash over SWD, you need an SWD-Adapter or you need some GPIO's on the RPi and an openocd with GPIO-SWD support for the RPi. Even if it is in simple for people like you and me, who have tons of JTAG and SWD adapters laying around, in real life it is easier to have a more discrete implementation and use the UARTs available. Both makes sense, each in it's own situation.

Plus a lot (not all) of uarts might not have a clock source that divides into 250000 baud without hardware modification... meaning all sorts of buggery or compromise for errors.

Then don't use them or build a custom card with a 16 or 24 MHz quarz. I't your own decision.

Add to that, USB DMX/RDM devices are so cheap that any professional and most hobbyist applications could budget for.

Everyone who writes some kind of Lighting Application has an interface or sells an OEM interfaces tailored for them. But there is no USB-DMX standard, like you have with USB-HID. I can plaster my kitchen with dmx interfaces. And there is no open source application that is as powerfull as grandMA, WholeHog, ETC ion, ETC eos, Avolites, .....

QLC+ might me good for life performance and you can run some small theatre stage, but for a real big show? I am not sure.

The Lighting Application is key. The interface is just an interface.

15 years ago I would have been right behind this... but now days, just doesn't seem worth reinventing this particular wheel.

I'd like to make an FPGA driven 32 port RDM ethernet stage rack - have some plans, some verilog written... don't have 2 years to waste though :(

This was a rough estimation if you refactor ALL linux serial drivers. And it was estimated if I would do it alone. When someone starts with the 3 most widespread platforms used together with RDM it is much less.

Do you plan to make a product with the FPGA implementation? I have one too in Verilog.

Michael