What's the best part for this job?

[SirNick]

What kind of silicon would you use to solve this problem?

I'm building an LED activity logic block for TTL serial.  Inputs are:

INACTIVE:  LOW = no link detected, HIGH = link detected
TX / RX:  LOW on idle, HIGH/LOW strobe with activity
RTS / CTS:  LOW = OK to send, HIGH = flow-control enabled
DTS / DTR:  LOW = OK to send, HIGH = flow-control enabled

I will have two bi-color LEDs per port -- one for the TX channel, one for RX.  Assume the LEDs are the reverse-parallel 2-pin type.  On each channel, the respective flow-control signals will be ANDed together into a signal I'll call FCEN.  That is, if both inputs are HIGH, FCEN is HIGH.  If either is LOW, FCEN is LOW.

The logic I'm trying to achieve is this:

If INACTIVE is HIGH, LED is off.  Otherwise:
If FCEN is LOW, the LED is red.  Otherwise:
If TX (or RX) is LOW, the LED is green.  If TX (RX) is HIGH, the LED is off.

Essentially, the LED is lit when there's a link, blinks with activity, and stays lit red when flow control is enabled.  I've implemented this with four AND gates, two with a single inverting input like so:

Code: [Select]

/INACTIVE >-------------------+------------------------------------+
                              |                  Green             |
             |\    +---\      | +---\          +--|>|--+    /---+  |
TX/RX    >---| )o--|    \     +-|    \   470R  |   \\  |   /    |--+
             |/    |     |--+   |     |--/\/\--+       +--(     |
                +--|    /   +---|    /         |  \\   |   \    |--+
                |  +---/        +---/          +--|<|--+    \---+  |
                |                                 Red              |
                +------+                                           |
                       |                                           |
              +---\    |                                           |
/RTS     >----|    \   |                                  |\       |
              |     |--+----------------------------------| )o-----+
/DTR     >----|    /                                      |/
              +---/
There's a cheap configurable logic IC with three inputs, that can be an AND gate, or an AND gate with one inverted input, meaning I can do the above with 4 of these ICs per channel.  Two channels per port.  Times 8 ports, plus one management port.  That's a grand total of 72 IC's -- quite a lot for some blinky lights.  They're cheap, at $0.40 apiece at qty-1, but still...  That's a lot of ICs, and a lot of traces.

Is there something on the market that would combine four or eight of these into one package?  I'm starting to look at cheap micros, but that seems like a sledgehammer solution.  On the other hand, it's simple, would allow configurable behavior, and I could replace 8 logic ICs with an ATtiny or something for the same price or less, and assuming onboard osc, using no external parts beyond decoupling caps (which I would use anyway.)

[nctnico]

Try and look at an MSP430 from the value line. These are extremely cheap, nice to program and very low power. With high efficiency LEDs you may be able to 'steal' all the power you need from the serial lines.

[SirNick]

Meh, they're interesting chips, but I can't seem to find any on Digikey that are any cheaper than similarly-equipped AVRs.  At the risk of being a fanboi, it's a platform I know well, so there would have to be a compelling reason to switch.  One thing the MSP does have going for it is that it'll run higher clock speeds at lower voltages, but I have 3.3v and 5v rails available anyway, and power consumption of all the silicon on the board combined is a pittance compared to the LEDs and Ethernet interface.

The more I think on this, the more sense it makes to go with a local microcontroller.  I ended up using an external UART IC per port pair due to some design constraints that have since changed anyway.  The cost savings from dropping the external UART and logic ICs would buy me a rather competent micro with an onboard UART instead.  (And then, at least it's not just an LED driver!  That just seems so excessive.)

[Harvs]

I'm starting to look at cheap micros, but that seems like a sledgehammer solution.

Perhaps 15yrs ago this would have been true, but now an FPGA would be a "sledgehammer" solution.

[DrGeoff]

An 8 pin soic mpu should do the trick and occupy little space on the pcb.
You can also implement pulse stretching for better LED display on fast baud rate TX/RX.

[SirNick]

You can also implement pulse stretching for better LED display on fast baud rate TX/RX.

That had occurred to me.  I wasn't sure whether to consider the inevitably different traffic / baud-rate patterns as a side effect or a feature... or really if it would even be all that noticeable.

So... none of you guys would look at a PCB with a micro solely for LED-blinking duty and think,  ".... really?"  (I'm sticking to my assertion that offloading UART duty to the micro makes it worth using the part, I'm just curious.)

[DrGeoff]

So... none of you guys would look at a PCB with a micro solely for LED-blinking duty and think,  ".... really?"  (I'm sticking to my assertion that offloading UART duty to the micro makes it worth using the part, I'm just curious.)

Nope. It's a part. It has 8 pins and it does a job. It's largely immaterial what's inside. Provided the constraints on cost, pcbreal-estate, power consumption etc are met. Firmware should be simple, so the long-term maintenance cost of this is likely to be negligible.

[Dago]

So... none of you guys would look at a PCB with a micro solely for LED-blinking duty and think,  ".... really?"  (I'm sticking to my assertion that offloading UART duty to the micro makes it worth using the part, I'm just curious.)

Nope. It's a part. It has 8 pins and it does a job. It's largely immaterial what's inside. Provided the constraints on cost, pcbreal-estate, power consumption etc are met. Firmware should be simple, so the long-term maintenance cost of this is likely to be negligible.

Nowadays something like a PIC10F200 is also so cheap that it is actually hard to achieve the functionality with any other solution at a similar price point. http://www.digikey.com/product-detail/en/PIC10F200T-I%2FOT/PIC10F200T-I%2FOTTR-ND/665882

In my opinion the only reason not to use a microcontroller for even simple stuff like this is if you do not have any other programmable devices in your device and it would add a programming phase to your assembly which might increase your manufacturing cost. But usually there is multiple programmable parts anyway and/or the addition to manufacturing cost is so small that it doesn't matter.

[SirNick]

The design uses a main microcontroller to provide Ethernet, management, and overall control duty anyway.  (I'm contemplating USB as well, since the additional parts cost is basically just a type-B port and a resistor or two.  Might as well, I guess.)  As it turns out, the original (main) microcontroller I was going to use (which dictated some of the earlier design) ended up not working out.  This resulted in a round of questioning the overall architecture, and thus the part selection of just about every major component on the board.

As a result, I should be able to remove all the LED logic and external UARTs, and instead put an ATtiny2313 or LPC812 on each port to blink the lights and provide flow control and a FIFO.  The main controller could easily store a copy of the firmware the port micros need, and during an upgrade, flash them via the SPI bus that it uses to communicate with them during operation.  The additional programming step is therefore a non-issue, aside from having to use a flash-host library on the main micro.  (Small price to pay.)

Overall, this should be cheaper, take up less room on the PCB, make routing a LOT easier, and allow for flexibility in how the ports behave.  I could probably even drop the 5v rail now.  Win win.  Thanks for the sounding board.  I think I'm good to go.   

[nctnico]

Why not have the main controller take care of blinking the LEDs? It sounds like an awfull amount of extra hardware and work to blink a few LEDs. Blinking the leds isn't a realtime task anyway so it shouldn't many extra cycles. If you don't have enough pins on the main controller use a couple of 74HCT595s connected to the SPI port of the main controller to create extra outputs.

[SirNick]

Well... for a good answer to that, it would probably help to visualize the system as a whole.  I'm working on an 8-port serial concentrator.  On one side you have 8x RS-232 over RJ45.  On the other, a single DB-9 console port (for management, and mux to any of the 8 inputs), an Ethernet port (for IP access to all of the above), and ideally USB for a virtual serial interface that would essentially mirror the DB-9 on the front (for the benefit of computers without a physical serial port.)

With a total of 9 serial ports, it seems like a bit much to ask of a single microcontroller.  There aren't enough integrated UARTs in any that I'm aware of, and bit-banging that many signals seems like an awful lot of trouble.  I had originally offloaded the RS-232 stuff to external UARTs with an SPI interface back to the uC.  That took care of baud-rate generation, frame detection, flow-control, and a small FIFO... significantly reducing the time-critical stuff the uC would otherwise have to do.  But I would have to handle LED activity elsewhere -- and the blinkenlights are important here.  Not just because they're cool, but link lights really help to see that you are indeed using the correct cable pinout for this combination of devices.

So back to your question...  If I go back to outboard UARTS and have the host uC control the LEDs, I would have to make the uC aware of all the I/O-level stuff again -- a burden I was trying to ease by using outboard controllers in the first place.  Not to mention the pin allocation and traces for TX, RX, CTS, RTS, DSR, DTR, INVALID, LED TX+, LED TX-, LED RX+, and LED RX- ... per port, while the management port adds CD and RI on top of that.    The micro I plan to use could probably pull it off with the high pin-count version, but the code would be a mess, and it would probably spend half its life in interrupt handlers.  OTOH, the LPC812 is like a buck fiddy apiece... cheaper than the SPI UART I had planned to use, with LED logic thrown in for free.   (Provided I keep the current draw to 5mA.)

[nctnico]

Ah. That makes everything a lot more clear. The last time I needed a lot of UARTs I used an FPGA connected to a processor and used the 16550 clone from Opencores. I don't know whether there is lots of processing required but if it is simple you could use Xilinx Picoblaze mini processor and make a system based on one FPGA which does the routing of the serial data. The UART from Opencores isn't a fantastic design but it works and it is an easy block to use. An extra controller could handle the management part (ethernet).

I wouldn't bother too much with blinking the LEDs. If your controller can see there is some data then light the LED for a short while it should be enough. Don't make a realtime task out of it!

[SirNick]

Wise advice, and I agree.  That's why I was a little hesitant to throw even a small microcontroller at the task.  It just seemed like a waste of so much engineering prowess that went into designing a tiny IC with a dozen peripherals and a KB or two of RAM for the sole purpose of making an LED blink.  From an economic and user experience standpoint, it makes sense.. it's probably the smallest, cheapest, simplest-to-design-with device that would accomplish the desired behavior.  But still the kind of thing that make me pause and bite my lip.

Another thing that changes the perspective of this project:  I'm not an experienced EE working on a commercial design.  This is a hobby project intended to make my professional life easier (by having a nice, portable serial console management device), give me a puzzle to solve, practice SMD design, and give me experience with technology I haven't implemented before (Ethernet, USB, ARM...)  Price and manufacturability are only a concern to the extent that I can justify the effort and expense to myself.  All in all, the parts and prototype(s) are likely to be cheaper than a commercial box of reputable make (e.g. Raritan), but that's secondary to my real motivation for building this thing.

That said, I feel like FPGA is still a little beyond my ability.  I'm excited to learn them for sure -- but attainable goals are important, and I think that kind of leap would leave me frustrated and a few hundred bucks poorer without any significant educational progress to show for it.  Some day...

[nctnico]

Hobby projects are always good even if you don't finish them. I have several unfinished hobby projects from which I made lots of money because of the experience I gained by working on them.

It depends a bit on how much time you have on your hands. I always advice to use one microcontroller which can do all the tasks. Making multiple microcontrollers work together isn't as straightforward as it seems.

[SirNick]

Time's not much of a consideration.  I envisioned this project about a year ago, with a much different architecture.  Project goals, feature set, and core parts have evolved several times since then.  I would like to have a working product in my hands, ideally by the end of the year, but other than my own interest, there's nothing riding on it.

If you are interested enough to offer suggestions, here's what I have so far:

Core uC is an NXP LPC4078, with Ethernet MAC connected to a Micrel RMII PHY.  USB PHY is integrated if I care to use it.  (I'm going to try, and will definitely plan for it in hardware, even if it is not functional in the initial firmware.)  It has a few onboard UARTs, but not enough to stand alone.  UART0 is going to be reserved for flashing the main uC via the ISP bootloader.  UART1 will be connected to the mgmt port, since it provides modem signalling as well.  UART3 will be for flashing downstream micros.  (More on that in a sec.)

As it turns out, the NXP LPC812 comes in a 20-pin package that is perfect for the port controllers.  It can be flashed via UART0, which will connect to the main uC UART3.  The 812's UART1 will drive the TTL-to-RS232 transceiver.  The 812 will also drive the LEDs, since it has all the signals and plenty of spare cycles to do so.

Communication between the main uC and the ones at the ports will be via either the UART(3 and 0 respectively), or I have two SPI channels available on the main uC -- I would use one for ports 1-4, the other for 5-8, just to reduce bus contention.  I should have adequate bandwidth with either interface, even if all ports are running at 115,200 (my target max baudrate), but SPI would have the most headroom.  If I use the UART for the data bus, I'll either have to treat it like multi-drop RS-485 or selectively tri-state the inactive nodes based on a slave-select signal.  If I use SPI for the data bus, the main uC UART3 will still be connected in parallel, but disabled (tri-stated) except when flashing the downstream controllers.  The 812s support dynamic peripheral pin assignments, so the TX/RX pins can be assigned at run-time.

So that's where I'm going with this.  I don't know of any way to get this kind of port density with a single micro without resorting to 200+ pin-count devices and bit-banging the serial interfaces.  Using external UARTs means going with SPI -- pretty much the same solution as I get with using per-port micros, except without the free LED control, and at about 150% of the cost.  FPGA is off the table for now, as cool as it would be.  That's just biting off more than I can chew at once. 

In my shoes, would you do anything different?