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.