UART speed problem
Jack
I need an opinion:
a customer wish to comunicate with our board (that uses a Freescale
MC56F8037 to control a BLDC motor with hall sensor for commutations
and an encoder for position sensing) via a RS485 bus with a baudrate
of 230400 bps. the frames are 16byte in length and a reply is expected
within 3 msec (communication should be every 80 msec).
I'm not sure that the 8037 can handle that speed (usually the speed I
use is 9600-38400 bps) but it's easy to check.
I thought to use an external chip to handle the communication
(connected to the main uC via IIC or SPI), but which one? Do you know
any that I can use?
Thanks Bye Jack
PS: the 8037 doesn't have DMA...
TTman
"Jack" <jack...@gmail.com> wrote in message
news:a927350d-ffb9-4c41...@o10g2000yqa.googlegroups.com...
Uart.
Jack
> 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
Stef
Jack <jack...@gmail.com> wrote:
> Hi,
> I need an opinion:
>
> a customer wish to comunicate with our board (that uses a Freescale
> MC56F8037 to control a BLDC motor with hall sensor for commutations
> and an encoder for position sensing) via a RS485 bus with a baudrate
> of 230400 bps. the frames are 16byte in length and a reply is expected
> within 3 msec (communication should be every 80 msec).
>
> I'm not sure that the 8037 can handle that speed (usually the speed I
> use is 9600-38400 bps) but it's easy to check.
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.
> I thought to use an external chip to handle the communication
> (connected to the main uC via IIC or SPI), but which one? Do you know
> any that I can use?
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.
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.
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.
> 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).
I've found the Maxim 3140. But yes, the controller still has to handle
every char...
> 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.
Probably this is the best solution, i will speak with my colleagues
about that.
Thanks!
Bye Jack
Tim Wescott
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.
D Yuniskis
[snip]
>> I thought to use an external chip to handle the communication
>> (connected to the main uC via IIC or SPI), but which one? Do you know
>> any that I can use?
>
> 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).
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.
> 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.
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.
Stef
D Yuniskis <not.goi...@seen.com> wrote:
> Stef wrote:
>> In comp.arch.embedded,
>> Jack <jack...@gmail.com> wrote:
>
> [snip]
>
>>> I thought to use an external chip to handle the communication
>>> (connected to the main uC via IIC or SPI), but which one? Do you know
>>> any that I can use?
>>
>> 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).
>
> 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.
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
D Yuniskis
> In comp.arch.embedded,
> D Yuniskis <not.goi...@seen.com> wrote:
>> Stef wrote:
>>> In comp.arch.embedded,
>>> Jack <jack...@gmail.com> wrote:
>> [snip]
>>
>>>> I thought to use an external chip to handle the communication
>>>> (connected to the main uC via IIC or SPI), but which one? Do you know
>>>> any that I can use?
>>> 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).
>> 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.
>
> 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
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).
Mark Borgerson
t...@seemywebsite.com says...
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
karthikbalaguru
wrote:
> In comp.arch.embedded,
>
> > [snip]
>
> >>> I thought to use an external chip to handle the communication
> >>> (connected to the main uC via IIC or SPI), but which one? Do you know
> >>> any that I can use?
>
> >> 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).
>
> > 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.
>
> 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).
>
Interesting.
Karthik B alaguru
karthikbalaguru
The processor should be able to handle.that speed.
Karthik Balaguru