Emax

>>> as soon as i start EMXP and initiate transfer or receive, XCK will be pulled to ground

That's normal, especially if you didn't connect the send/receive data pins with the Emax.

The reason is that EMXP doesn't instruct the EMuSer immediately to go in SYNC mode. It first does some communication in asynchronous mode:
In a first stage, it instructs the Emax to change its Timeout parameter, followed by an instruction to start the bank transfer.
Both commands are done in ASYNC mode at 31250 baud. As you can see in the main program of the firmware (EMUToSerialEmu.c), if the baudrate is not 500000 (as 31250 is...), the clock pin is set to OUTPUT (bit 5 of DDRD register) and the communication mode is set to ASYNC (UMSEL bits of the USCS1C register).
Only after both instructions have been executed succesfully at Emax side, EMXP will instruct the EMuSer to go into SYNC mode, which is done by changing the baudrate to 500000. As you can see in the main program of the firmware, only then the XCK direction changes into INPUT and the device is set in SYNC mode.
After the high speed data transfer, EMXP will init the EMuSer to baudrate 0 to disactivate it temporarily.

As long as EMXP's RS422 functions have not been used after initial connection of the EMuSer to the USB port of the PC, the EMuSer uses the default settings of LUFA. As far as I remember this means that the XCK direction is OUTPUT (high).

If your Teensy++ is continuously showing an OUTPUT direction of the XCK pin after having started the bank transfer option in EMXP, it means that for some reason EMXP is not getting a response from the Emax in MIDI/async 31250 baud mode. After a while you should get an error in EMXP (=when timeout/read retrials limit is reached). This could take a while (even minutes) depending on the Preferences parameters that are defined for the RS422 communication with the Emax. 

So, what error do you actually get in EMXP ?   


>>> Btw Teensy++ will not work with the Teensy firmware (Windows will not detect the COM port, which proves this)
Do you mean Teensy++2.0 firmware or Teensy2.0 firmware ?
(I hope Teensy2.0, that would be normal :-)


BTW1: Have you tried SYSEX communication with your Emax via the MIDI bus ? Perhaps you should try this at least. If it doesn't work, there's definitely something wrong with the Emax. If it works, there could still be a problem with the RS422 section of the serial circuit hardware of the Emax. If the Emax RS422 driver or receiver IC is dead (which is perfectly possible !) then it's normal that EMXP will fail in its attempts to communicate with the Emax.

BTW2: Can you confirm that you are using an SE/SE-HD/Plus OS on your Emax ?

(PS: if these detailed technical discussions are too boring for most group members, we should switch to e-mail communication...)

///E-Synthesist

--- In emax@yahoogroups.com, "Adam" <fake@...> wrote:
>
> Hi, thank you for the test on your side. Here it still looks rather weird.
> The problem is definietly related to the clock.
> 
> Let's make things as simple as possible. 
> 
> Let's detach everything from the Teensy, just get EMU's clock to the XCK (PD5) pin (besides VCC and GND) - but nothing else.
> 
> In this situation we've used an SN75176 line driver configured  as receiver like this:
> 
> CLK (from Emax:5)  ->  SN75176B:pin6 (A) 
> SN75176B:pin7 (B) = L
> SN75176B:pin1 (R) -> Teensy PD5  (XCK)
> SN75176B:pin4 (D) -> not connected
> SN75176B:pin3 (DE) -> L  
> SN75176B:pin2 (NRE) -> L  
> 
> in this configuration i can measure fine clock coming from the EMAX (or EII: tried with this too, results were the same), and it can be seen arriving on the XCK.
> 
> as soon as i start EMXP and initiate transfer or receive, XCK will be pulled to ground! the oscilloscope shows almost no signal on the pin, which suggests that it went to output state.
>  
> What you think of this? I'd appreciate any suggestions.
> 
> Beyond this we wrote a single code that tests the Teensy's PD5 output by making it H, and it works.  
> 
> Then we wanted to check then if it could read its PD5 pin. We did a little program which reads PD5, and if it was high, it sets PD6 high, and it makes the orange LED lit up, as it wired there by default.  
> 
> For me it means that the PD5 on the Teensy works all right.
> 
> Btw Teensy++ will not work with the Teensy firmware (Windows will not detect the COM port, which proves this)
> 
> At this point we are completely clueless!!!! If there was anyone who could say anything about it, that would be none else, but you i guess.
> 
> Adam
>