cancel
Showing results for 
Search instead for 
Did you mean: 

Dominant/Recessive state support for UART

flyer31
Senior
Posted on March 25, 2014 at 17:48

A wish for new chips: It would be nice if STM could consider to implement a UART which supports bit-wise arbitration, as it is required for KNX / EIB networks.

KNX/EIB of course is a big market, but this functionality would be also very nice for any other network - it then allows collision-free data transfer on UART channels (only requirement is that you use a PHY with recessive/dominant state, you can just any CAN transceiver or LIN transceiver for this).

Currently I consider to do it with a ''slave processor'' who handles the complete data transfer itself ''bit for bit''. But this of course is a bit cumbersome (it would be nicer of course, if an STM32 dual core would be available similar to the LPC4300 ... but as my application is quite cost sensitive I would by far prefer an STM32F0 or STM32F1 chip which includes a UART with bit-wise arbitration functionality).
14 REPLIES 14
jpeacock2399
Associate II
Posted on March 25, 2014 at 21:13

Thing is, if you already have the CAN transceiver then why not use CAN for everything?  Sounds like you're asking for UARTs to duplicate the functionality of the CAN controller.  CAN is already there, has the buffering and priority FIFOs and works very well up to 1Mbit with not a lot of CPU overhead.  If you did the same with a USART you'd have to use DMA, aong with all the arbitration logic to stop DMA if there's a collision.

I've neve come across the KNX/EIB setup (mostly in Europe?) but it looks to be more of an X-10 legacy requirement for backward compatibility rather than something new and compelling, especially compared to CAN.

As for dual cores, yeah, providing the I and D memory paths aren't on a shared bus.  Otherwise memory contention kills any benefit.  For myself I'd prefer more DMA channels, bigger cache and more useable timer pinouts rather than an M4/M0 dual core.

32 or 64 filters for the CAN peripjheral would also be nice, make it much easier to implement CANopen SDO Manager, multiple SDO servers and implementing PDOs past the 4 predefined PDOs if there were extra filters to map individual identifiers in 11 bit mode.

  Jack Peacock
Posted on March 26, 2014 at 02:30

Still sounds like rather a niche requirement, with very high volumes, and very low cost, surely an SoC would be the most practical route. ST does huge volumes with the White Goods, and Apples of the world.

Are you sure there isn't some start-up somewhere that's slapped an M0 core, with an KNX/

http://www.rushlimbaugh.com/

transceiver?
Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
flyer31
Senior
Posted on March 26, 2014 at 09:28

The only (and first) company with a KNX microcontroller currently is Renesas (see uPD78F053x, http://www.opternus.com/de/siemens/knx-chipset.html). If you call Renesas a small niche market supplier, then you have a good humor :). And their entry into the market is quite fresh, I think this uPD78F053x is just in market introduction phase.

But this controller then also has PHY and Layer 1-2 support for KNX included. Doing an inductorless PHY for KNX/EIB on Silicon I think is quite heavy and needs much Silicon area. This really then strips the market share for such an application down to narrow niches.

But there is a nice proposal for a PHY made of discrete components on http://www.freebus.org/content/freebus-grundschaltung?language=en (sorry, only in German available), which seems to work nicely.

Now to get full suppport from the controller side, the only thing is a trick, that the controller will stop a data transfer on the bus, if he recognizes that one of his recessive bits (1) was overridden by a dominant zero from some other transceiver on the bus.

For God sake, the KNX bus on the line segment has a fix baud rate of 9600 baud (don't be anxious - the line segment is only for the sensors / actors TP-1 segment, and as soon as the signal reaches the router, then it will typically continue with Ethernet speed ). So at 9600baud one bit time is about 100µsec, which is very slow for an ARM processor, so I possible really do not need a ''slave controller'' for this bit arbitration. I think I can do it with a capture input / high priority interrupts of a timer. But anyway it is quite a fuss. The arbitration time of KNX bus is the first 3 bytes for the standard message (0-16 data bytes), and the first 4 bytes for the extended message (up to 250 data bytes - usually only used for configuration/boot load). As KNX bus runs with parity (+stop+start bit as for normal UART), 4 bytes mean 4x11 bits = 44 bits (this means MINIMUM 44 bits - of course it would be no problem from KNX side to apply bit arbitration to the complete data frame, but if I have to do bitwise arbitration with a timer, of course I will stop after these 44 bits). This unfortunately is much longer than the CAN arbitration field of only 23 bits (I considered already to use the CAN for the first 23 bits ... perhaps I will do it, as possible 44 high priority interrupts by the compare timer will be quite a throttle neck for the controller).

If you compare KNX to CAN, you have quite a bit of severe advantages:

- The arbitration is much better - there is about 50 bit times pause between frame end and arbitration byte, and the arbitration is a complete byte (thus you have not only ACK and NAK, but also BUSY, which is quite useful for configuration/boot load purposes). This ''more relaxed'' arbitration gives also the large advantage, that you can use repeaters on the bus, so you can build very large networks (which of course are required in buildings). But the possibility to use repeaters of course is a very nice ''add-on'' for any network - this is quite a severe drawback of CAN (that CAN cannot really support repeaters due to the ACK bit in the last bit slot, or only in some very restricted way).

- The KNX bus has this very nice feature with this TP-1 ''24V power line'' access. This is quite ingenious for simple sensors with max. 10mA - in a typical house application you have tons of such sensors. And it supports a VERY chaotic topology, star, line, stubs all ok (just no rings). If you look at a sensor/actor network in a building, then it nearly always will be VERY chaotic, at least after the first building extensions :).

- The KNX protocol is much more flexible with 0-256 bytes data load. The 0-8 bytes of CAN is a nightmare for any software engineer who wants to include some flexible configuration possibilities into the bus.

If you think of adding such a bitwise arbitration to a UART, I think on chip level it should really be a snap. You mainly need 1 transistor to switch off the UART-TX, you will need another transitor to compare the RX to the TX after each bit time (directly after RX bit read - I do not think that you need a further timer for this). And you need a flag in the UART status register which tells you, whether your signal lost arbitration or not.

The KNX protocol further defines some very strict timing specs for the distance between the end of transmission of the data frame and the arbitration byte. But this in STM32 chips can be already nicely met by using the IDLE interrupt (which is a very nice feature, thank you to STM for this).

Andrew Neil
Chief II
Posted on March 27, 2014 at 00:33

''I think onchip level it should really be a snap''

So why don't you do it, then?

Be that startup!
Posted on March 27, 2014 at 01:17

Many silicon vendors service niche markets, rather the question is whether such a peripheral should eat a large area of silicon in a general purpose micro-controller, where the cost is borne by all, and utilized by a fractional portion of the customer base.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
flyer31
Senior
Posted on March 27, 2014 at 08:09

Sorry for the ''snap'' ... I must admit that for ME it is not a snap :).

I just wanted to say, that it would need only a minimum amount of chip area.

I am very sure that this is NOT restrictred in any way to a niche market. On one hand KNX is no niche market, but currently growing very strongly. On the other hand, this arbitration would be useful for any UART which uses a dominant/recessive state transceiver.

Such dominant/recessive state transceivers are readily available:

- CAN transceivers for 2 data wire connections, working up to > 1MBaud

- LIN transceivers for 1 data wire connections, working with up to > 100kBaud

- the simplest 1 data wire connection between several processors is just a short-circuit on RX and TX, TX output set to open drain, and one external pullup resistor (as done also in I2C with 2 wires)

- zero data wire connections (=power line connections), using some simple discrete bus access as described in http://www.freebus.org/content/freebus-grundschaltung (sorry for only available in German - the receive circuit is in ''Die Empfangsstufe:'' and the trasmit circuit is in ''Die Sendestufe:''). (To achieve a reasonable baud rate for power line connections, the power supply should contain some current limiting scheme, in KNX bus usally a large inductor is used).

If the controller UARTs would support this dominant-recessive state support, then it is a snap to create a collission-free data transfer in any of these UART connections.

... this should be very interesting for very many people in future ... I am a bit frustrated that nobody is supporting me here ...

Posted on March 27, 2014 at 12:54

Niche is not a bad thing, I think micro-controllers with special features for HDD controllers are niche, they sell perhaps hundreds of millions of parts into the market they service. Chips used in cars are also niche, they work in very hostile environment and are expected to keep functioning for 10-15 years. Creating yet-another wire standard, instead of using existing ones, is by definition going to have trouble gaining traction, and escaping it's adopters.

It's also European centric, does Philips/NXP have a solution? As far as I can tell it has no penetration in North America, but I'm not in that market space.

While the feature might be of general use, in it's intended or other forms, I'm not sure it's practical to back-fill into an existing range of micros, it would be a stand-alone like the STM32W108, also a niche product (Zigbee/Radio), with a potentially huge market, yet practically no traction or support.

My question would be why can't this problem be solved with CAN or 10BT? Or the dozens of power-line protocols that seem to have come/gone over the last say 20 years?

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
Posted on March 27, 2014 at 13:26

I am a bit frustrated that nobody is supporting me here ...

The pool is a bit shallow here.

A simple UART has a very LOW gate count, I'd hazard that the CAN controller is at least an order of magnitude more complex.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
Andrew Neil
Chief II
Posted on March 27, 2014 at 14:25

I am a bit frustrated that nobody is supporting me here ...

Maybe that says something about the actual demand for this...?

Sounds like the kind of thing you could ''prototype'' on something like a PSoC, and see how it actually sells. If that demonstrates a genuine demand, then you might have a better chance...