Thanks for the suggestion, I attached a notebook, which is just basically the original post in notebook form.

Very nice! I'd like to be able to create a GUI with mathematica to control our microscope lasers via the Arduino. This seems like a very good start. Just tested and it works on my system (Windows). However, any thoughts on how fast this can pulse the LED? I tried setting the time delay to 1 ms and it seemed a bit off. How fast can we pulse?

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

As 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. Instead, having the Atmel chip on the Arduino execute things is much more effective, as there is no other processes to slow it down, i.e. serial communication, OS processes, etc. If one needs high frequencies I would say that having the Atmel chip on the Arduino execute those commands is the way to go. I would also say that any faster than the theoretical limit mentioned on the documentation page for analogRead would probably require special hardware, and then another driver developed for it, but it is certainly possible to have the Arduino execute some command at that frequency, then pump out the result (or an array of the results) over serial would be the best way to move forward.

In short, serial communication and Mathematica are definitely the bottlenecks for doing things quickly.

I am not familiar enough with the inner workings of Mathematica to know exactly what the upper limit is, but I do know that operations handling files, like OpenWrite and Write work much faster than higher level functions. You can see Arnoud's response here for some information on how to do that with a Raspberry Pi, but I'm not sure that would help you if you plan on using a normal computer (i.e. Mac or PC).

What you could try is to have an Arduino connected to your Geiger counter, then that Arduino would be connected to Mathematica. This would require a library known as Software Serial to have the Arduino be able to communicate with two UART (serial devices) simultaneously. Although, if as you said the Geiger counter only sends information, you could have just the receive pin of the Arduino connected to the Geiger Counter, then the transmit pin going to the Computer. Obviously this would require some hardware modification such that you take care of the UART to USB handling without using the onboard ATmega32u4 as the serial to USB converter.

Anyways, with all of that, you can have code on the Arduino listening for the 1's and 0's from the Geiger counter and be able to handle those at just about whatever frequency you like, then once the Arduino determines, hey something changed that is important, it can then send off a command to the computer and you can either send the raw data trough the Arduino to the computer or have the Arduino do some processing on it (as I said I am not familiar with this device, so I don't know what exactly that data looks like or if the Arduino has the capabilities to process it properly).

I work remotely from Minnesota, but anyways I did somewhat manage to get to 1KHz, but I can't confirm that it was 1KHz, as I don't have an oscilloscope handy, but it appeared to be flickering so fast that it almost seemed steady. I accomplished that by just using

Do[(
DeviceWrite[arduinoObject,<|pinNumber->1|;
Pause[1/2000];
DeviceWrite[arduinoObject,<|pinNumber->0];
Pause[1/2000]),
{1000}]

However when I wrapped that in Timing, it took about seven seconds to evaluate, and the light would flicker as I mentioned for about twoish seconds (again, don't have an oscilloscope handy, so can't confirm the time), then it would flash on and off for about two more seconds, then after that it would stay steady on either on or off, depending on which time I ran it, i.e. sometimes it would end with being on, sometimes it would end with being off. So that leads me to suspect that Mathematica is either doing stuff after sending the commands that takes seven seconds, or that it is getting "confused" with all the serial output such that it doesn't output correctly, on top of being slower than suspected.

Also, thanks for the tip on Mac serial discovery, I may have to integrate that into the FindDevice functionality!

Ian

This is great - it is nice to have this all in one notebook. But I actually meant ArduinoDriver.m file that is currently linked to webpage with an expiration date. That file won't be accessible after some time. If you wish to attach it - your original post can take many attachments.

Hi, 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. 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.

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

If you are curious, you can look into increasing the size of the Serial buffer on the arduino here. 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. 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.

Ian

I'm glad that helped!

And the reasoning I had for putting the device into an always reporting mode is that once one read is triggered, it's likely that more reads are going to be expected, so that was a way to help performance with something like

Dynamic[DeviceRead["Arduino",2]]

or something similar. In the version of the driver that will be released with Mathematica soon, this has changed so that one request provides one response, rather than putting the Arduino into an always reporting cycle.

I reattached the file as an attachment to the post. The file had a limited amount of time it was hosted on the server, and I had thought that the official driver would be in the software by the time it had expired, but unfortunately not. It will be a little bit longer before the official driver (which was derived from this work) will be integrated into the product.

Ian

Hello Ian, thank you for this approach!.

Can I use this with my Arduino DUE board, using the 32bit ARM cortex M3 CPU Atmel AtSam3X8E ? In Arduino, you have to let it download the Board via Boards Manager. DUE has a USB to serial bridge with Atmel ARM ATmega16U2 on board, having its own bootloader. The Sam3X8E also has a built-in USB device. And several Hardware Serial Ports, normally the standard one attached to Serial of 32U4 to get the Program in the chip with normal bootloader and bossac programmer.

I am looking forward for this, because combined with coding from mathematica, one could do an oscilloscope with the 12bit 2MHz 2 ADC's it employs. DAC is also there. And 12 PWMs, etc...

Could you use OpenOCD.org's Debugging features to inject code "live"?

Thanks again

Andi

Hello Ian, unfortunately my ideas are way beyond the skill I reacht up to now. I will try to hook up an arduino micro or nano first, 32u4 / 328P. Then the due...

The temptation is that DUE is not so limited in pin count as are the small arduinos. And the limitation of 10bit DAC, beiing noisy as it is, diminishes together with 4kHz usable sample rate the use as aquisition device. Due would probably stand out there, so I will try.

For you I found a link that mentiones M3 simulation model as open source, so you could swallow it in Mathematica, and it has morphing technology...

Yours

Andi

Hi Jose,

The Arduino firmware as I called it in the post is the same thing as a sketch. They are the same.

A Wolfram Language package is a file that contains Wolfram Language code and definitions that is meant to be portable. It is intended that packages contain useful definitions that is to be used multiple times. It is similar to a library file in other programming languages. You load packages with either the function Get or the function Needs. In my post, << is a shorthand notation for Get.

Ian

I also use <|11 -> 1> but dod not work either.

Yes.. I uploaded using the Arduino loader..

sketch to verify everything is ok with the board. At what speed is the Mathematica download running? Does this matter? My Device manager states that arduino receives at 9600 buds.

NOW IT WORKED!!!!\ I will check again with your link .. But the Wolfram guide in too confusing.

Yes.. I already posted an issue

For ecample, it does not explain hot to get the Device Properties.

-- you have earned Featured Contributor Badge Your exceptional post has been selected for our editorial column Staff Picks http://wolfr.am/StaffPicks and Your Profile is now distinguished by a Featured Contributor Badge and is displayed on the Featured Contributor Board. Thank you!