16F628A USART - Sync receive mode

[kenmac]

Hi,
When the 16F628A USART is set up to receive Sync code, and is receiving a continuous stream of bits, how does it know where a valid byte starts?
Is the USART capable of recognising Sync bytes itself, or does that need to be trapped in code?
I understand the Sync code system, but I'm not sure how the PIC USART is able to output bytes - it normally requires some "bit shuffling" until a Sync code is recognised.

kenmac

 

[Papabravo]

There are different protocols out there. Most of them rely on the difference between an idle line (0xFF) and a character with some zero bits. For example HDLC uses 0x7E characters, and the protocol throws away characters until it finds a 0x7E and then it starts looking at what follows. IBM BiSync used a 0x16 as a syncronization or preamble character. There are probably other examples out there.

The issue of byte syncronization is a bit murky with this device because the clock does not run continuously. There are 8 clocks per character if you are receiving characters from another PIC16F628. If you are receiving clocks from an actual modem then I'm not sure how you establish byte syncronization because those clocks run continuously and you have to look at the incoming characters on a bit by bit basis until a syncronization character shows up.

 

[kenmac]

I understand about the different protocols, (which the USART cannot know) it just responds to data and clock bits.
The datasheet says it outputs a byte of data - how does it know what is a valid Sync byte?
I am working with some EBCDIC format messages, which uses 0x32 as Sync characters.

Even with continuous code the same problem exists, because it sees all c locks, but still doesn't know where to start a valid byte, unless it is assumed that the first 8 bits are a valid byte.

kenmac

 

[Papabravo]

Until there is valid evidence to the contrary I think we need to assume that byte syncronization is determined by whoever is generating the clocks. When the 16F628 transmits, it generates 8 and only 8 clocks. A typical modem on the other hand generates continuous clocks, it establishes bit syncronization. It assumes that byte synronization happens in a higher layer. The PIC16F628 does not have the ability to look at an arbitrary bit stream and establish byte syncronization.

There is another quirk, which I did not discover, but which was discussed on this forum. If you continuously load the the transmit data register with 0's, what you get on the output is 8 zero bits, with 8 clocks, and a single 1 bit with no clock. The datasheet does not contain even a remote hint of this behavior. Doesn't sound like any syncronous protocol I've ever used, but who am I to complain or throw stones?

EDIT: It was knemac that made this discovery. I had forgotten.

 

[Nigel Goodwin]

Obviously there needs to be some way of identifying where the data starts, perhaps the ONE with no clock is that identification?.

 

[Papabravo]

That is essentially what I was trying to say. It is the generator of the clocks that determines where a byte begins. The 16F628 transmitter does it and the 16F628 receiver depends on the external clock source to do the same.

In the "syncronous" UART mode of the PIC16F628, the receiver does not expect continuous clocks, only clocks in groups of 8 which define the byte boundries. The transmitter does not produce continuous clocks only groups of 8 with a one bit space in between, assuming a continual supply of bytes to the transmit data register. This is not truly syncronous since the amount of time between bytes can be anything it wants to be from one bit to whatever. It would also appear that the maximum transmit throughput is 8/9 ths of the baudrate and not the baudrate.

It did just occur to me that the receiver might be able to run at the syncronous limit since it is depending on an external device for the clocks. I am quite sure that those clocks arriving in groups of 8 define the byte boundries.

 

[kenmac]

OK - it seems the USART is of no use for receiving messages in other than a " known start" type.
So, I will cease working in that area and go the hard way, generating code to handle "bit banging" of the received stream.
Are there any examples (PIC) out there of raw code to handle incoming Sync messages? (i.e. with sync character trapping)
I know what is required, just need to implement it in code.

Thanks guys,
kenmac

 

[Blueteeth]

Hi,

Found this thread on google, and I completely forgot I was a member here

It seems ANY information regarding the operation, initialization, development of the USART in 'sync' mode is sparse to say the least.

Although there a few apps that require it (most would just use SPI) I'm trying to find a way to 'stream' bits continuously for wireless comms, at high speed. The speed I'm after is too high for bit-banging (and even for UART in async), so a hardware module must be used. I'm using the 16F628A as a prototype...my final design could use something a bit 'beefier' but I'm always up for pushing PIC's to their limits and it would make the development so much cheaper.

Anyone managed to see a scope trace of the output of the USART in sync mode? I don't have a scope, so its either debugging with LED's, which is depressing....or somehow working out if a continuous stream (bytes back to back, no stuffing/framing bits or delays) is possible.
If anyone has managed to 'solve' this enigma, I'd be very grateful to know the results.

Blueteeth.

 

[Papabravo]

Blueteeth

kenmac's most excellent scope pictures are in the previous thread where we discussed the transmit behavior of the USART. Here is the link

https://www.electro-tech-online.com/threads/16f628a-usart-in-sync-mode.20847/?highlight=kenmac

 

[Nigel Goodwin]

Hi,

Found this thread on google, and I completely forgot I was a member here

It seems ANY information regarding the operation, initialization, development of the USART in 'sync' mode is sparse to say the least.

Although there a few apps that require it (most would just use SPI) I'm trying to find a way to 'stream' bits continuously for wireless comms, at high speed. The speed I'm after is too high for bit-banging (and even for UART in async), so a hardware module must be used. I'm using the 16F628A as a prototype...my final design could use something a bit 'beefier' but I'm always up for pushing PIC's to their limits and it would make the development so much cheaper.

Anyone managed to see a scope trace of the output of the USART in sync mode? I don't have a scope, so its either debugging with LED's, which is depressing....or somehow working out if a continuous stream (bytes back to back, no stuffing/framing bits or delays) is possible.
If anyone has managed to 'solve' this enigma, I'd be very grateful to know the results.

Syncronous requires TWO wires, so isn't suitable for a wireless application where you only have a single communication channel.

 

[Blueteeth]

hmmm

Thankyou Papabravo, it seems you guys (namely kenmac) have solved this problem quite nicely. Although, I must say, it does mean I can't use this in my app...unless I allow a '1' between bytes in the bit stream - which might be advantagous for synchronisation.

And thankyou Nigel.

Quote: Syncronous requires TWO wires, so isn't suitable for a wireless application.

Not entirely sure what you mean. I'm obviously not going to transmit the clock on a separate channel, or at all for that matter. I was simply going to encode my data using manchester encoding before sending it to the USART. This allows the receiver to automatically sync itself to the incoming stream, bit synchronisation. My receiver isn't going to use a USART, it'll be on a CPLD/FPGA, and I've already designed/tested it using a PIC's UART (async) and it works. Although, I was really after 2Mbit/s, which is only available in sync mode.

Thankyou.

BuriedCode.

 

[Nigel Goodwin]

Not entirely sure what you mean.

Quite simple, this thread is about syncronous comms using the USART in the PIC - but you're not using either?.

I'm obviously not going to transmit the clock on a separate channel, or at all for that matter. I was simply going to encode my data using manchester encoding before sending it to the USART. This allows the receiver to automatically sync itself to the incoming stream, bit synchronisation. My receiver isn't going to use a USART, it'll be on a CPLD/FPGA, and I've already designed/tested it using a PIC's UART (async) and it works. Although, I was really after 2Mbit/s, which is only available in sync mode.

If it's any help?, one of my tutorials is for Manchester via RF, but at normal slow rates - you're obviously already well aware that Manchester halves your bit rate?.

 

[Blueteeth]

Quite simple, this thread is about syncronous comms using the USART in the PIC - but you're not using either?.



If it's any help?, one of my tutorials is for Manchester via RF, but at normal slow rates - you're obviously already well aware that Manchester halves your bit rate?.

Well, I guess either I've got the wrong idea about the microcontrollers USART being using in sync mode as being 'synchronous' (sans framing bits) or we've got confused somewhere. I agree that my app isn't strictly synchronous, but its certainly not asynchronous. It involves continuous streaming of data (regular intevals, reserved timing), manchester encoded, which, if I'm not mistaken, is synchronous (embedded clock).

I believe I have read your tutorial on manchester coding for RF, very helpful, thankyou. And yes, I'm fully aware is halves the data rate, and I have other options available to me (4b6b, scrambling for example). What I don't understand is...although I'd say 95% of wireless apps only require a few kbit/s I'm streaming raw digital audio...which is a whopping 2-4MB/s, and...I honestly can't find much info on designing this sort of system on the internet. But, I will leave this for another thread, as you rightly pointed out, this is about the USART on the PIC16F628A only.

Thankyou,

BuriedCode.

 

[Nigel Goodwin]

Well, I guess either I've got the wrong idea about the microcontrollers USART being using in sync mode as being 'synchronous' (sans framing bits) or we've got confused somewhere. I agree that my app isn't strictly synchronous, but its certainly not asynchronous. It involves continuous streaming of data (regular intevals, reserved timing), manchester encoded, which, if I'm not mistaken, is synchronous (embedded clock).

I would consider 'syncronous' to require a seperate clock signal, as the USART in the PIC does - I wouldn't consider recovering the clock from Manchester coded data as 'syncronous' at all - it's got a far greater overhead than normal asyncronous.

Manchester is generally a packet system, with the receiver syncing to the header of the packet, which seems more like asyncronous to me?.

You mention 'continuous streaming of data', how do you intend to ensure you're reading the right bits in the right place?.

But it certainly sounds an interesting project (no pun intended), I'd be interested to hear how it turns out!.

 

[Papabravo]

Nigel,

You can consider the data and clock separate before they go into and after they come out of the modem. There are numerous examples of clock and data combined. Manchester encoding is one of them, and is used in several LAN syatems including 802.4. In the old floppy disk drives there was FM and MFM encoding which allows the clock to be recovered from the single channel data stream. In an earlier era there were 2400 baud Bell System modems that did IBM BiSync and later HDLC protocols.

I think Blueteeth has it right, and your definition of syncronous is quaint and out of step with the rest of industry. Naturally being an iconoclast does have its advantages.