Yahoo Groups archive

Emax

Index last updated: 2026-04-28 23:23 UTC

Message

Re: [emax] Re: RS422 fun

2008-11-24 by mr julian

tu@... wrote:

>Thanks, this protocol makes sense. No doubt Emu did it this way so they could reuse the SDS sample dump code. Can you confirm that the Emax 
>always waits for an Ack/Nak before sending the next packet? This is important to know, as the buffering requirement is much lower if we can be sure a 
>new packet will not arrive until after the last packet has been handled.
>  
>
yeah..... that would make things really simple.
:-)

>A side effect of this is that when operating at 31.25k baud the Emax UART is actually working in asynchronous mode. Synchronous operation 
>only happens when the x1 clock divider is used. Therefore the Mac is presumably doing the same thing at its end when switching between the baud 
>rates.
>  
>
I'm pretty sure the mac would have to have it's own clock for 
asynchronous communication.

in asynchronous mode, the UART runs at much faster than baudrate speeds 
(say 500k for 31.25k data ??which is why the emax works fine at asynch 
31.25k with this as it's clock, still... ;-) and continually samples the 
serial data for the start bit. then when it's got a valid start bit, 
having detected the falling edge at the beginning,  it samples the rest 
of the bits in the middle, and confirms the final edge of the stop bit. 
all being good, the received byte is latched to the output.


>The easiest solution from your software perspective would be if you could have a USB serial port that supports synchronous RS422 connection to the 
>Emax (or other Emu sampler). Then you handle the protocol, baud rate switching etc and you can use standard Windows drivers. This is presumably 
>what the expensive commercial interfaces are offering and I presume this is what Julian is working on a low cost alternative to. 
>
yep!
:-)

basic solution if this works will be one $30 dev board, wired to a 
separate board with a couple of ICs. I will just veroboard the custom 
stuff for now, but if it works and a few people want one, can always get 
a batch of small PCBs made up for a few $.

if I can get away with a simple unchanged serial adapter, that would be 
amazing - otherwise I might have to put some smarts into my buffer that 
will make it only work with the emax (ie look for header info and 
deliberately hold off a packet retransmission to the emax until it has a 
whole one, etc etc - basically make it run off the actual data that 
comes through it...)

>Another option would be 
>to have a microcontroller with a large buffer memory that the PC can read from and write to using whatever protocol and the microcontroller would 
>handle the Emu sampler synchronous RS422 interface and protocols. Obviously this would be more work to develop the software for the microcontroller 
>and possibly the drivers. 
>  
>
yeah - would be best not to have to do that if at all possible.
also, half a MB of fast access RAM for buffering would be annoying to 
deal with hooking up on an 8 bit micro.

>Another possibility would be to have a micro controller with two serial interfaces, one to the PC (asynchronous RS422 or RS232) and one to the Emu 
>sampler (synchronous RS422). The micro controller would just buffer and pass data between the two UARTs and switch baud rates (31.25k/500k) 
>toward the Emu sampler if required. The PC host could connect via any off the shelf USB to RS232/RS422 adapter or use a built in or PCI serial port. 
>Because of the flow control provided by the Ack/Nak messages, the PC serial connection could also use any baud rate the PC port supports. Although 
>dumps would be slower at PC baud rates lower than 500kHz, this would make it widely compatible with any old PC you might happen to have lying 
>around. Both the microcontroller software and hardware would be fairly simple for this option and no special drivers would be required. The Emax serial 
>port even provides +5V that could be used to power the small interface board.
>  
>

A serial rate converter would be even simpler, but it would be nice to 
be able to have PC side running fast enough that there was no gaps 
between bytes in a packet, as seen by the emax.....

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.