I am trying to develop a GUI to control a device hooked up on the Arduino. The Arduino communicates with the device through SPI. I have developed a GUI on MATLAB to visualize read by the Arduino. For this, I made Arduino write data from the MISO line to the serial port and MATLAB would read from the same port and do its magic. However, I am trying to come up with a method to write to the MOSI line using the GUI.

Right now I am thinking of making Arduino listen for a particular code (like a character) on the serial port and once it sees it, it will look for an x number of succeeding bytes. The bytes will be formatted in a particular way so that Arduino can then parse it and write to the appropriate registers.

Is there a better way to do this? As a generic question, what's a good way to write to a device hooked onto a microcontroller using I2C or SPI through a GUI?

  • 2
    the GUI should be separate from the communication. develop the communication part first. once that works, add the GUI code. – jsotola Dec 18 '17 at 3:48
  • You can bypass the Arduino entirely, if you want to make this more efficient. adafruit.com/product/2264 EDIT: I just realized how old this is. What are the chances OP needs this anymore? – Tri Aug 15 '18 at 15:00
  • @Tri Thanks for the recent reply. I decided to make the GUI write a configuration file to the serial port and have the Arduino code parse through the same before communicating with the device on SPI. Thank you for the FT232 link though. That will be helpful in the future – Mathews John Aug 26 '18 at 19:58
  • Perhaps we need clarification / definition of "GUI" by the original poster, hence stop mixing "graphical user interface" with "device interface". – Jan Hus Aug 28 '18 at 19:57

I grappled with the same question for a while. Here is how I solved the issue.

1- Find a suitable exchange format and protocol

Here you need to decide what is the most important thing on the communication. Is it speed? Is it error detection? Is it memory footprint? For my project, for instance, I decided that I need my communication to be as error free as possible, with minimal memory footprint (up to 64 bytes) and I don't really care about speed, so I gone for a JSON messaging protocol where the desktop application send a short (up to 64 characters) JSON message and receives a short answer. This solved MY problem, your requirements might be different. If you need speed and don't care for memory, for instance, you can use a binary protocol with a header specifing size, the message and a CRC footer to check vailidity. Or you can use BSON and take this library to avoid the hassle.

2- Define the Serial Polling Cycle How will the arduino firmware knows it is time to send or receive messages? It is always talking? Always ready to receive? It looks at the serial port buffer once each few microsseconds to know if there is an incomming message? How that is handled by your device? If you just need to output data without bothering whether there is someone listening or not, like an GPS device, just throw a Serial.print now and then, but if you need to wait for data, you will have to compartimentalize the process inside an FSM or using some kind of scheduler. If you are not using a scheduler, I recommend this one.

3- Define the Communication Cycle Here you will take the data from serial port and storing it on a buffer for later usage. The trick here is 1- Check the serial FIFO for incomming data. Serial.available() does it already. 2- If there is incomming data, copy the data to next available space in the buffer. 3- Check if there is more incomming data after a few millisseconds. 4- If there is no incomming data, mark the buffer as ready to use, and parse it.

The following code is unscheduled for simplicity,and I recommend you to replace the sleep() calls to proper scheduling least you want the arduino go unresponsive. It is also waiting text data, so you will need to make changes if you are waiting binary data.

  char buffer[64];
  memset(buffer, 0, 64);

  while (!Serial.available())

  while (Serial.available()){
    Serial.readBytes(buffer + strlen(buffer), Serial.available());
| improve this answer | |

SPI is a synchronized interface, it has master and slave. Either you need to switch between slave and master, or you need to provide a way to let Arduino start "reading" from the other end, since the one who initiates the communication in SPI or I2C is a master, in your case, Arduino, I suppose. The simplest way to do this is to provide another line via gpio. As for generic question, to do two-way communication properly, you probably want to choose asynchronous protocol like UART.

| improve this answer | |
  • Does that mean that devices on I2C or SPI cannot be using a GUI; a GUI not running on the microcontroller? – Mathews John Nov 9 '17 at 4:49
  • @MathewsJohn: you don't directly control the SPI or I2C busses from a PC/Matlab, you have an abstraction layer between the two. – whatsisname Dec 13 '17 at 0:34

I had a similar requirement and came up with Wirekite. It is a complete solution based on a Teensy board, some code for it plus libraries for Mac or PC.

With Wirekite, you can hook up digital and analog inputs and outputs, I2C devices and SPI devices (very soon) to the Teensy board and connect the Teensy board via USB to your Mac or PC. You can then control the I/Os, I2C and SPI buses from you Mac or PC. You don't need to adapt the code on the Teensy.

Wirekite uses a custom protocol for the communication. But you don't need to care about that because you can simply use the far more convenient API provided by the Wirekite libraries (.NET for Windows, Objective-C/Swift for MacOS).

| improve this answer | |
  • Ya I guess that's one way of doing it. MATLAB can already do this. There's a hardware package that I can use for the same. I think this is a good alternative. Will look into it. – Mathews John Nov 10 '17 at 19:18

If you want to communicate from the computer to the arduino, use USART. Arduino already has this pre-programmed, as well it's own GUI.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.