February 04, 2014

If you want to use special techniques to get performance out of the not-Arduino on board, then that’s fine.

When I was a consultant, I noticed that customers usually think that what they are doing is the most amazing thing in the world. Even the company that made trash compactors seemed to think it was exciting. I guess that’s how you get through the day.

The other effect I’ve noticed — and I think it is getting worse — is that people tend to develop irrational love for some tool or product and then eschew other tools. I have a lot of faults, but I mostly stay out of that trap. As you probably know, I do have the irrational fan boy fixation on emacs, but other than that I’m pretty equal opportunity with tools. I’ve written code in dozens of languages and used more microprocessor architectures than I can count. Sometimes it was because of what the job demanded. Other times it was because it was the right tool for the job.

I enjoy programming in C and C++. But if I am writing something with a network socket, I’m likely to turn to Java. I write a surprising amount of string processing code in Awk or Perl. I’ve written Forth, PL/I, and going way back a bunch of FORTRAN. None of those are the perfect language.

I find that’s an unusual thing. Many people cling to their language of choice even when it makes them jump through hoops to do some task. I see the same fixation with processors, operating systems, and just about any tool. I suppose it is natural to want to use what you know, but it is all too easy to slip into fan mode.

I’ve been accused of being a Java hater, an Arduino hater, and a Mac hater (well, there might be something to that last one). The funny part is I’ve used and written about Java and Arduino quite a bit. I am just realistic about their limitations. C++ and C# both have their limits too. Most of the other languages I mentioned have huge limitations.

This comes to mind because I got quite a few comments about the last blog regarding Intel’s super Arduino named Galileo. My point was (and still is) that if you expect people to use it like an Arduino, they will use it as an Arduino. In testing, if you use it like an Arduino, it is going to be slow.

Now, I’m all for using it as a Linux board (I’m dangerously close to being a Linux fan). If you want to use special techniques to get performance out of the not-Arduino on board, then that’s fine too. I mentioned last time that I knew there were special techniques to get better performance out of the board. But, in fact, if a typical Arduino user buys this board and a shield and tries to use the library that came with it (much as I did the LCD code), it will either be slow or it may not even work. Only a few people will dig into a library and update it with special calls.

For the record, here’s the fastest way I could find to toggle a bit on the board:

uint32_t outlatch;

void setup() {
  // put your setup code here, to run once:

void loop() {
  // put your main code here, to run repeatedly: 
  int x=0;
  while (1) 

This outputs a square wave just under 3MHz (see the figure below). That’s not bad, but the key is that you had to do special gymnastics to get there. A reader pointed out a page that had several tricks like this. But I still say that this isn’t useful if you are trying to use off-the-shelf Arduino libraries. After all, that’s the power of the Arduino is the vast array of plug ins (both hardware and software).

If you read the FAQ, by the way, it indicates that the frequency the GPIO can achieve is 230 Hz because of the I2C port expander. Clearly the fast latch technique must bypass that, but I haven’t dug into exactly how that works yet.

Just to be clear, I don’t hate the Galileo. But I do think its Arduino support may miss the mark for the majority of the Arduino target market.