In a hot summer of a couple of years ago, trying to not thinking about the stifling heat of the afternoon, I put some efforts in a system which should drive a set of motors and peripherals by means of a single serial line. The idea consists in creating a sort of instruction set, sent over the serial, to transmit and receive informations, but the main effort was to develop this under a robust software, to make the system rensonsive and interrupt driven, fully aknowledged to keep trace of errors also.
This project is born following these ideas, on order of development:
- Driving a low level peripheral using a console, with an affordable and error tolerant firmware
- HW separated by SW, being able to design them finely and independently
- Being able to drive the HW on any type of PCs
- Expliting any software that can handle strings, the only specification is to know the language of the console
- As a natural consequence, a PC connected on the Internet can drive the HW remotely
The main idea
In order to do this, I thought to a concept made of a two stages of control: the microcontroller receive commands from the user and put them in action. But the user of the microcontroller could be another board or PC, not necessarily a human generated commands. This, as previoulsy said, can be made through a console.
In this way the microcontroller carries an “interpreter” which translate commands to the hardware. By this mechanism I split a single action in a confined memory and execution time, affordable and in a responsive way. Due to this software “modularity” it is possible to extend indefinitely the instructions that the micro can interpret and use all of its calculus power to control precisely the hardware desired or manage the instructions in a robust way. The MCU is then only a front-end of the system which receive and sent signals from/to external world. By using a coherent language, the device can communicate with other peripherals (like a PC) by using the serial, and being driven by them directly.
The abstraction layer
The user only see a console over the serial, which work so vaguely similar to the Python line interpreter. But commands are simple, being able to be generated by a software running on another machine which send them to the console. And are simple because this project is at a very early stage. 🙂
Here the user of the console can implement all the algorithms, writing them down to the MCU generated command prompt. With this machanism we already have an abstraction to blink an LED over the Internet, or driving a robotic arm, nothing change inside the MCU. The abstraction give the possibility to personalize the behavior of the device and save in a text file on the PC without the need of reprogramming the chip. Also, but this is not structured yet, can be possible to save this content on an EEPROM or whatever memory support can be reached by the microcontroller, when the console is not directly accessible.
So, anyone can control the device directly or through a PC algorithm. The power of the idea is that if I want to drive a robotic arm, I have sufficient abstraction to drive it directly from another location, making this MCU implementation very suitable for remote control and environment analisys.
At this stage of the project, the software running on an internet connected device is written in the multi-platform Python language, due to its versatility. It reads the console and write commands to it. But here the console is just an echo taken from the microcontroller, elaborated by the Python based SW and printed on the screen. What is important, the user can not know anything of the hardware of the MCU, being free to think to the optimum driving algorithm.
Are also implemented 2 buttons where each control a device bypassing the physical serial console. But due to the modularity of the firmware, when a button is pressed, it is not activated a signal inside the MCU, but there is an auto-generated internal command sent back to the console, by parameter passing without using the USART module. By means of this mechanism, all controls are the same, the code remains modular and there are no performance losses.
A pretty stupid image is shown here, just to make the idea. The light green is what is done inside the MCU, while the light orange shows the basic algorithm of the PC. Between these two colors, there is an USART wrapper, but can be implemented on other technologies, like SPI, I2C, whatever isola supported on the MCU side.
I almost forget an analogy: we can think about a client-server structure. Here, the server is the MCU while the client the Phython based PC software. I like thinking to the old fashioned gerarchy of the computer terminals, a dumb terminal that send commands on a mainframe. But here the terminal is not so dumb compared to those in 1960.
I almost forget to talk about the core. Its based on a 8-bit PIC18F47J53 microcontroller, which can handle very efficiently two levels of interrupts priority. Here I can give more priority to the USART commands instead of those on board, or viceversa, depending on what I desire. For example, when I press a button and I want to be interrupted by the serial, I can put the serial receiving interrupt up in priority. The project was previously born on an Atmega328P by using Avrdude and AVR Studio 6, but then ported on this PIC using XC8 and MPLAB-X, due to better hardware specifications.
Moreover, and I will talk about that on next article, on the MCU board there are two buttons and here are configured to work efficiently like a joystick. The ADC samples a value of voltage on a potentiometer and can set the intensity of the command.
The software on PC is Python based and uses the Pyserial library.
Now as soon as I can find some time to put something on more than a breadboard and when the Python based terminal is presentable (keep in mind what “presentable” means for an electronic student…), I will put something more that a bare useless presentation. I will also put the sources and I will explain better what is going on, trying to be helpful to who want to play with this stuff.
On the next article, I’ll try to explain how to control a motor by using an opposite phase PWM modulation, allowing the analog control of a motor. This can be done also without an MCU, by using only one 555. I’ll see what implementation I will adopt.
Nevertheless, this opposite phase PWM method can be integrated very well with this UART intepreter project: one can drive the motor manually and then an algorithm can decide if that speed must be kept, and so take the control over the device. Yes, I will decisely talk about that in the first release of this project. I will play with the 555 another time…
But I’m afraid that I’ll not find so much time to setup a proper sensor and data acquisition. So, I need to organize myself on order to find time, and this is not a good news.