It’s toooooo much time that I work on my projects without new posts, and I apologize for this.

The fact is that I have -as you know- many activities in parallel to making open source *ware projects: my work (I work in the frame of space projects for artificial satellites, for example I uploaded a little part of me on JUNO, and especially on the Italian part of Juno: the JIRAM instrument), my music (I play in some bands, and I also produce a lot of solo music: check it out and download all at www.marcolastri.net ) … and obviously my family!!! 🙂

It is a great monophonic synthesizer based on ATMEGA32P, with a really great sound, very deep and powerful.

…Have a look to demos on Youtube for the proof of what I’m writing.

I loved the MeeBlip Anode sound from the first time I heard it. In Italy we call this feeling “Amore al primo ascolto”…. 😀

And to me, the greatest thing of MeeBlip Anode is that this incredible project is completely (hardware and software) open source!!! You can buy a pre-built one, but you can also self-produce it in order to play it with your band or to modify/hack it (or both the things, like me ! 😉 )

Well. I obviously self-produced one prototype of Anode and I started to play it in my music projects, but I wanted to add some (in my opinion) important functionality to this great project.

The idea has been of my father Gualtiero which, looking me playing with Anode and modifying the position of potentiometers, said to me: “It sounds very good… but… in which way you know the values for potentiometers?”

Woooow, thanks dad! It was the idea: add a numerical/visual indication of pots values using a display. An OLED display (because the OLEDs don’t have the backlight regulation…so less electronics to add! 😉 ).

And I decided to call this mod “Italian Way” because in Italy we always need visual information. For example think to our famous gestures when we (try to) talk in English to tourists to give them indication on the streets of our cities. 😀

So, I decided to proceed in the following way:

Look in the electronic schematic if ATMEGA32P has some free GPIO to be used in order to command the display (at minimum 6 pins, which is the minimum for commanding the great part of displays)

Since the Meeblip code is written in AVR assembler, download and study the datasheet (and instruction set) of the ATMEGA32P. I was a good assembler programmer once upon a time…but now I am a little older, so… 😉

Find a good AVR driver or set of subroutines for commanding display, written in assembler

Decide which synth values to display on the OLED!

Modify these subroutines in order to display in quasi-realtime, and integrate them in the original code

Modify the original Meeblip code in order to use the display subroutines.

Well…the work has been long (long, long, very long and again looooooooong) and hard (hard, very hard… etc.).

But I think it has been a great work! 🙂

I uploaded all the code on GitHub. I dont know if I well done all the process, but this is the first time with GitHub for me…. 😉

The GPIO pins to be used

I had been lucky: the MeeBlip Anode has some free (and not connected) GPIO on the microcontroller, so they can be freely used to command a display.

They are reported in the following photo:

I decided to use an OLED display by Newhaven ( Mouser code 763-NHD-0420DZW-AG5), which will use 4 pins for data (+ 2 pins for Enable and RS) chosen from PB0, PB1, PB2, PB3, PD2, PD5 and PD6 (plus 5V and GND).

The mapping used for the connection between the display and the ATMEGA32P has been the following:

Display pin 1 (Vdd): VCC

Display pin 2 (Gnd): GND

Display pin 6 (data 0): PB0

Display pin 7 (data 1): PB1

Display pin 8 (data 2): PB2

Display pin 9 (data 3): PB3

Display pin 4 (RS): PD5

Display pin 5 (E): PD6

So… I solded the pins of ATMEGA32P to display pins using a 9 pins male/female connection (such as a simple serial connection). The result has been the following:

The datasheet and code study

Simple step…but very tricky! 🙂

Well, during this step I downloaded the Atmel Studio 6 (freely available) and I wrote some example code, I used the debug function on the simulator and then I created a project based on the Meeblip Anode original code downloaded from Github (and obvioulsy I succesfully recompiled it).

The display driver written in AVR assembler and his

I created the file LCD.inc, and I added it to the Atmel Studio project. Obviously I changed the GPIO assignments in order to match to GPIOs used in my situation. I also added some modification regarding the fact that I would like to display values taken from the RAM of the microcontroller and not from the program memory (as is in the driver). This is the fundamental modification, at line 786 of file LCD.inc:

;lpm temp_lcd, Z+ ; ///ML: removed since this instruction read from Program Memoryld temp_lcd, Z+ ; ////ML: get a character from RAM

And I also added some ad-hoc subroutine to be used in the frame of the modified MeeBlip code. They are the main ones:

MYLCD_PREPARE_GUI is the subroutine which prepare the display inserting the fixed labels (they wont change during normal operation of synth).

MYLCD_UPDATE is the main subroutine used to refresh the display (pots values and switches status). It refreshes tha display on every 100 milliseconds.

MYLCD_CLEAR is used to clear all the display

Note also that in order to display numeric values in the display, a conversion between the values and his correspondent string should be done. For this I found online a very simple subroutine which is called in order to have the values to display in ascii format. This is the subroutine contained in the file SimpleASCIIConversion.inc:

Well… now we can include and use the file LCD.inc inside the original MeeBlip code.

Synth values to display on the OLED

I chose to display the values directly tied to the potentiomenters position and to switches positions. But it is only an idea: you can decide to display also other parameters. 😉

In this hand-made drawing you can see the Anode panel with the names of global variables tied to pots and to switches.

Under each switch you can see the switch number to refer in the code. Under each potentiomenter (in the [] parentheses) you can see the name of the variables used to memorize the pot values.

Note that the pot on the bottom-left is used for two purposes (waveform and width), depending on the position of switch 3. The real variable names for this pot are the following (I know, the drawing is not updated to the last revision of my code…. but I loved to report it in my post 😉 ): WAVETABLE and PULSE_KNOB_LIMITED.

So in the code I managed this in order to display the right values depending on the siwtch position. You can see in file LCD.inc at the labels DISPLAY_WAVETABLE_VAL and DISPLAY_SWEEP_VAL. The choice of the path is done at lines 301 to 303, analyzing the current (and saved in a temporary variable) position of the switch 3.

The other variables names to display reported in the drawing should be OK…. I hope! In any case you can refer to the code, which ever says the truth! 🙂

Integration with Meeblip original code

I included the file LCD.inc after the inclusion of file “subroutines.inc”.

…Bonus Easter Egg (for die-hard geeks only): overclock it!

I am an old style geek… some years ago one of my hobbies was to overclock the CPUs of my computers.

I know that ATMEGA32P can be connected to a crystal with maximum frequency of 16Mhz (following the datasheet). But…I love the risk (hmmmm…. only on electronics things! 😉 ) so I wanted to connect him to a 20Mhz crystal.

With some basic code modification, you can have your overclocked Meeblip Anode “Italian Way”.

These are the modifications.

Firstly in the anode.asm file we change the cpu frequency:

.SET cpu_frequency = 20000000 //ML changed the CPU frequncy to 20Mhz

The other basic modification is the Timer 0 initilization (which is the hearth of the MeeBlip sound generation):

Note that I used the value 62 for r16, instead of theoretically correct value 61, since I used a software tuner to have the best sound (Tunafish for MacOSX) and trying the values around 61.
Then I add a warning also in the initialization of Timer 2 PWM controlling cutoff…

This should be all for this easter egg… but I think you should do many other improvements of the code!

I had no problem and I played (and I’m playing) with great satisfaction the overclocked synth in my home studio for several projects…. but note that nothing is guaranteed with this mod. So handle with care! 😀

Phhhhhheeeeewww (I can rebreath now :-D)….Well geek boys & girls, that’s really all for this time.

It was a long time without a post on Garretlabs, but with this one I think I paid my debt with DIY community and to Garretlabs readers!

Because today we talk about a high-scalable videosurveillance system called RasPI-Surv, based on:

A system controller based on Raspberry PI

A practical (and modifications-friendly) command/telemetry interface via SMS messages, using the very well known SIM-900 module from ITEAD.

A set of wireless video cameras with good motion detection feature

A internet router/modem with wireless access point

A Google Mail account (it will be your “house account”), to be accessed via IMAP.

I engineered this system after a very strange request from one of my strangest friends. 🙂

He was looking for a “internal” videosurveillance system with motion detection to be used only during his vacation periods…and after the vacation periods he wanted to disable the system and put all cameras and controller inside a box! 😉

In other words he wanted a “portable” internal video surveillance system, without in-the-wall connections, without fixed positions for the cameras, so a very dynamic system with the opportunity to move the cameras and the controller inside his house. Plus, he wanted a powerful and portable alarm siren to be placed in his house, without external components (please note that this DIY solution is not accepted by italian laws, so in our country the alarm device must be always placed by a devoted an credited technician).

A practical example of the siren 12V powered could be THIS …but you can buy another model following your needs.

Firstly I placed the cameras near a wall power socket (ok, they are wireless..but unfortunately they need power… 😦 ), then I connected all cameras to the internet modem/router following their own user guides.

Finally I enabled their motion detection feature with the email sending (using the “house Google Mail account”) of the captured frame when a motion is detected.

Note that for some camera, a fast tramsition from day to night vision and viceversa (i.e. a sun ray refled by a passing car in the street) could be recognized as motion (so as a false alarm by the system 😦 )…so the best way to place the camera is in front of closed external doors without glasses and of closed windows with the rolling shutter completely closed.

Well… do you placed the alarm siren and cameras? Have you configured your cameras in order to connect to your modem/router and to send an email using your Google mail account when a motion is detected? Very well… we can go ahead with the system idea.

This is the overview schema of the system (as always drawn by hand by me, sorry for the bad photo! 😉 ):

…In practice at this moment we have all cameras connected to our modem/router and a alarm siren connected to the power thru a relay commanded by the Raspberry PI. So, we must to setup the Raspberry PI in order to execute the following operations/requirements:

Periodically it should check the SENT folder of your Google Mail account, in order to verify if one of your IP cameras detected one motion (and so they sent an email using your “home account”). The cycle should be fast because one burglar can be very fast to open a window and to move in your house… 😦

If one or more email arrived from your cameras, it should activate the relay in order to power ON the alarm siren

In this case it shoud send an SMS to your mobile phone in order to advise you that the siren has been powered ON

It should manage a set of SMS commands in order to: force the power OFF of the alarm siren, enable and disable the check of the sent emails, cancel the SMS memory of the SIM900 module, reset or reboot the system etc.

It should send a set of SMS in order to advise you that there is some problem (i.e. the internet connection is down, so the Google Mail mailbox can’t be accessed).

Well. It is’nt so difficult to implement it all. If you you read first these previous posts from Garretlabs: THIS ONE (it uses a GSM dongle and the software gammu in order to receive/send the SMS messages, plus to command the GPIO pins of Raspberry using Python) and also THIS ONE (it uses the SIM900 module and the AT commands in order to receive/send the SMS messages).

This is the Fritzing schema of the controller Raspberry PI+SIM900 module used to command the relay for the alarm siren:

I propose you the complete code of my project…. so you can now start playing with the RasPI-Surv system

The Sparkpunk Sound generator is a very interesting sound generator similar to the famous ATARI Punk Console, The Sparkpunk Sequencer is a control voltage step sequencer used to control the the Sound Generator.

After the assembly of the two devices, I played some hour with these objects… but, as you know, I am a (pro-am) musician, and I would like to have a MIDI IN port in all my instruments. Because I attach my devices to my DAW (digital audio workstation, examples are: Steinberg Cubase, Ableton Live, Cakewalk Sonar, Apple Logic Pro etc.) resident on my computers (Mac or PCs), and my DAW is ALWAYS the MIDI master for my set of instruments. I should command the tempo, the start and stop of my devices.

Before to do my modifications, I printed (and read) the following IMPORTANT page: https://learn.sparkfun.com/tutorials/sparkpunk-sequencer-theory-and-applications-guide . So, firstly I followed the steps for modifications in the section “Synchronizing Multiple Sequencers” and I opened the connections between IN and OUT for the pins CLK, BTN, RUN, STOP (and I used jumpers in order to re-close them again, in case the sequencer isn’t controlled from another device and it used stand alone).

After this, I thinked to use an Arduino UNO as interface between my MIDI master (the DAW) and the Sparkpunk Sequencer in order to force the Sparkpunk Sequencer to follow the MIDI clock of the DAW. This is the actual setup of my experiment:

In order to build logicaly and electrically the interface between Arduino and the SparkPunk Sequencer I studied the signals on the CLK IN, BTN IN, RUN IN, STOP IN pins in the Sequencer stand-alone configuration (so the CLK IN is connected to CLK OUT, BTN IN is connected to BTN OUT, RUN IN is connected to RUN OUT and STOP IN is connected to STOP OUT… using my preferred tools: the jumpers!).

I studied them connectinfg the oscilloscope on the pins and pressing the Run button on the Sequencer in order to start and stop the sequence. These are the results (drawn by hand… it’s so stylish and vintage! 🙂 ):

Well… as you see the behavior is very simple. And we can simply replicate it using Arduino with the following logic:

When Arduino receives from DAW the MIDI START message it commands the RUN IN pin high, the STOP IN pin low and BTN IN pin firstly high and after a short delay (I used 5ms and it works…but you can measure the real value with the oscilloscope if you want) it commands it again low.

When Arduino receives from DAW the MIDI STOP message it commands the RUN IN pin low, the STOP IN pin high and BTN IN pin firstly high and after a short delay (I used 5ms and it works…but you can measure the real value with the oscilloscope if you want) it commands it again low.

The CLK IN value is commanded by Arduino following the reception of the MIDI CLK message, in order to synchronize the tempo of Sparkpunk Sequencer with the DAW tempo.

IMPORTANT Note: a standard MIDI CLK message is sent by a DAW 24 times per quarter note. A time of 120 BPM (beats per minute) is equivalent to 120 quarter notes per minute, so in this case the DAW sends from the MIDI out (120*24)/60 messages per second. It’s too much for our Sparkpunk sequencer(if you sends all these messages to ther sequencer, it doesn’t work…and you can’t see the ON/OFF of the Rate led).

So I decided to send to the SparkPunk sequencer only one MIDI CLK message per 24 received by the MIDI IN port on Arduino. In other words Arduino decreases the rate of MIDI CLK message in order to correctly command the sequencer.

Regarding the hardware connections, the are very simple:

Connect the Arduino GND to a GND point of the Sparkpunk system (i.e. the ground of the Speaker port on the Sound Generator)

As you see I used for the CLK IN a square wave with a period of 200 ms (100 ms high and 100 ms low). It seems sufficient in order to command the step ahead of the sequence.

Ok, using this sketch and starting the MIDI clock on my DAW, the Sparkpunk Sequencer starts working, exactly synchronized with the DAW (and the sound is correctly generated by the Sound Generator). Modifying the BPM tempo on the DAW causes that Sparkpunk SEquencer changes correctly his tempo, and it correctly starts/stopswhen the start/stop command is sent by the DAW. Yeahhhhhhhhh! 😉

But.

Yes, there are always some “But” in my projects. 🙂

In this case there are still some strange behaviors of the system, to be investigated and debugged (also with YOUR contribution, my dear followers, if you want):

The Sequencer start working also if the POWER switch is OFF, and at the same time the . It’s clear that the sequencer and sound module takes power from the 4 pins connected to Arduino…

In this condition the ouput volume of the Sound Generator is a little low… maybe the Arduino doesn’t drive the correct power supply to all the system. 😦

In this condition (POWER switched OFF) only the LONG pulse works, if I switch on SHORT no sound is emitted from the Sound Generator.

If I change the POWER switch from OFF to ON on the sequencer (or on the Sound Generator), only the SHORT pulse is emitted (if I switch to LONG pulse no sound is emitted)

Finally, in this case (POWER switched ON on the Sequencer) the output volume of the Sound Genrator is higher.

I think all is tied to the fact that Arduino power is not sufficient to drive all the circuits (Arduino itself+MIDI interface, Sound Generator and Sequencer), and to the fact that Arduino uses 5V as HIGH value for the CLK IN, but Sparkpunk sequencer uses 7.5V. See also the paragraph called “Switch Voltage Processing” in the https://learn.sparkfun.com/tutorials/sparkpunk-sequencer-theory-and-applications-guide …I think it is very involved in this behavior of the circuit. I’m continuing my investigation.

Another solution I would try in the near step of my experiment is to use a MOSFET commanded by Arduino pin D5 (connecting the D5 to the gate pin, the CLK IN to the source pin and the CLOCK OUT to the drain pin, for example), in order to control the synch pulse on the CLK IN connecting it to the CLK OUT (something similar to a electronic switch), in order to have the same situation of the stand alone Sequencer configuration, but generating the clock pulses using the MIDI tempo. It’s a solution similar to which used in this video from Sparkfun: https://www.youtube.com/watch?v=LUcqDM4k1gU

Well… but now, after this ordeal, I’m really ready for a glass (…a bottle?) of my preferred grappa. If you know what I mean. 😉

..Hi, dear techno frieds (obviously male and female)!
My holidays unfortunately ended some day ago, and now it’s time to restart the work in my garret (and in the Garretlabs). It seems that your visits to my little blog during August increased…so many many many (many) thanks to you all! 🙂
Once returned from my vacation, my dear friend Luka Cekka (it isn’t his real name, so he isn’t a Russian guy, but a real Italian guy, and he is a “spitting image” of Tim Robbins in “Antitrust”…have you seen the movie? 😉 ) asked to me to realize a thermostat with touch screen for his new house thermo installation.

Once created the “sandwich” with Arduino, the breakout shield and the TFT, I connected to Arduino the DHT22 and the alarm led on the breadboard.
This is the Fritzing diagram (please, see the note and pay attention to the use of Arduino pins in order to drive the Adafruit TFT):

Regarding the software, I started using the following ad-hoc DHT22 library (and one very useful example found on internet) and verifying that the sensor was OK (and the alarm led ON/FF strategy).
Secondly, I added the code to manage the visualization of the temp on TFT, starting from the well coded examples from Adafruit libraries.
I decided to have two software modes: in the “temps” mode you can see the actual temperature acquired from DHT22. In this mode you can touch the software button “SETUP” on the touchescreen in order to enter “setup” mode. In “setup” mode you can adjust the alarm temperature using two software buttons on the touchscreen (one “+” button and one “-” button). You can return to “temps” mode touching the “TEMPS”software button. …All simple! 😉

Note that on the screen there are four temperature values: I’m now working on a more powerful application in order to match Luka request (he wants to use four DHT22 sensors in his house… I think I will use a input multiplexer with the Arduino UNO, or more simply an Arduino Mega! 😉 ).
But you can use this project in order to add the powerful Adafruit TFT touchscreen to your application.
Only two notes on the Adafruit TFT:1. the screen refresh is slow (very slow in my opinion), but it’s an acceptable issue in embedded projects2. the touchscreen is natively very sensitive to human touch, so if your touch is “too long” it will be detected as a multiple touch. You could implement some “low-pass software filter” (i.e. you could manage the touch only after a multiple touch).

Well boys and girls, now you have a thermostat with a touch screen for your hi-tech house. I hope Luka will be happy with his new toy (but I’m not sure..he is a very perfectionist guy! 😉 ).
…But attention friends, the touchscreen will record your fingerprints ;-), so clean it with attention…especially if you don’t like CSI! 🙂

Well… during these days it isn’t a good idea to remain in a dark and little microelectronics laboratory, it’s a better solution to close your laboratory in order to go in a good house/hotel by the sea (or at the mountains)! 😉

So, today Garretlabs wants to propose you a very simple (but) all-in one solution of house anti-intrusion alarm system, based on Arduino UNO.

This basic idea is very compact (but you can add all the subsystem you invent/want):

we will monitoring a set of house internal doors via a “wired connection”, using the digital in/out Arduino pins in order to detect a door openting (…I confess: this is inspired from a old joke which I knew 😦 during a high school week at the mountains … as we say in Italy literally “White Week” that is “Settimana bianca”)

we will also manage a ultrasonic sensor in order to monitoring tha opening of another house internal door

in case of door opening detection, we will send an alarm email using the well known Arduino Ethernet Shield

This is, as usual, my hand-made design of the system 🙂 :

The part list is (as usual) very short, because my goal is to use (when possible) only the parts present at the moment in my …garret! 😉

One Arduino UNO

One Arduino Ethernet shield

One ultrasonic sensor

Assorted cables (never too many! ;-))

This is the Fritzing circuit (click on the image to see it bigger):

Well, remember to the Arduino place in a safe and fixed position in the house (for exaple fixed on the roof or fixed inside a electrical box on the wall) because if someone will open one of the doors connected by wire, our goal is that the wire will be disconnected from one of the two used Arduino digital pins (in order to open the controlled signal circuit).

Now, let’s go to code some line. The ultrasonic sensor is managed by the excellent newPing library, and the code to send email using the Arduino Ethernet shield is took from the my preferred site about Arduino resources (the only and one Arduino.cc …”made in Italy” rules! :-)), and modified by myself. The specific link is the following: http://playground.arduino.cc/Code/Email.

As you know I am also a musician, and I produce freely downloadable music from my music website www.marcolastri.net (only italian language, sorry! ).

I have a large set of keyboards and synthesizers in my studio, and I have also a Roland AX-7, a “wearable” MIDI controller keyboard similar to a guitar (today these instruments are called “keytars” 😉 ). This keytar is used also by the mighty Herbie Hancock…. 😉

This keytar has also a great feature: it can be power by 6 AA batteries….but you will have always the midi cable in order to command your sound generator or expander (or software synth etc.). The midi cable is a limitation to your performance freedom on stage…so I want to cut it! 😉

Then I connected these components to two Arduino UNO boards in order to realize: one component working as MIDI Receiver-XBee Sender and one component working as MIDI Sender-XBee Receiver.

Thi is the system overview…design handmade by ML! 😉

First step: program the XBee modules

This is the more complex step…I don’t love it but (unfortunately) it is necessary.

We must to setup the Series 2 modules in order to enable the “AT mode” communication (the Series 2 chips support also another -more complicated- configuration, in order to realize very complex networks of XBee modules). In other words, we must to program the devices in order to simulate a point-to-point-connection, a true serial wireless connection.

After this, I attached a wire to the RESET pin of the Arduino and I connected it to GND. Then I connected the XBee Shield with the XBee module onboard (remember to set his jumper on “USB”): this is the way to directly access the XBee modules for programming them using Arduino board USB connection. In other words, to program the XBee modules it’necessary to disable the ATMEGA chip, so…or you remove it, or you connect to GND the RST Arduino pin. 😉

So, I used as network ID the suggested number (1234), then I configured one module as Coordinator AT (setting in the values SH/SL of serial number of Router module), and I configured the other module as Router AT (setting in the values SH/SL of Serial Number of Coordinator module).

IMPORTANT NOTE: I used the default speed of serial connection (9600 bps) for XBee modules, since I noticed that if I change the data speed, the USB connection from Arduino IDE to Arduino in order to download applications should fatally fail.

Second step: the MIDI receiver-XBee sender

The difficult step is passed…so, one moment of relax now! 😉

Ok, let’s start with the secdond step.

This MIDI receiver/XBee Sender has one MIDI connector in order to receive MIDI signals from a synthesizer, the software collect them, then it uses the XBee serial link to send MIDI signals to the other system component (see the third step).

The circuit is very simple…. and it is based on the standard MIDI-IN circuit. See http://www.midi.org/techspecs/electrispec.php to see the details. I modified it a little (especially the optocoupler)…in order to match the parts I had in the “Garret” at the moment 😉 !

The components are:

1x Optocoupler 4N35

1x Diode 4148

1x 100KOhm resistor

1x 220Ohm resistor

1x 3.3KOhm resistor

Note that in the schema I added the XBee module and the XBee shield on the right side of Arduino, in order to better explain the connections, but OBVIOUSLY their must be mounted ON the Arduino! 🙂

The software is simply a MIDI messages collector and re-sender.

Note that I used a buffer to memorize a certain number of MIDI message before to send them, because if wen I receive a message I resend it immediately, I could loose another MIDI message incoming in the meantime. So, I used a “buffering approach”. I verified -as musician 🙂 – that the latency due to buffering is very (very) low, so this approach is acceptable. 😉

Note also that I use the Software Serial (the RX is on pin 10) to receive MIDI messages, because XBee must use the Serial port.

In order to write the program on Arduino, you must set the XBee jumper on “USB” position (and obviously you must to remove the cable to ground connected to the RST pin…see step one!). After programming, you should set the jumper on “XBee” position.

Third step: the MIDI sender-XBee receiver

Well, this component is more simple than the previous: it receives the MIDI messages from Xbee serial wireless link and it resend them to the MIDI Out port, in order to command a sound generator, a expander or another synth.

Only one component in this case:

1x 220Ohm resistor

This is the (simple) circuit. As you can note, the MIDI In and Out circuits are NOT mirrored (this is the standard)! ….What a strange design choice!!! 🙂

To test the system you can connect a master keyboard (better if it is a keytar! 😉 ) to Midi Receiver-XBee Sender and a sound generator to Xbee Receiver-Midi Sender…. and you can try to emulate Sandy Marton’s (one of my 80’s Italo Disco heroes) performances with their faboulous keytars!

This is the mighty Sandy in one of his mighty performances:

Well… it seems a DIY keytar!

Bye bye people, now I go to play some note with my AX7…I need a music overdose (I think today I will write an italo-disco song)! 😉

So, the behavior of code should be very very (very) simple: 10 milliseconds the led is ON and 10 milliseconds it is OFF. So the GPIO2 output is a 5V square wave, with a period of 20 milliseconds and a duty cycle of 50%.

I connected the channel 1 of my oscilloscope to TestPoint1 and the channel 2 to TestPoint2.

As you see the behavior of the two boards are very different: since the square wave of Arduino UNO (TestPoint 1) is fixed on the timeline with a period of 20 milliseconds, the square wave of Galileo is moving on the timeline and it has more long period than 20 milliseconds. It means that the period is not exactly 20 milliseconds, and it is variable.

This is the trace for Arduino UNO:

As you see, the square wave is perfect (…note that the horizontal scale is 10 milliseconds for division)!

This is the trace for Intel Galileo (stopped in a certain moment, since the trace is continously shifting right):

Well...in this case the square wave has a period major than 20 milliseconds (because each half wave has a duration major than 10 milliseconds).

Plus, if we measure two random periods, they havent the same duration (the continuous shift of the trace is depending on this).

These are both waveforms:

So, for me the result is clear: since Arduino UNO commands GPIOs using a very strict realtime, Galileo does not command GPIOs with a realtime scheduling politics.

The motivation can be probably tied to the fact that Galileo launches Arduino scripts as Linux user processes (as I noticed in my prevoius post), so without realtime characteristics.

My conclusion is that, at the moment, we can’t use Galileo as hard realtime controller for particular hardware (ie. safety critical mechanisms and so on). 😦 …

And what are your thinkings about this behaviour of Galileo? Have you found my same results?

Obviously, possible solutions and workarounds are welcome (I thinked to modify the Intel Galileo native Linux in order to add some realtime extension, i.e. RT-PREEMPT or Xenomai).