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)

Ok more logs in the Dropbox folder ( here is the link to the folder) https://www.dropbox.com/sh/7ud7s5eoy30v … g8l7a?dl=0
In putty2.log and putty2.txt
I opened the Editor and after the cursor stopped spinning (trying to refresh from OPA? ) I hit the Load Internal three times (Program 1, internal 1). So the last 9 bytes of the log should be 0x0A, 0x00, 0x00, 0x0A, 0x00, 0x00, 0x0A, 0x00, 0x00 yes?
But the log shows this in HxD- 0x0E, 0x00, 0x00, 0x0E, 0x00, 0x00, 0x0E, 0x00 0x00
So this is strange. I did another run but pressed Store Internal (Program 1, internal 1)
putty3.log and putty3.txt-
Now its 0x0D, 0x00, 0x00 when it should be 0x09,0x00, 0x00
So don't know What is going on, why the bit values are off compared to the Command value in the manual. Maybe some weirdness with PuTTY or HxD or the FTDI interface or the Pi uart ?!?!
And why the Editor works with an FTDI and not with a direct connection. Judging from these tests it would seem that the shield would do Something,  even if it's the wrong command. But not seeing/hearing any signs.

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.

Last edited by yogi (Sep 4, 2016 1:14 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)