OPA Multi-timbral FM Synthesizer (Page 3 of 4)

Well, been testing the RPi's uart. The shield and Editor works very well with an FTDI converter as ttyUSB0 but didn't see the Pi's uart at all, so ...
First task was to free it up for general use. Followed this guide-
http://spellfoundry.com/2016/05/29/conf … ding-pi-3/
Which is very complete. Then found a thread on StackExchange which recommends stopping Getty's access to the uart with-

   systemctl mask [email protected] 

Then I changed the permissions-

   sudo chmod a+rw /dev/ttyAMA0 

Everything seemed good EXCEPT the Editor didn't see the uart, ttyAMA0.
So had a poke around in the source and in rs232/rs232-linux.c found-

/** Base name for COM devices */
#if defined(__APPLE__) && defined(__MACH__)
        ...
#else
    static const char * devBases[] = {
        "ttyACM", "ttyUSB", "rfcomm", "ttyS"
    };
    static int noBases = 4;
#endif 

This appears to need the Pi's uart name and after adding ttyAMA to devBases[]  and changing the total of noBase to 5, the newly compiled Editor does discover ttyAMA0.

After these changes, tested with the shield connected to the uart but it isn't responding to the Editor. Doing a PC to Pi serial test, minicom on the Pi and PuTTY on the PC both talk fine @ 57600. So the uart seems to be working. Testing PuTTY on the PC and running the Editor on the Pi shows that data is being transmitted. I assume it's corrupt/wrong but I can't tell for sure how as it's not sending ascii in the first place. Will have to see if PuTTY can dump raw bytes as hex (?).

Did double/triple checks of the cabling for the shield and I am sure it's correct; so I feel it is related to how the source is setting up the uart. There is another function in the source,

 int comOpen(int index, int baudrate) 

that is related to Mac vs Linux port configuration but I have to do more research on these bit flags.

To be honest, I don't know if the Editor was ever tested with a HW uart, as the project is meant to be hosted on an Arduino UNO (USB serial) so there may be a fundamental bug in the rs232 HW port handling. Or it may be Pi related. On my XP box the Editor does discover the mobo Serial port but I haven't tried using this.

The quest continues,
Yogi

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

Last edited by yogi (Sep 3, 2016 9:26 pm)

Hello 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.

Last edited by marzacdev (Sep 4, 2016 6:24 am)

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

Hi Yogi,
since you are in the rs232-linux.c code could you try this:

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

Last edited by marzacdev (Sep 5, 2016 3:47 pm)