Are you the guy maintaining this code?
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.
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
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)
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.
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.
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.