Emax

If the Emax bank dump protocol uses the same format as the MMA SDS data packet then each 
packet only requires 127 bytes. That should not be too difficult to buffer.

If each packet requires a Ack/Nak reply then there is a built in flow control mechanism and no 
RTS/CTS hardware flow control is required. 

Esynthesist, would it be possible for you to reveal a bit more detail about the bank dump protocol? 
What goes in the headers etc?

/Tristan

Sunday, November 23, 2008, 9:01:15 PM, you wrote:

>

esynthesist wrote:

> Oops. I'm getting depressed finding out that my s/h USD50 old Mac is
>
>equipped with two (!) serial ports capable of what one (!) new USD399 
>one can do. And for that 50 dollars the Mac package also includes a 
>computer with screen, keyboard, harddisk and floppy drive :-)
>(ok, the Quatech will have more *serial* features, but still...)
> 
>
yeah.... modern computers move on from old tech, but then when you need 
the simple old features of the old tech, they're no longer a standard 
item, and you pay $$

>So I guess the next step is custom building one, e.g. with 
>experimental/evaluation boards or from scratch. 
>Not my piece of cake...
> 
>
Well, I did some investigating, and got the basic RS232 adapter test 
code up and working with serial loopback on my dev board, and read 
through the manual about setting up the avr USART for synchronous 
communication, which looks really simple... (though will have to build 
some buffer circuits, and then do more testing running it in loopback, 
while being externally clocked form the emax, before I can say it'll 
even be approaching being a possibly being useful solution)

note: this will never work as well as a proper US$399 synchronous 
interface, because it will be limited by whatever buffer size that can 
be made in the AVR(which has only 8k of ram), after the USB stack and 
the basic code takes everything it needs, but it's possible that maybe 
with a bit of tweaking, it can be made to work well enough to send and 
receive packets for the emax... as long as it's allowed to spend a bit 
of time shuffling data to/from the PC between packets....

so - how big are the packets that the emax sends and receives, anyway??

>I guess experimenting with the CTS/RTS signals also does not make 
>sense anymore, right ? I thought it could be a way to keep the 
>drifting under control... I guess not... 
> 
>
nope... sorry... it's the mechanism for either side of the comms pair to 
say "hold up! I've had enough!!" to the other side, instead of just 
overflowing and crapping out...

looking at my service manual again, I don't see CTS or RTS here 
either.... just tx, rx, and clock. so I guess that's all we need, to 
talk to the emax from a PC?

>And I'm still a bit afraid that it could damage my PC RS422 port 
>since the RTS/CTS pins are expecting either positive or negative 
>voltages but not a mixture of them. Or are those ports typically 
>protected against this "abuse" ?
> 
>
They are protected, to some degree.

btw, "+" and "-" do not refer to the voltage polarity of a balanced 
signal, they refer to the logical polarity. in this case, I think you'll 
find RS422 + and - parts of a signal are both always in the range of 0V 
to 5V, but the "+" is 5V when the "-" is 0v, and the "-" is 5V when the 
"+ is 0v....