Bit streaming for comms

[Buriedcode]

Hi,

This is a pretty basic quesiton, but I can't seem to find a satisfactory answer, and considering its used in almost all digital comms, I thought I'd try here.

Without designing custom IC's, or using programmable logic (FPGA/CPLD) how exactly could one 'stream' bits for wireless or wired communication?

What I mean is..say we have to send: a preamble, start of frame, payload, and error check. Now, how exactly could one get this into a serial format without gaps between the data? Using a basic microcontroller (which isn't fast enough for my app, just an example) the only way to do this would be to use 'bit banging' entirely in software. A USART would either add start and stop bits between bytes, or leave a gap (as would back to back SPI).

So, do all these ASIC's for USB/ethernet/wifi simply have a shiftregister to output these bits or is there some standard I'm not aware of? where one can load in a byte or 2 and it would send it serially.

As I said, really basic question, but I haven't found much information on it, as few datasheets (or standard protocols) go into this sort of detail with the 'phy' layer. I've already asked in the microcontroller forum, but most micro users want low-bandwidth links that UART's can cope with, I would like to be able to design a fairly simple proprietary protocol from the ground up without the need for custom IC's or expensive programmable logic.

Hope someone can help,

BuriedCode.

 

[lambtron]

You may not find a "phy" device with this capability because all serial communication devices include some sort of "framing." This feature is always present so that you can resynchronize if there is an error, which there will inevitably be at some point because the bit-rate error can never be zero.

You could, of course, build a state machine from ttl/cmos msi parts to do this job, but I sense that would violate the spirit of your specification.

 

[Buriedcode]

hi,

sorry for the late reply, forgot to check this topic..

You could, of course, build a state machine from ttl/cmos msi parts to do this job, but I sense that would violate the spirit of your specification.

Heh, 'violate the spirit of your specification', I like that...its true as well. I have used a CPLD, and considering I don't really have any background in desinging comms chips per se, I just used common sense. . .

An 8-bit shift-register, with a buffer that automatically loads the SR with the next byte, once the first has been sent, so I can 'stream' bits continuously for ever, without any gaps in timing (as long as I provide bytes). Of course, the 'framing' you mentioned would simply be a byte of preamble, and a 'sync byte'. I was going to use 'manchester encoding' on-the-fly (encoding one bit at a time) but in a microcontorller, its just easier to use a look-up table.

I suppose I could use a UART, and send manchester encoded bytes using that..since the start and stop bit are zero-DC anyway (0-1) but I haven't seen any commercial standards that use this (like 802.xx, zigbee, keelog etc..). they simply send 'bits' usually bytes back-to-back.

I was hoping to find a microcontorller that can do this (and yes, I have checked the microcontroller forum, no-one answered) my only alternative is to do it entirely in software, which is hardly efficient, even on an ARM9.

Thanks again for the reply, its an odd question, and it seems that if anyone wants to design a wireless device for over 2MB/s and have complete control over the protocol, the only options are FPGA/CPLD and ASIC - both are expensive.

So, I will continue my search.

BuriedCode.

Ps, Just thought......using an external shiftregister, and using a micro's PWM to clock it...one would only load the SR once every 8-bits, and the clocking is done automatically......methinks I'll get my breadboard out...

 

[PaulHolland]

'bit banging' if your using normal microcontroller otherwise use serial (NOT UART - That is Asynchronous data) synchronous controllers like the Z85C30 from Zilog. No gaps or what ever !!. You can use this chip also in plain mode, that is "shift register" mode with only CRC calculation and sync function !!. I also used it as a nice shift register byte wise.. works perfect and fast. Supports DMA etc..

Paul.

 

[Buriedcode]

Hi, thanks for the reply,

NOT UART - That is Asynchronous data

Yep, but most micro's have 'USART's, which can be operated in 'synchronous mode'. But, unfortunately, even though it is true synchronous...my PIC micro seems to leave a 'gap' of one bit period between bytes, which isn't clocked which is fine for true sync comms, but I'm just using the data bits (no clock, its embedded in the data).

Z85C30 from Zilog

Interesting...I didn't know these sort of chips were around... Probably 'over-kill' for my app (no CRC, or DMA, all in software) but still small enough for a transmitter, and ideal for my reciever!

Thanks for the advice...I'll see if I can get samples for it.

Regards,

BuriedCode.

 

[PaulHolland]

Hi Buriedcode, I know a much better way. If you use your PIC as serial controller you should not have gap's. but a different possibility is using a flip, flop D Type. OK. Connect the clock line positive edge to the D flip-flop clock input (clock can be made locally by PIC timer etc or from an external source. Also connect the clock to an interrupt pin on the PIC (negative edge). Also use one pin as output data and connect it to the D of the flip-flop. So when a interrupt happens, quickly set your bit you want to transmit on the output pin connected to D before the positive edge happens. This way you get a jitter free bit stream cheap and you do not have to worry to much about processor speed. For the receiver you can do the same, but then your clock needs to come from the source (TX).

Paul.

 

[Buriedcode]

Hi,

I've read, and re-read your post, a lot of info to absorb there, cheers

If you use your PIC as serial controller you should not have gap's.

Yeah, its fine in 'async' mode, back to back bytes stream perfectly, but it limits the speed to something silly like 1Mbit/s. Sync allows for up to 5Mbit/s. About the 'gap' thing, I'm sure its just a bug, but microchip haven't responded to my emails. Anyway, I know this isn't a microcontroller forum...so back to bit streaming in comms...

I know I will probably have to use at least some form of external digital circuitry, but reducing it down to a couple of flipflops would help alot. It does bother me that such a simple task can be so difficult, a fast contorller would allow for a one-chip solution...but is over-kill. All my tramsitter contoroller must do is take samples form an ADC (via I2S) and packet it up with constant bytes (preamble, sync word, etc.) and yet, there is little info on this anywhere, depsite the fact I'm convinced it can be done with simple and cheap micro's. it also doesn't help that the board size of my transmitter must be about 40mm x 50mm.

The only problem I can see with your idea, is that it seems to use 'software bit-banging'. Although this is only for transmission, I would have to change the data pin output state every other instruction. Unless of course I use an AVR, which is much faster. Unless you meant to use the USART in sync mode and 'modify' the output with clever use of flip-flops and timers to reduce the gaps. I will look into it.

However, silver lining... I AM writing some code for a PIC to form a fully, reprogrammable (variables in RAM) serial data controller based on your idea's. It will come in handy for anything <1Mb/s. And it'll allow for extras, ECC, CRC, variable preambles, channel coding etc.. I like building little modules like this, it makes prototyping for various systems a whole lot easier.

Thanks for your help,

BuriedCode.