Serial port communication support

Are you the guy maintaining this code? :slight_smile:

Oh and I could very well be doing something wrong. My only experience with juce is a tutorial on how to make some buttons, sliders and so on.

I begrudgingly maintain the code. Lolā€¦ I use it a fair amount, so I try to keep it working. It sounds like your issue is about getting the Projucer to do the right thing. Iā€™ll try and help, but this isnā€™t specific to the serial port module.

I have a ā€˜third party juce modulesā€™ folder where this module lives. So in projucer I use the ā€˜Add a module from a specific folderā€™ option, and select the top level juce_serial folder.

1 Like

Kudos to you for maintaining it, you are doing amazing work for mankind
my friend.

Ah. It seems the name of the folder needs to be juce_serial and not juce_serial_master as it is when downloaded fresh from github. I included it successfully to the modules.

It was me being a dumbass.

Thanks man, I hope itā€™s fine if I ask here again if I encounter issues :slight_smile:

I have included the module but I get errors. (I havenā€™t aded any serial code to my project yet).

It has problems with these lines where the ā€œpriorityā€ variable is used:

example:
void setWriterPriority (int priority) {setPriority (priority); } //It says it canā€™t convert argument from int to juce::ThreadPriority

They changed the juce::Thread API so that simple integers canā€™t be used for the priority. I guess this is a bit more work for cpr2323ā€¦

Can I go in and manually change them to ā€œautoā€ or something?

auto was not allowed

Changed from int to ā€œjuce:: Thread ::Priorityā€ and it compiles fine. Should I open an issue on github? Iā€™ve never done it, (noob programmer) :stuck_out_tongue:

Yes, open an issue. I also may need to implement more than just that change, if I want to try and maintain compatibility with previous JUCE versions.

1 Like

I understand. I just wrote an issue with the problem. I leave the solution to you.

Iā€™m trying to write code to scan the com ports and find my teensy 4.0. However it canā€™t find the class SerialPort. Iā€™m writing like this: juce::SerialPort but itā€™s not recognising it. What #includes do I need?

Third party modules are not in the juce namespace. The #include is part of the JuceHeader.h files.

Iā€™m actually using the library today, as I work on a personal project (audio plugin that controls LEDs over USB connected micro controller). Since serial port stuff can block (including the opening and closing of ports), I tend to set up a state machine (idle, open, close, process) thread to manage the serial ports in another thread. Here is an example of the open

bool LightPlugDevice::openSerialPort (void)
{
    serialPort = std::make_unique<SerialPort> ([] (juce::String, juce::String) {});
    bool opened = serialPort->open (serialPortName);

    if (opened)
    {
        SerialPortConfig serialPortConfig;
        serialPort->getConfig (serialPortConfig);
        serialPortConfig.bps = kBPS;
        serialPortConfig.databits = 8;
        serialPortConfig.parity = SerialPortConfig::SERIALPORT_PARITY_NONE;
        serialPortConfig.stopbits = SerialPortConfig::STOPBITS_1;
        serialPort->setConfig (serialPortConfig);

        serialPortInput = std::make_unique<SerialPortInputStream> (serialPort.get());
        serialPortOutput = std::make_unique<SerialPortOutputStream> (serialPort.get ());
        juce::Logger::outputDebugString ("Serial port: " + serialPortName + " opened");
    }
    else
    {
        // report error
        juce::Logger::outputDebugString ("Unable to open serial port:" + serialPortName);
    }

    return opened;
}

I have written code like you describe as well, ie. looking for a device. It is another reason I use a thread for opening the serial port, because you can get strange behaviors from ports that arenā€™t connected to your device.

Lastly, let me know if you need any advice on a comms protocol. Using a start byte pair should be the minimum, but tossing in a crc is cheap and can keep you from processing bad data. The little project I am working on is 2 start bytes, a command byte, a command data length, and then the command data bytes. Iā€™ll add in a crc once things are up and running more.

It seems Iā€™m going to be pulling my hair for a few days getting this stuff to work as itā€™s way above my knowledge.

What I need the Serial communication for is to send waveform data so I can see whatā€™s going on in my electronic drum triggering software. Iā€™m doing it now by sending comma separated values to another app but I want to make it work with juce.

Iā€™m thinking to send a struct or array with the waveform data which consists of maybe 5 float variables, one for each waveform and Iā€™ll be sending it at maybe 10kHz for a few milliseconds after every new hit on the drum is detected. Sort of like an oscilloscope. Iā€™m not sure how many samples of each waveform I can send at once because it will slow down the loop that acquires the analog values. I was thinking to send just the current sample of each sensor and then fill a buffer in juce, normalise and display them.

This chart might help in guesstimating your bandwidth requirements against a given baud rate.

https://omohmproductions.com/data/

I have pushed a fix supporting the latest ā€˜Thread::setPriorityā€™ API in JUCE. Which also allows usage of the old API through a compile time constant.