microcontroller networking

This is easy as long as th same data is broadcasted to all nodes. However, if selective data needs to be transmitted to different nodes, the protocol needs to define a node address and there must be a mechanism to assign individual addresses to the nodes using e.g DIP switches.For amy voltage based system, just connect the receiver in parallel, for a current loop system, put the optoisolator LEDs in series.

This doesn't work for standard RS-232 or RS-422 connection, unless you use the diode trick. Neither does it work for ordinary TTL, In all these cases, both states are actively driven.

Open collector TTL works fine, as long as the idle state is defined as High. When using open collector NPN and open collector PNP on the inverting output, you effectively have a CAN bus. In a current loop, in the idle state, each series connected transmitter must pass the 20 mA loop current.

RS-485 and tri-state TTL are also easy, simply put the idle transmitter into idle tri-stste, effectively isolating the transmitter from the bus.

The OP is talking about microcontrollers. I assume he has enough control over the outputs to achieve this.

Sylvia.

I was amused that someone suggested using an FPGA for something here the other day. I suppose it's just what people are used to.

But MCUs do seem to be very practical and cost effective for anything that doesn't need very high performance.

Sylvia.

r output

ps or

That was probably me. I find MCUs to be a PITA because of the complication s of trying to emulate parallel operations with a sequentially executing CP U. Yeah, they can be used and for very simple stuff they are easy. But so are FPGAs and they don't get much more complicated when you have a lot mor e stuff to do in parallel. In fact, they just stay the same. I also find them a lot easier to debug using the simulator and seldom have any issues t o work out on the hardware. 99.9% of my bugs are caught in simulation.

To each their own, but I haven't used an MCU in some years now.

Rick C.

The application idea is essentially an N-way RS-232/serial splitter where an input "packet" can be routed from the input to any output, user-configurable, and the packet might need to be processed/edited on the way through then drive another length of cable.

data rate is not particularly high in the 10s of kbps but low latency/deterministic timing is important so I think I'd prefer to use a hardware UART on the output side rather than bit-bang.

The KISS solution that occurred to me is just use a UART-i2c bridge on the input and route the input packets via i2c to N 8 bitters with an i2c input and a UART on their output and have each responsible for their own output.

Dev time is also a factor I can probably have a prototype of a system like that up and running before I can even get an appropriate ARM dev board in the door. prolly a little cheaper to have a f*ck-off ARM do everything but eh client is not needing thousands of these /shrug

"workload sharing" among dinky processors is probably not required for this application but just a fun concept to think about (but likely offers few advantages given that powerful ARMs have become so cheap.)

Sure, you can bit-bang serial, even pretty fast serial nowadays. But if you need 4, 8, 16 etc. serial outputs at a pretty fast rate it would seem that eventually your mpu ends up spending a lot of its time bit-banging serial.

If you want tight timing you have to have timer interrupts and every time a timer interrupt for one of the virtual output ports fires stop everything you're doing, do a context-switch, service the ISR, fiddle the bits, restore state, etc. it's not a particularly low overhead solution.

Also from a given MPU master clock not every baud rate is easily available to good accuracy from a nice rational-number-coefficient divide-down from the master clock.

Actually not. It was my customer asking for the 28 processor behemoth, and I was my own boss then (now retired).

--

-TV

s d .

on.

I'm not sure a "software UART" has to be so labor intensive. If all the se rial ports are at the same bit rate you can simply set a single interrupt f or your sampling factor (say 8x bit rate) and read all the inputs in one wo rd at the same time. Some DMA units would be able to read this automatical ly even reading a burst of enough samples to process a bit per burst. Then it is a matter of the software sorting through the data to accumulate bits into framed characters, characters into messages, etc.

Assuming you can read 32 inputs in one operation collecting each bit would be a matter of an 8 sample DMA.

Yeah, the software would be interesting to do this way, but you don't seem to want to consider how easy software UARTs can be. I'm not a big proponen t of using Interrupts on MCUs because of the way they get complex fast with different priorities, etc, but multiple UARTs are a lot simpler than you s eem to want to think they are.

I was just researching the FPGA options and there are viable FPGAs for just over a dollar in QFN packaging. I have to refresh my recollection periodi cally so I can keep up with how inexpensive these things really are. Oh ye ah, this part has a hard I2C and SPI interfaces built in so you only need t o design the UART and connection logic.

Rick C.

A uart will work with a clock rate 8x the baud rate. So for 9600 baud you could use a periodic interrupt of 76.8 kHz. That's no big deal these days. The ISR could do, say, 16 UART i/o channels, given reasonably efficient code.

--

John Larkin         Highland Technology, Inc 

lunatic fringe electronics

Sure, there are always limits.

I have used nops to fix timing...

Baudrates have a very large error tolerance.

An other example is PWM outputs, here I use hardware PWM:

but that needed 3 PICs 18F14K22, each has only one PWM generator. The reason I used hardware PWM and 3 PICs in the RGB thing I build was to prevent flicker when UDP data was processed, but using different PICs for R,G,B created an other problem however, clock interference.. So now the slave PICs clocks run from the the main PIC clock output, all PWM for R,G, B is then in sync again,,,,

But you can do multiple PWM in software too, older project:

then you do not have those sync problems...

Or here one old PIC driving op to 4 RCservos:

It all depends on the application, programmer, weather, parts available, budget..

So basically it is good to know how to use both systems, hardware and software.

For SPI and I2C there is not normally a time constraint.

BTW the old way to address many chips listening to the same serial data was to use 9 bits, when bit 9 was set it was an address, followed by the data with bit 9 reset.

Sure, for that price if you have suggestions I'm all ears...

I'm a fan of occasionally using say two "networked" uPs working in tandem to accomplish a larger task that needs somewhat more say PWM channels, output pins, EEPROM, or suchlike than a single 8 pin uP has. One just kinda functions like an IO expander. Done it before with the ATTiny series and it can come in cheaper in some circumstances than stepping up to the next-more-featured device series.

But beyond a couple slave units I think any advantages quickly evaporate in most use cases.

The baud rate I need is going to be tens of kbps, at least 50kbps. on the plus side I only need multiple outs, not ins. 8 channels of 50 kbps RS-232 type output, plus data-massaging on the way thru for each channel if the user selects it. it's asynchronous/intermittent though so on the upside not every output channel is likely to all be running full blast simultaneously.

Yeah I suppose an ARM Cortex can do it all but grumble grumble. I've done ARM development but I don't much love it and thinking about writing bit-bang multiple out serial code for a mystery-meat ARM makes my heart a bit heavy.

One of the nice things about them simplistic modern 8-bitter RISCs is that you can fit everything there is to know about them in your head and there are few "gotchas." The full datasheet is only 300 pages long not over a thousand.

By comparison I've already got one channel up and running as a prototype and it only took me about two hours of development time. For very high volume the choice is pretty simple use the cheapest part that can do the job and suffer. For one-offs the choice is also pretty simple use what you're most comfortable with that can do the job, don't worry what the chip costs, and get it out the door, the parts cost isn't shit compared to total budget.

It's the low-mid volume decision stuff where the trade offs - cost vs. ease of development vs. development time hurt my brain

To clarify by "total budget" here I mean _your fee_ if you're a one-man outfit ;)

re

is

eed

se.

e f

ution.

output is dead simple and only need to run at the baudrate

the only code that is MCU specific is how to setup a timer and how to set/clr a pin, 99.99% of the code is going to be exactly the same no matter what processor

It depends, if you have choice of baudrate and are transmitting only, then the fastest baudrate you can make is the best, In that case no interrupts, just the 'bit test / send, shift byte, delay (with nop) loop' to transmit a byte, And that TX byte can then be done from where ever in your program. You can make that re-entrant too, and even delay a tasks witch if it is a multi-tasker. At 460800 Bd, 1 bit takes 2.17014e-06 s, 2.17 uS, 8 bits 1.73611e-05 s 17.36 us Even the little PICs I use have a 64 MHz clock...

Unless your main program is in a big hurry sending some bytes with an in-line subroutine or even macro is not a problem. No interrupts. Or only interrupts... There was 'Viper' once, a system without interrupts. I have several projects that do the opposite, interrupts only, nothing in main. When interrupts do not interrupt interrupts, then that serial out will still work OK, no context save needed. For RX if those are replies you could than also use the only available hardware UART, when you make the receivers reply only after being addressed (wired OR). Not saying do it that way, but pointing out strategies.

,Some general observations about hardware/software UARTs.

Someone suggested using the old 9 bit system, with the address flag set only on the first byte (i.e. 8051 style). This makes sense only if the system contains multiple slaves, each with hardware UARTs and a separate interrupt for the 9th address bit only. Initially with only address bit interrupt enabled, the first address byte generates an interrupt, which checks if the whole message belongs to this slave. If it belongs, enable ordinary byte interrupts to read actual data. If it doesn't, wait for next address interrupt, thus reduce slave interrupt loading. This system makes no sense with software UARTs.

Regarding bit rates, 9600 bit/s is often quit sufficient in many cases, especially i humans are in the loop. The 9600 bit/s is 960 bytes/s so even with a few multidrop slaves, there would be 240 bytes/s/slave with 4 slaves. If 1-2 updates/s is sufficient, this would be about 100 bytes/slave with a primitive but effective protocol.

There are of course multiple ways to implement software UARTs. One is an interrupt generated by the falling (mark->space) edge of the start bit, then disable edge interrupt, start 1/2 bit time timer to sample the middle of the start bit and then set 1 bit time timer to sample the mid points of the data bits.

If you can get interrupts on both input edges (H/L and L/H) just count the time between interrupts from a high resolution timer and from this, find out which bit is transmitted. With NRZ data, less than one interrupt/bit will occur on average. With some self clocking (e.g. Manchester) signaling, there will be 1-2 interrupts/bit, the timer accuracy requirement is mediocre.

The use of constantly sampling at 8x or 16x the bit rate makes sense only with more than 8 serial lines. For transmission, only 1 sampling/bit is required, even with a large number of lines. if dissimilar processors are used, it might even make sense to have different data rates in different direction.

Just other day, I was pondering the merits of installing an MCU core onto an FPGA, as a way of avoiding premature obsolescence for work put into programming an MCU.

Not a problem I face, but just something I was musing.

Sylvia.