Is it possible to use the UART for 18 bit frames?

[asdf85]

I need to communicated with a device at 4Mbps and each of its frames are 18 bits long including the start and stop bits.

Can this be done?

[FvM]

PIC processors are supporting neither the baud rate nor the 16-bit frame. There may be special external communication processors that support it, but I'm not aware of any at the moment. Personally, I would go for programmable logic devices. I'm e.g. decoding 40 MBPS UART protocols with FPGAs.

For a PIC processor application, you should also consider that the data throughput with 4 MBPS may be a problem.

[temtronic]

If the 4Mbps is 4 million BITS per second, then a PIC can handle it though not through the UART. The common 'UART' is a chunk of hardware designed for 8 bit communications( ok...5 to 9 bits).
However I run 22 bit serial data all day long in a network and 4Mbits is 400,000 baud that a PIC can handle.I have one CNC device running 300,000 baud and MIDI is 250,000 baud I believe.

[FvM]

[Ttelmah]

Realistically, if this is at a fixed 4MB/sec rate, I'd look at doing this with a small amount of programmable logic. A basic UART, only involves a couple of hundred gates. One of the smallest FPGA's, could do this "in it's sleep", and with the size that even the smallest devices now offer, add a couple of characters of buffering as well. You can then just retrieve the data as parallel, with a strobe, or equally easily shift it out again in 8bit synchronous form, allowing it to be retrieved with the SPI on a PIC. Trying to do it in software, even with a much faster chip, is going to mean you can't do much else while it is arriving.

Best Wishes

[asmboy]

This post is so OPAQUE - and all thats possible is a NON illuminating debate over theoretical limits. B O R I N G ;-))

WHAT IS THE DEVICE IN QUESTION ???

Lets get real --what does it have for data transfer CONTROL ???

[asdf85]

asmboy, I'm not sure what do you mean by opaque and non iluminating. The device is an absolute encoder.

So Ttelmah and FVM, the suggested way to do this is by using a FPGA? Looks like I have some learning to do then.

I'm just wondering, if I try it in software uart, then would running the internal oscillator at 32MHz of say a PIC18F2620 be sufficient for a 4mpbs line, assuming I don't have to do anything else, but retrieve the data and storing temporary in ram? Or should I get an external crystal of 40MHz to do it ?

[asmboy]

Is the encoder a developmental item , product-to-be
OR does it have a part number // data sheet ?
Thats the way I usually size up a challenge.

[Ttelmah]

The data sheet is what is needed.
There are a number of problems:

How often do the frames come?.
Is there any 'warning' that a frame is coming - if not, then you can't do _anything_ else while waiting.

Thing is that 32MHz, gives 8MIPS. At 400Kbps, you have just 20 instructions/bit. It takes time to store values, time to rotate values, time to sense edges. It is probably _just_ about possible to read an 18bit frame like this at this speed, but it will be 'borderline', and certainly not if you want to do anything else at all while waiting....

If this is a 'one off', then just consider a pair of 8 bit shift registers, a latch and a counter. You'd want an 8MHz clock, start when the first start edge is seen, wait three counts, and then just advance the counter, and latch the bits into the shift register, on every other count. When the counter reaches the end, trigger an interrupt to the PIC, and read the 16bit value out (2* 8bit reads). You could probably do it with about 6 IC's. However on any production project you will need some other 'glue' logic, so doing everything in an FPGA makes much more sense.

Critical thing though is how often the frames come. There has to be long enough between frames for you to read the data, and do whatever you want with it. 'Data' is needed.....

Best Wishes

[temtronic]

Up the clock to 64MHz and you'ld have 40 instructions/bit. That 'should' be enough time to grab and store.
From what we've been given it's just 16 bit data (start bit, 16 bit data, stop bit) so it should be possible to use the 'shift right() function' along with a 'trigger' (start bit) detection and a 'clock' (inverse of 4Mbps) to accomplish the task. This is the PIC equal to Mr. T's external hardware SR chip setup.

For 'proof of concept', I'd burn a PIC as a 'pseudoEncoder' outputting known data at slow speed (say 500 bps) and cut code on a receiving PIC to grab and store the data. When running right, increase the data transmission speed to say 1000, 2000,....4M bps with the appropriate changes in the receiving PIC.

This process might take 1-2 days. Since I don't know what you're going to do with the data once in the PIC, I can't help anymore.

[Ttelmah]

There is one other 'lateral' suggestion.
Take a tiny PIC. Say something like the 12F675. Clock it at 16MHz.
Have it sit in a tight loop just watching the incoming signal. When it sees the edge of the start bit, delay for 3.5uSec, then just generate 16 clock pulses at 400KHz. Will need a little bit of careful coding, but basically pretty easy.
Then feed the incoming signal to the SDA pin of the main PIC as well, and the clock from the 675, to the SCL pin of the main chip.
The main chip can then just use the SSP to receive the data, clocking using the 16 clock pulses from the 675. Since the SSP hardware has a byte of buffering, you have 20uSec to get into the interrupt handler and retrieve the first byte, which is pretty easy to do.

Very small part count, easy to code, uses the minimum number of pins.

Best Wishes

[asdf85]

I managed to find the link to the datasheet of a very similar model M0006890K. The one I'm gonna use is the M0006890C.

http://db.sanyodenki.co.jp/downfile/manuals_en/SANMOTION/M0006890.pdf

Look at page 210 of the PDF file (labeled 9-5 in the doc).
I have not seen this device yet, but I'm told it uses the encoder signal direct output format for the communication.

Thats why I'm wondering how do I read this kind of signal.

[FvM]

Please refer to what's already said about decoding 4 MBPS serial data. In addition, the frame rate is specified to be "only" 8 kHz, so there's at least a chance to process the data with a fast microprocessor after receiving it with a dedicated external hardware (CPLD) UART.

The other point is, that the device apparently offers different communication options, so I wonder if it's absolutely necessary to select the one, that can't be decoded by a µP on it's own.

[RF_Developer]

I know of no microcontroller, of any type, that can handle 18 bit asynchronous frames in hardware. There might be one, some particularly specialised one, somewhere but no run of the mill micros will do it, they simply don't have asynchronous serial hardware that'll do that size frames. Few can deal with anything more than 11 bit frames, with maximum of 9 bits of data. The speed is another big issue too.

This means that you'd have to use a software UART... at 4Mbaud. Not going to happen. Not with a PIC, not with practically every microcontroller.

Not only that but what are you going to do with the data? This is a rotary encoder, that implies sine/cosine processing. Full on transcendental floating point, on the fly on a fast data stream... not for the faint hearted, and certainly not for a PIC. At the very least you're going to have to CRC check the data and then send the data on: over what interface? At what speed? Just the CRC will take most if not all of mosts PICs procesing power. Don't even think of 16F or 18F, that would stretch 24s and dsPICs. No way you can store anything but a very short burst on any PIC, and pretty much no way you can process it and compress it on the fly.

This is a clear FPGA application. There may be a dedicated decoder chips out there, and indeed Sanyo Denki do provide controllers for these units, the Sanmotion T series. Doing your own thing is re-inventing the wheel, and its a pretty complex wheel at that.

In any case M0006890C is NOT a model number. Its the document number for an eariler version (of december 2005) of that data sheet, which is now at K revision. So that is the current data sheet for the unit you're using.

RF Developer

[Ttelmah]

Have to agree wholeheartedly. Both transfer formats 0, and 1, can be directly handled by the PIC (the data sheet includes the start and stop bits, so what is referred to here as an '11bit frame', is 9 bit in more normal nomenclature), which can be directly received by the UART, as can the '10bit' format.
Looking at this, this is not designed to allow you to perform your own servo control. The unit itself already does this, but to allow you to monitor/display what the unit is doing, and as such could be handled by the PIC.

Best Wishes