Poor man's UART

center alignment on every transition should also work

I just realized there is a wrinkle. If you want to use the start bit in the shift register to flag run/stop it has to be there as soon as the bit center counter starts. So you need extra logic to enable the register on the edge of the start bit, but not the center. That will be messy! lol

Looking for the start bit saves the bit counter, but not the run/stop flag register.

--

Rick C

STM32F030F4P6

How poor did you have in mind?

--
Mike Perkins 
Video Solutions Ltd 
www.videosolutions.ltd.uk

So you are going to use a FF to detect transitions? Why not just use it for Run/Stop? You seem to be determined to not use a Run/Stop register bit, but I don't see how to make it work. There is a reason why UARTs came as LSI functions, mostly the 'L'.

--

Rick C

This thread is very interesting in it's meandering all around the spec. What spec you say? EXACTLY! Every design starts with a COMPLETE statement of EVERYTHING it has to do with volume, cost and development time constraints. What are you going to do if you get the start byte and another start byte without the end byte? Sounds simple, but EVERYTHING needs to be defined. WORST case inputs need to be defined.

While conceptually trivial, the UART is a big bucket of worms, most of which you will discover trying to implement it. The devil is in the details.

Hint: "low-ish" is NOT a specification and predicts that the cavalier approach to the problem statement will result in a disaster.

Rant on: If you're gonna design anything electronic these days, you should at least consider using a microcontroller. Once you have a breadboard setup and a high-level programming language, many things will be trivial to program and just work. And if they don't, you can patch the code. Use the controller for everything possible. The stuff that's too fast or too high voltage or current gets done in separate components. UARTS are built into many microcontrollers, assuming you are using ASCII at standard formats and bit rates...see the spec... oh right... Rant off:

What's your definition of the "poor man"? Lotsa ways to be poor and many affect the design.

Are we having fun yet?

Yes. OTOH, the OP may simply be looking for general information to guide his thinking on a *possible* approach he is considering.

If, for example, he was thinking about snooping ATM cells for specific data, it would be a relatively high bar to meet without some software assist. I.e., the first bit of advice might be: "design an easily programmable FSM to drive the logic" (which one might read as "use a fast microcontroller")

Start *bit* ultimately followed by stop bit(s). Though it still begs the question of how you recover from a framing error... How do you handle a long space? etc.

OTOH, microcontrollers tend to have a "minimum entry fee"; you can often beat that on custom logic (quantity) *or* improve obfuscation (raise the bar for or delay counterfeiters). And, you can tend to ensure the device's continued availability (microcontrollers come and go with some frequency)

Sure, anything's possible. ;-)

You won't save space, let alone cost, doing it discrete though. More than, probably about four chips (maybe even fewer!), you're better off with a tiny FPGA instead.

Suck it up, old fart! Go get a cheap dev kit, they're starting under $20 these days. Force yourself into it! You /need/ this skill.

If you have the luxury of controlling the signalling protocol, you can opt for SPI, which can drive a basic 74HC595, say, and then some comparators or gates. That's feasible with discretes, though still not "small"!

Related story: I once put a custom serial *transmitter* inside a CPLD. I forget how many macrocells it used, probably 10 or 20 including the baud rate divider. (Along with the other stuff, it fit snugly inside a MAX3064.) It transmitted status bits, which is really quite easy for a CPLD to do: it's a bit counter attached to a mux, so it transmits each status bit as it goes. (You can latch the status bits if you like, before transmission, to prevent them changing during transmission. :o) ) But a /receiver/ will be much more complex, for the reasons that others have covered.

Tim

--
Seven Transistor Labs, LLC 
Electrical Engineering Consultation and Contract Design 
Website: http://seventransistorlabs.com 

"bitrex"  wrote in message  
news:IOf6A.285791$HF2.183087@fx41.iad... 
> Is it possible to build a "poor man's UART" to look for a specific 
> byte in a low-ish speed current-loop serial bitstream? 
> 
> Like use a serial->parallel shift register with a fast clock and a bit of  
> combinatorial logic to trigger on the appropriate 8 bit word output?

The sad fact is that you're going to get the most logic for a money unit by buying a single chip processor.

For your speed range a small Cortex chip is more than sufficient, and it is hard to beat in price by either a progeammable logic chip or a bunch of SSI chips.

I have done a 31.25 kbps Manchester encoder/decoder and packet interface (IEC H1) with a Cortex M4 running at 50 MHz clock, and the task is for sure much more complicated than yours.

--

-TV

If you look at a CPU as logic, the beauty of a CPU is in the fact that the logic in the CPU is reused for many tasks by serializing them. State is stored in the memory which is *hugely* efficient in terms of space and power. So a lot of otherwise slow processing can be done very efficiently this way. If memory wasn't so low power or space efficient the random logic of an FPGA would be a lot more attractive because of the ease of designing many tasks with separate logic. I find it odd that FPGAs have a reputation for being hard to program. I find them much easier to use because I don't have to juggle many tasks on one processor and all the problems that presents.

Here is some irony. FPGAs a long time ago gave up "long lines" with tri-state buffers. Memories still and likely always will use them for the multiplexers.

--

Rick C

You can buy small CPLDs/FPGAs for _much_ less than an M4. M0, maybe. OTOH, a PIC for such a trivial exercise will be much less than either. The OP doesn't want to do anything reasonable, though.

Why is that an irony? It's perfectly obvious why. Different use, different needs.

I've done my share of software uarts in the past. Not that hard.

16x over sample and some voting logic works well. If you have a some what repeating byte(s) in the stream it's not that hard to autobaud. Build a correction lookup table with the off timing patterns. I've used 0x00,0xff,0xaa (or 0x55) sequence to help lock the clock.

If you really want to do it in hardware you can do a x16 sampler followed by a up/down counter and a SR along with clock and glue logic.

--
Chisolm 
Republic of Texas

That all seems very much over the top. Why not check for stop bit edge and sample at the relevant times from that?

--
Mike Perkins 
Video Solutions Ltd 
www.videosolutions.ltd.uk

' This is sci.electronics.design! Posting a 100% accurate spec which invites a simple, cookie-cutter solution (use a uP, dumbass) is against the rules.

I find I learn more reading people debate the merits of different approaches. That's where the fun is! I hope that's okay..

Disaster is my middle name!

I've programmed a lot of microcontrollers. :-(

A 16x clock is not needed for a software UART. Either in a polling loop or using an interrupt on each edge, the CPU will be aware of the leading edge very soon after it happens. It then only needs to time to the middle of the start bit and Bob's your uncle, only bit times need to then be measured.

--

Rick C

A 16x clock is commonly used to increase noise immunity. The bit is sampled three times and the majority is taken. Only the OP can know his noise environment, but MIDI systems are often operated in noisy environments.

This is a solved problem - a poor man's UART is just a UART. Use an existing one, only a rich man would try to make one.

yeh, if the mcu doesn't need to do much else just a big loop that busy waits for a startbit and the times bit periods with NOPs

that also means you don't have to figure out how to setup timers or interrupts

MIDI is a current loop, so should be pretty immune to noise electrical noise.

+1 This whole thread is ridiculous.

To me the easy way is to use an FPGA. Nice and simple, no need to fuss with timing loops and software irregularities. But I can't see messing with discrete logic. The only reason to use an MCU is that it integrates more of the system into one chip.

--

Rick C