You're welcome.
Kudo for the easier compilation of the editor. I've submitted a pull request for the documentation on github.

I understand some people wanted to have some kind of GM for FM as well, because GM is a kind of standardisation and not so badly done as it as a wide range of instruments. Probably it was also easier to let PC user which had some GM cards (with some samples support) be able to benefit of the music too. But you're right, it's a pity, music wise.

I guess you like this music (Dune for PC): https://www.youtube.com/watch?v=gUfGyfbzl9k

garvalf wrote:

You're welcome.
Kudo for the easier compilation of the editor. I've submitted a pull request for the documentation on github.

Well, if it hadn't been for the discussions here I wouldn't have dug deeper smile I feel a little like a sorcerer's apprentice with Linux, Find the right 'spell', type it in and Poof, Magic big_smile 

I understand some people wanted to have some kind of GM for FM as well, because GM is a kind of standardisation and not so badly done as it as a wide range of instruments. Probably it was also easier to let PC user which had some GM cards (with some samples support) be able to benefit of the music too. But you're right, it's a pity, music wise.

Yea, for PC game devs, they had to support two audio systems, Roland MTs and Adlibs, with one sound track. And MT32s were the priority. Later on the Sega MD you see some really innovative FM sound design, like in Sub-Terrania and X-Men Clone Wars VGMs. 

I guess you like this music (Dune for PC): https://www.youtube.com/watch?v=gUfGyfbzl9k

YES, one of my favs (on many levels, love the game series. Many hours playing Dune 2000 head to head over our network with my kids. Long before WoW).

So, I'll be posting my notes on getting the OPA running on the RPi's GPIO UART; I think I've got  it worked out but need to test today.
Yogi

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 serial-getty@ttyAMA0.service 

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

marzacdev wrote:

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

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

Here is the PuTTY log. I started a session then started the Editor. Hit Load, then moved the Vol knob about Halfways up.
https://www.dropbox.com/s/mh0sshvwftwt5 … y.log?dl=0
Yogi
EDIT: if there is a specific command in the Editor to log let me know. Also I included a hex view from HxD as putty1.txt
https://www.dropbox.com/s/l92l1yshr1qdu … 1.txt?dl=0

Last edited by yogi (September 3, 2016 10:09 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 (September 4, 2016 1:14 am)

Wow, So I rechecked my cable but everything seemed right. Setup the shield and opened the Editor, and unlike with the FTDI it didn't load the default program 1 from the shield. This behavior is like I had noted before (and thought it meant the shield wasn't working), but this time I tried connecting my keyboard and played a few notes. AND HEARD the 1 OP default sound. So I Opened a patch from disk, the editor updated the display and the synth plays it.

  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

Last edited by yogi (September 4, 2016 2:20 am)

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 (September 4, 2016 6:24 am)

Thanks so much Fred. I noticed the same byte pattern in the logs but didn't know the meaning. Of course remember that the logs are dumps of the Editor sending to the PC (in place of the OPA), Pi->PC test setup. It does confirm that the Editor is opening and using the Uart port. But the sound test, with the OPA I did last night, does show the one-way comms behavior.

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

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.

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.

marzacdev wrote:

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

YES, success by accident! I had been testing this afternoon, trying the different setups and ideas we've been kicking around with no improvement. Then at one point, opened the ttyAMA0 com (no display update), closed the connection; THEN without closing the Editor, I re opened the ttyAMA0 connection and BOOM! full functionally smile I've repeated this after a cold boot and no test harness attached, to confirm the workaround. Not really sure if something changed with my cable but I doubt that was the issue.

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 smile

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 (September 5, 2016 3:47 pm)

Great, will do!
one question-the TCIFLUSH line with the TCIOFLUSH line also or one in place of the other?

Last edited by yogi (September 5, 2016 4:50 pm)