Emax

Thanks for this information.

I understand that an analogue scope could be sufficient to analyse 
the voltage levels, but I don't understand how such a scope can help 
in checking the data integrity... the pulses are sent at 500000 
pulses per second and are not symmetrical so I assumed I would just 
see some fast moving pulses passing through the screen, too fast in 
fact, right ?

About the timing: the strange thing is that when I go in 
conversational mode with the EII, it doesn't really care about the 
time between bytes, commands, ack/nack, ... I wrote a terminal 
program in which I can send one or more bytes to the EII and receive 
one or more bytes from the EII. 
A small example: the command to send 5 bytes to a certain position in 
the EII memory is a stream of 4 bytes, e.g. FF 00 96 05. Then the EII 
should answer with a kind of ACK (one byte) after which it expects 
the actual 5 data bytes to be sent from the computer. Now when I send 
the command byte after byte with pauses of 2 seconds between them, 
it's OK for the EII. After receiving the ACK from the EII I can send 
the 5 actual data bytes one by one, again one by one and even with 
huge elapstime in between them, that's still fine for the EII. After 
receiving the last byte it ACKs that it's OK. But when I the command 
sring or the databytes in one move, the EII starts complaining. 
Strange. At the other hand this might proove that it's a problem with 
timing...
I have no timing problems for receiving data from the EII.

Maybe I will buy a s/h analogue CRO to check voltage levels (to be 
sure) and a logic analyser to check timings.
I'll also perform tests with the Emax instead of the EII during the 
weekend.
Finding a PC/Express card RS422 will be difficult I guess. I only 
have laptops...

Thanks

///E-Synthesist


--- In emax@yahoogroups.com, mr julian <jujulilianan@...> wrote:
>
> 
> In my experience with comms between an embedded system and a modern 
PC, 
> your biggest problem is likely to be the timings.
> 
> Not timing between edges on the data (and control lines? does emu 
gear 
> implement these? I don't have my emax service manual right now) but 
> timing at more of the "transport" level - between data packets. 
> especially requests, and acks. Possibly even timing between bytes...
> 
> I haven't done anything with RS422 since my first proper job, 9 
years 
> ago (eeeek!) but RS422 is pretty much the same as RS232, in terms 
of 
> signalling, only lower level and balanced. As far as voltage goes, 
there 
> is a lot of margin in the design between what a transmitter should 
aim 
> for and what a receiver should act on.
> 
> Anyway - I've done a lot with RS232 lately, and can tell you that 
USB 
> converters on a PC for RS232 can fail with older embedded gear, 
because 
> the embedded gear was written when computer interrupts were a lot 
> tighter, and serial comms were not also piled on top of a USB 
interface 
> with its own hold-ups and data negotiation crap..... they could 
expect 
> an ack to a query a lot faster than they get now...... and so their 
> timeouts are pretty intolerant of sloppy responses, and with USB 
> interfaces especially, they can very easily fail.
> 
> if you wanted to try something on a PC, have a go with a PCI (or 
PCMCIA 
> or expresscard if you have a laptop) card that does RS422. they'll 
be 
> more expensive than the USB equivalent, but you won't get the 
faffing 
> about related to the USB layer that is almost definitely the thing 
> killing your comms attempts.
> 
> Also - no need to buy a digital storage CRO here - if you want to 
> analyse the integrity of serial data, you can see a lot with just 
an old 
> analogue CRO - looking at the integrity of the "eye" as long stream 
of 
> data goes past. If you want to analyse the actual data, then you're 
much 
> better off with a logic analyser. a cheap USB logic analyser would 
do 
> exactly what you want, and you'd be able to look really in depth at 
the 
> timings, at all of bit level, byte level, and packet level, if you 
get 
> one with a half decent amount of memory.
>