1 Select ttyAMA0
2 ****Send Note On/Off messages to editor, the first 2 or 3 key presses are silent, thereafter the synth sounds.****
3 De select ttyAMA0 or shut down the Editor.
4 Select ttyAMA0 again, now the the Editor will refresh.

I hadn't noticed that step 2 was needed but I was doing it when it worked yesterday. Just tried Select-Deselect-Select with no Note messages and that didn't.
Yogi

add the line:

tcflush(handle, TCIFLUSH);

before:
if (tcsetattr(handle, TCSANOW, &config) < 0) {

So it makes:

// Timeouts configuration
    config.c_cc[VTIME] = 1;
    config.c_cc[VMIN]  = 0;
    //fcntl(handle, F_SETFL, FNDELAY);
// Validate configuration
    tcflush(handle, TCIFLUSH);
    if (tcsetattr(handle, TCSANOW, &config) < 0) {
        close(handle);
        return 0;
    }
    com->handle = handle;
    return 1;
}

It's very possible the uart buffers are not initially empty as they are used by the system as a terminal console. Can you tell me if that solves the problem?

It could even be more secure to perform a:
tcflush(handle, TCIOFLUSH)

Please try it too.

Fred

In the Dropbox are the putty5.logs of the re connect; dsPIC's Tx monitored via a FTDI connection to my PC, while the OPA was connected to the Pi.   

So my guess is there is something strange in the RPi's uart handling that is outside the norm for other Linux distros. Where as the Editor using ttyUSB works almost flawlessly on the Pi. 
Yogi

If you're sure of your connections (RX and TX swapped correctly), you can try to short R5 and see if that's working better.
Also, if you do not have a scope at reach, try with an ohm-meter to check the basic conductivity of your wiring.

I'm sure with the pinning and will try shorting R5 (is it series resistance, current limiting?). After several cycles of re pinning for the two setups, I suspect the crimp-on connectors ( AMP type shell and crimp connectors). The metal 'socket' may have been deformed a little when I crimped it, just enough to have a bad connection on the carrier board header and a slightly better connection when plugged into the PC FTDI header.

I did do a continuity test across the cable: SIP header pins inserted into the Pi end socket of the cable, the other socket plugged into the header on the carrier board, and tested from the back of the board header across to the Pi end pins. Which was good, but  of course I was applying 'pressure' and flexing the cable with my meter probes. Will continue testing from OPA shield to Pi board.

Was also thinking of a another test harness- the cable between the Pi and OPA in place, but add a jumper/probe from the Rx on the PC FTDI to the OPA's Tx. Sort of a 'Y' on the line so I can log the dsPIC response and trace the signal path. My biggest concern is loading the dsPIC's pin too much. 

Yogi

The weird part is I used the same jumper cable on both tests, ~25cm of 4 conductor ribbon with a 4 pin socket on the Pi end and a 6 pin socket on the OPA end. The shield carrier board has a 6 pin header following the FTDI breakout board layout. So the OPA end of the jumper cable is pinned to match this header, plugging in instead of the FTDI board. With the Pi->PC test I just re pinned this socket, swapping Tx and Rx and removing the +5V from the socket. Then plugging it into a PC side FTDI board, set for +3.3V. This Pi->PC setup did work bidirectionally with the terminal tests.

At any rate, all signs point to a bad connection to the dsPIC Tx. Don't have access to a scope any more but I can setup my Papilio board as a Logic Analyzer. So if I can't make headway with inspecting the cable connectors, will load up the Papilio and see if that helps.

Thanks again,
Yogi

given the logs, I can tell that the editor received no data from the OPA.

Look (putty1.txt):
00000040  3D 7E 3D 7E 3D 7E 3D 7E 3D 7E 3D 7E 3D 0D 0A 0A
00000050  00 4C 00 0E 00 00 05 00 09 04 05 00 09 07 05 00

Real data starts at 0x004F (0D 0A is carriage return / line feed)
Editor sends 0A 00 4C 00 = please send me program 1
Then he should ask for program 2 until program 10, kit parameters and global parameters to initialise the GUI.

If it does not ask for more, it is because he received nothing.
I have checked the Raspberry Model A & B 2.1 and Model B+ 1.2 schematics and TX / RX lines are directly connected to the CPU, there is no logic conversion or pull-up, pull-down resistors.

The OPA shield also works with 0V to 3.3V logic levels (as the Raspberry).
You must have some connection problems.

I recommend you to use a scope and probe the logic levels on the RXD pin on the Raspberry connector to check if they are in a good range.

  Testing further, seems that the Editor is not updating from the synth. Loading an Internal patch does load it on the synth but the Editor doesn't update the screen with the patch prams.  Moving controls or Opening a saved patch updates the synth and the display.

Seems like there is an issue with the dsPIC Tx -> Pi Rx connection, More checking with this cable!!!
Yogi

Hope this helps,
Yogi
EDIT: Ok I looked into the Arduino Lib. Checked in OPA.h and see  that

        OPA_CODE_INTERNALSTORE        = 13,
        OPA_CODE_INTERNALLOAD        = 14, 

Which matches with the above logs, so... will have to recheck the cable. I also wonder if the +3.3V signals from the Pi are a problem. It Should work with the dsPIC but maybe the drive from those pins is just too low? I have some SF bi-direction Level shifter boards I can setup on the cable and test again.

Hi yogi,

I have been reading what you've done and I think you've found most of the problems. It should be working ok by now!
Send me a dump of the data it transmits and I will have a look.

You can actually log a putty session into a text file:
http://www.tricksguide.com/guide-how-to … ssion.html

I believe the problem might be the wiring.

Are these lines set as followed:
- DIG2 / CS1 => 0v
- DIG3 / CS2 => 0v
- DIG7 / RESET => 0v
- DIG7 / SWAP => 0v

with no jumper on the shield?

Fred

Hi Fred, I'll get a dump file for you.

As to the pins, got those set as you noted and jumpers open. Cable- Pi GND -> GND, +5v -> +5v, Pi Rx -> Rx and Pi Tx ->Tx (carrier board crosses Tx/Rx between FTDI header and Shield header ); same carrier board just replaced FTDI board  with cable to PI. Have tested on GPIO uart with and without Swap active, have a jumper block on the board. As well, I have the 'Arduino' Reset line pulled high with 10K R as per the Arduino board.

Thanks for your input, will get back to you,
Yogi