UART speed problem

Perhaps consider using something like an Atmel AVR..... integral SPI and Uart.

as external device that handle che COM? It's an idea (maybe not the avr but a HS08 that we already use), there still be the question if the secondary uC can handle the speed (230400 bps) :P

Thanks Bye Jack

have you checked that already? 230400 is not very high speed if you compare it to SPI/I2C/etehrnet etc. and a very standard UART speed. I suspect your controller will be able to handle it, provided you have a suitable clock frequency. At higher speeds, your baudrate divider selection is more limited and a matching clock becomes more important to keep the frequency error low enough.

And what should that device do? Just pass the bytes on to your controller? In that case your controller still needs to handle every char so the load remains the same (you may have more buffering in the external device).

Or should the device handle your low level communication and replies? In that case the microcontroller answer is a very good suggestion. A small micro should have no problem keeping up with the 230400, if that is all it has to do.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Resisting temptation is easier when you think you'll probably get
another chance later on.

I checked. the freq. error will be under 1%. I also discovered that the UART module of the 8037 has a tx/rx fifo buffer (4 word each), so I can cut in half (at least) the interrupt request.

I've found the Maxim 3140. But yes, the controller still has to handle every char...

Probably this is the best solution, i will speak with my colleagues about that.

Thanks!

Bye Jack

This is such a huge "that depends" question that without knowing your software intimately there is no answer.

Is that chip _capable_ of handling _some_ RS-485 comms at that baud rate, while controlling _some_ BLDC motor? Sure!

Is it capable of handling _their_ RS-485 comms at that baud rate, while controlling _your_ BLDC motor? Well...

What sort of processor overhead do you have? What sort of extra latency from the serial ISR can you tolerate? How big are the packets on their protocol? How much processing does it take to chew through one of their packets to determine a correct response? Etc., etc., etc.

--
www.wescottdesign.com

This is where you win. Instead of incurring ISR overhead on

*each* byte (or, each *dozen* bytes in the case of a buffered UART), you can pass blocks of data to the device. If the "master" can write the data to the "slave" open-loop, then the savings can be noticeable.

I use this approach (cheap PICs) to talk to parallel ports. The "slave" (PIC) can watch the handshake signals with the "printer" and focus solely on moving data to the "printer" so the "master" doesn't have to poll or get interrupted on each significant transition.

When you consider the alternative is a latch or buffer on the "master" processor, if you treat the "slave" as if it was as disposable *as* that latch/buffer, then it makes sense.

Since he *wants* I2C or SPI communication to the *external* chip and he has also claimed to have *no DMA*, the main CPU would still need to handle

*each* byte as it comes in, but now from I2C or SPI, not a *real* difference from direct UART to the CPU. _If_ he can use, say, 20MHz SPI, he may be able to busy wait for an entire packet in a *burst*, but that _depends_ (as always).

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Life only demands from you the strength you possess.
Only one feat is possible -- not to have run away.
		-- Dag Hammarskjold

I interpreted the OP's comments as *suggesting* that he would

*like* to use I2C, etc. and not a _mandate_. I.e., given an analysis of the costs of each approach (in hardware and overhead), other approaches might be more attractive.

Regardless, if the "master" CPU can't keep up with the instantaneous load at any particular time, having a second *real* processor ensures that the demands of that communication protocol (i.e., to the "external device") remain satisfied -- since the protocol between the master and the slave is something that he would have 100% control over (and, thus, could design to accommodate these periods in which the master was overloaded).

Add this one:

Does the UART have the capability to automatically control the output enable on the RS-485 driver? If not, is there an interrupt after the last stop bit of a transmission?

Mark Borgerson

ler?

ice).

e

nce

ble

Interesting.

Karthik B alaguru

The processor should be able to handle.that speed.

Karthik Balaguru