Blogs

While everyone is crazy about the Raspberry Pi, I'm pretty skeptical about it. Why? Well, because it's a closed source hardware based upon a BGA microprocessor using a 6 layers PCBs.

What does that mean? Well, it means that it's really a pain in the ass to create derivative projects from it.. So, although the Pi it's a really awesome device, it's almost impossible to create a product from it.

With this in mind, I started to look around for alternatives and I found the Olinuxino Maxi, a single board Linux compatible computer based upon the i.MX233 microprocessor, designed by Olimex.

Why this is much more interesting for me? Well, first of all, it's a complete Open Hardware project so the schematics and PCB designs are available released under CC-BY-SA so that we can take them and modify as we like.

Second very important aspect is that it is based upon a QFP packaged microprocessor using a 4 layers PCBs. This means that we are perfectly capable to solder it by hand and getting PCBs for it cheaply (through OSH Park for example).

This can very well support the creation of derivative hardware starting from the original Olinuxino designs..

So, I got one of these boards and in the following video I show it running with ArchlinuxARM.. looking pretty awesome so far.

What do you think? Should we all use Raspberry Closeberry Pis or look for more open and easily hackable alternatives?

The past months have been characterized by many big news in the quadcopter and multirotors world. The arrive of many 32bit software and hardware platforms has been seen by many as the upcoming death of the 8bit flying controllers (read Arduinos).

While this may be true eventually in the next years, there is still many people working on 8bit flying controllers, producing great code and awesome results.

I'm obviously talking about MultiWii, even if based upon simple 8bit Arduinos, with limited memory and performance, it is still improving and providing awesome results. It's not unusual to see MultiWii copters flying much better than fancy 32bit ones.

Since I'm a big fan of MultiWii, I'd like to thank all the developers and the testers of this firmware. Thanks guys!

I'll finish this post with a great new video from my friend Warthox, one of the best quadcopter pilots around. He shows us his perfectly trimmed copter, using custom firmware ESCs, with the new GPS and altitude hold features and improvements.. and of course, he uses a FreeIMU!

The hacking started when we connected the Leonardo to the NFC and discovered that I2C, the default hardware communication bus used by the shield to communicate with the Arduino, was not working on the Leonardo. This shield, even if already designed for Arduino UNO R3 pinout, wasn't working with the Arduino Leonardo at all! This blog post is a small summary of what we did to address these issues.

We started investigating the problem.. the first strange thing worth noting is that this shield, even if it comes with the various Open Hardware logos on it, it doesn't actually have any shematics nor EDA CAD designs available The designs were actually available on Adafruit github but simply not linked from the product page, that's why we missed them. So, we had to kind of reverse engineering the shield in order to understand the problem.

So, the first problem we discovered is that the IRQ pin of the PN532, used to signal the microcontroller on a successful read, is connected to pin Digital 2 on the shield.. this is not good at all with the Leonardo since D2 is also I2C SDA making communication impossible. Fixing this was as simple as cutting out the trace going from the IRQ pin into the D2 pin on the shield.

We decided to use a two ways on-on switch (see picture below) connecting IRQ to D2 in one position and IRQ to D8 in the other position.. the idea was being able to switch between D8 and D2 when used with UNO or Leonardo respectively. On a second thought, it is probably better to move that to another pin usable on both the UNO and Leonardo.

The next problem we had to address was a pin conflict: this shield connects I2C SDA and SCL both on the new SDA and SCL pins on the new Arduino UNO R3 pinouts (top left near the various digital pins) as well on the legacy A4 and A5 pins used for I2C in legacy Arduino Duemilanove and previous boards. Fixing this was as simple as cutting out the traces connecting I2C to A4 and A5.

With a small modification to the reference code from the Adafruit NFC library (attached below), instructing the library to use D8 instead of D2 as IRQ connection, we finally had a perfectly functioning NFC shield with I2C on the Arduino Leonardo!

Suggestion for Adafruit: in case backward compatibility with legacy boards is needed, I'd use a 2 ways on-on switch (eg: JS202011SCQN) allowing the connection to A4 and A5 when needed on legacy boards. Solder jumpers will work too.

The past Saturday me and Franco met up at Fablab Torino to solder the PN532 NFC/RFID breakout board from Adafruit/Microbuilder. This should be a pretty good learning platform to dig into NFC/RFID.. stay tuned for more on this...

Btw, Franco had the nice idea of making a timelapse of the day.. here it is.. almost 6 hours of bloody soldering!

Result? Well, the chip communicates fine with Arduino but it still didn't recognize any RFID tag: I found out that the RF inductors were completely wrong (ordered a different part), so I hope that once I get them it will work. Stay tuned ;-)