Either one, you send it a command over serial, it changes something, then waits for another command or two you send it a command over serial, then it executes some type of small set of commands on its own processor, then returns the result.Īs I mentioned above, the first method of having Mathematica and your computer do the legwork in determining what command to run when is very ineffective at high frequencies. While I'm not familiar with how the Gieger counter mentioned in your post works, it looks like it is doing one of two things. I tried this, and it seemed to have about 1 KHz frequency, but stopped flashing after a second or two and stayed on, so it's possible that the Arduino runs it fine, but after it finishes Mathematica takes a couple of seconds to catch up. Just change it to Serial.begin(115200), and re-upload it and you should be good to go. The second to last line here is Serial.begin(19200). Here, you can change the option from "BaudRate"->19200 to "BaudRate"->115200.Ĭhanging the Baudrate in the Arduino firmware file, you can open up the file, and down a ways is the void Setup() loop.
I haven't quite gotten that far, but the most difficult task to me would seem to be the Symbolic C portion of it and the updating of the firmware, as I have accomplished just about all the other tasks.Īlso, if you would like to change the baud rate on your drivers, you can do so by opening up the package in Mathematica, and right underneath Begin is the definition for open, which opens the Serial Port.
This is not yet available because what I plan to do is be able to write whatever commands you want the Arduino to be able to execute in Mathemetica using Symbolic C, then have Mathematica automatically update the firmware file, and then automatically upload the firmware to the chip, all without ever leaving Mathematica.
Instead, I am currently developing a new functionality (using DeviceExecute), which would basically send one command over Serial to the Arduino, which would then cause the Arduino to run some pre-uploaded code (in C/C++), at which point there would be absolutely no problem doing things on the order of microseconds. add up pretty quickly and the timing becomes problematic.
Work faster than about 1 KHz, because the front end combined with all of the necessary Mathematica functions to write over serial, etc. However, I would be surprised if it would ever be possible to have something akin to Do Pause DeviceWrite),]
It is definitely possible to increase the speed (in both the Mathematica driver file and the Arduino firmware) to 115200, which is the fastest I have seen with an Arduino.
Well, when I built the drivers I used 19200 as the baud rate, which is quite slow for serious applications. That will probably help out quite a bit with the "qqqq" showing up, but my main recommendation is to put a Pause in between the DeviceReads, something not less than 1/2000 seconds I think should be enough. That refers to modifying the builtin arduino library that defines the size of the serial buffer to 256 in that case for the Arduino Uno, but it can be easily modified for a Micro. If you are curious, you can look into increasing the size of the Serial buffer on the arduino here. This is why my error values of "qqqq" are showing up, because the original bytes were overwritten, and now there are new bytes there that cause undefined behavior. As you mentioned a check for the length of serialReadBuffer would probably solve at least some of the problems, but the other problem is that because so many requests are being sent into the serial buffer on the Arduino, the entirety of the buffer can be overwritten in the time it takes to process an analogRead, as analogRead's are somewhat slow on the Arduino, mainly because the buffer is only 64 bytes. On the topic of ArduinoRead, I can almost guarantee that the problem is because too many requests are being sent to the Arduino, and Mathematica reads the serial buffer too fast, so it doesn't get a chance to become populated. I have an Arduino Micro chip here, and I can't seem to reproduce the disconnection, so it could be unrelated or something in the driver code I'm not seeing. I have been looking into this, and I think the problem here is that too many requests are being sent to the Arduino, and the Arduino Micro chip doesn't have an additional chip for processing incoming Serial bytes, so I would say that it is possibly the cause of losing the connection, but is still quite wierd.