Twittering and signatures

One of the things that I want to be able to do at some point is connect to a server using a secure socket.  That's a little way off yet, but isn't so distant that I can put it out of my mind.

Many Internet-of-Things devices might want to connect securely; and more than that, robust authentication is also necessary.  Simple authentication is being discarded and OAuth is starting to become the norm for services such as Twitter and COSM.

In view of that, I constructed an example a little while ago that will sign a Twitter API call using an HMAC-SHA1 signature.  Rowley Associates has an established history in all this crypto boffinry as we wrote compilers under contract to Microsoft for their smart card virtual machine, and we also wrote the SmartWorks for MULTOS product which was bought out, rebranded, and now rests with MAOSCO as SmartDeck.  This signing code isn't hardcore crypto: it's rather simple, in fact.

So, if you're interested in the signing code, you'll find it here:

http://www.soldercore.com/manual/corebasic_twitter_oauth_signature.htm

This example takes the example from Twitter of constructing an OAuth signature and codes it up in CoreBASIC.  When I run the program, I get the correct signature:

So, we're on the way to direct posting to Twitter without using a proxy application!

Classic Controller + Ardumoto = Kiddie Toy

Today I turned my attention to the list of e-mails that I receive outside the helpdesk about CrossWorks and SolderCore.  With a weekend and a couple of extra days off, you wouldn't believe the amount of stuff that piles up!  It's amazing how many customers can order the wrong thing, or how many can't read the manual, or can't even be bothered to look at the CrossWorks manual and use the helpdesk as an on-line help resource.

With those things put to bed, I turned to a question about the PWM output of the SolderCore when a pin is configured as a digital output. I hooked up a scope to the PWM output of the SolderCore and things actually looked good, pretty much as I expected. I need to test some more tomorrow to confirm things.

To put this to good use, I wrote a small CoreBASIC program that uses a Nintendo Classic Controller to control the left and right tracks of a hastily-constructed robot. From the bottom up, the robot is built from a Polulu chassis and motors, a liquidware LiPo battery pack, a SparkFun Ardumoto, a SolderCore, and a SenseCore with a CoreWii adapter fitted:

Here's the CoreBASIC application to exercise this contraption:

' Call up required drivers.
INSTALL "NINTENDO-CLASSIC-CONTROLLER" AS CONTROLLER
INSTALL "SPARKFUN-ARDUMOTO" AS MOTORS

' Run until I die.
WHILE TRUE

  ' Read vertical positions of both controllers.
  THROTTLE = CONTROLLER.V

  ' Ask left and right motors to follow the joysticks.
  MOTORS.LEFT = THROTTLE(0)
  MOTORS.RIGHT = THROTTLE(1)
WEND

END

Now when you move the left joystick forward or back, the left motor's speed and direction follows. Same for the right motor. When you pop the robot on the floor, you can drive it around just like when you had one for Christmas!

I'll blog a bit more about PWM tomorrow along with controlling the robot with a Nintendo Nunchuk controller, as long as I have some spare time.

Tidying up and Pressure Sensors

So I came into the office at the weekend to do some tidying up before going away to Wales for my wife's birthday surprise.  I didn't expect it to snow, and where we're going to stay is in a red Snow Warning area.  Great!

I took the opportunity to start sorting out the multitude of sensors I've been ferrying back and forth between the office and the Curtis family home each day.  My rucksack is usually stuffed with bits and pieces that I convince myself I might need at home for the night's coding, but in reality I only ever break out a couple of items and concentrate on them.

So today I mounted a SparkFun BMA180 breakout on a SExI prototyping board, wire-wrapped the connections, and tested that I could address the accelerometer.  Sure, yes, that worked, so I'll write a driver for it one evening as all the Bosch Sensortec acceleration sensors have the same type of memory map and set of capabilities.

But I also constructed a shield to take the DIL modules that ST provide for evaluation of their sensors. I happen to have an LPS331AP DIL module, so I plugged it in and labeled the shield so I know what it's for.

The easiest way to test the sensor out is a few lines of CoreBASIC.  Telnet into the interpreter and type away!  I know my device has address 0xBA and the LPS331AP has a "Who Am I" register at address 0x0F that should read back 0xBB.  Will it?

>i2c 0xba write 0x0f read 1 to x
>print hex expand x
["BB"]
>

Excellent!  It does!  I can address the sensor and away we go!  After a bit of reading and coding, I constructed the C and CoreBASIC drivers for it:

>install "lps331ap" as lps331
>print lps331.temp
26.3229
>print lps331.pressure
99078.1
>

OK.  Brilliant.  That driver will make the next release of CoreBASIC!

Just time to finish up, tidy up, wrap up, and go home.

Back to the Freedom Board

I am composing this using my new IPad mini so please forgive any mistakes that I might make.

So, today saw a few inches of snow on the ground. Walking into the office wasn't too bad, and watching the comedic teenager in his red Astra gunning his engine trying to tail slide around a roundabout was interesting.

On arrival, the usual morning ritual of turning on the espresso machine, the computer, and looking at the build and machine status lights was all pretty run of the mill and uninteresting. Had to deal with a few tickets before turning attention to testing the AVR product.

With the delivery of some additional Xplained sensors, I started work on completing a driver for the Kyonix KXTF9 on one of them. This was a continuation of last-night's coding session where I started out but couldn't decipher the meaning of the ADC counts in the data sheet. After a while, it was written and tested and the AVR merrily produced quaternions from fusing the sensors. The gratifying thing was that they even looked right!

It's no good trying to write portable code if you only test on one platform, so I regenerated the project files for the SolderCore and Freedom board to test there too. I took a prototyping shield and wire-wrapped a couple of connectors to make an Xplained site I could mount the three Xplain sensor boards onto. All very good. Testing with the SolderCore revealed nothing problematic, but the Freedom board was proving to be a bit of a jerk. In the end, I decided that I really needed to bite the bullet and write the Kinetis I2C platform drivers using interrupts rather than relying on polling.

Well, it transpires this isn't quite as straightforward as I had hoped! Having completed the interrupt-driven drivers for the Arduino, all I can say is that the AVR has a great i2C engine and that the Stellaris and Kinetis parts really don't. The Kinetis reference manuals are very light on detail, probably expecting you to use some vendor-supplied, tested source code. Well, that's not the way we roll here, I write my own software!

After a few hours with a Logic probe (great software supporting it), I figured something was wrong. It transpires that there may well be an undocumented silicon bug in the Kinetis silicon. More investigation when I get time.

There was a bit more excitement in the office over the Raspberry Pi, but that deserves its own posting sometime next week.

Today's Attitude

So, today I continued testing the forthcoming release of CrossWorks for AVR.  Actually, I'm also testing CrossWorks for MSP430 at the same time.  But for now, let's get back to the AVR.

Digital MEMS sensors are usually connected with I2C.  Now, to bring up the Arduino version of the CrossWorks Platform API quickly, I wrote the code to do GPIO to all the header pins and then pressed the software SPI and I2C drivers into action to get the first-cut implementation going on an Arduino Uno and the Olimexino-328.  However, that doesn't use the AVR's hardware resources to their best, so I started writing interrupt-driven I2C bus code.  As a consequence of this, and because of the way that the AVR I2C engine works, I needed to rework the high-level code that sent I2C requests to the bus.

Now, one of the problems with an mid-level framework API redesign like this is that some clients need to change and all implementations needs to change.  As it turns out, the I2C redesign has a positive benefit for all of the code, and it spurred me to carry the redesign over to the SPI mid-level API too.

So, with this new I2C driver, I can successfully interface all the I2C sensors that we support, including MPU-6050 and HMC5883L that are fused by the CrossWorks library's Attitude and Heading Reference System (AHRS).  The AHRS code takes the measurements from accelerometer, gyroscopes, and magnetometers and updates an estimate of the orientation of the body frame as a quaternion.  This is pretty cool stuff because I can fuse any of our supported sensors into an AHRS, but it just so happens that the MPU-6050 and HMC5883L are built into the CoreMPU board you can find here:

http://soldercore.com/products/sensecore/corempu/

Well, along the way I figured out a few things that I needed to do in CrossWorks, and I also figured out that I had left my debugging code in with a huge array, which caused me to run our of RAM when compiling the orientation demonstration.  At the end of the day, the AHRS was delivering quaternions, but it wasn't updating.  A quick look at the code revealed that I hadn't implemented a high-resolution tick to measure elapsed time between sensor readings, so the code that updates the orientation would go through a whole bunch of computation and, effectively, multiply feedback terms by zero which meant there was no feedback!

So, tomorrow I get to implement a 32-bit free-running timer that will be enough to time accurately for the AHRS.  And then we'll see how the fixed-point and floating-point AHRS code performs on AVR!

CrossWorks and SolderCore, the Platform API

For a long time now, I've been working on an API that will help customers, and particularly hobbyists, get up and running quickly with CrossWorks and SolderCore.  The decision process on what to put into the API, and particularly what to leave out, was interesting.

At Rowley Associates we have a whole wall stacked with magazine files which contain each and every ARM board that we have acquired.  Right now, the tally is over 600 ARM boards.  Most of these are supported in CrossWorks by board support and CPU support packages which so customers can program those boards without needing to construct header files, write and then debug flash loaders, type in boring memory maps, and so on.  Now, writing demonstration code for all these to have them do something more than flash a LED or respond to a button is a big challenge.

To reduce things to a manageable level, I looked around for something that I could develop for that would enable me to take a LEGO-style brick approach to constructing interesting, useful software.  After a while, it was evident that the Arduino footprint was very popular, had an ever-expanding range of third-party shields.  And, with that popularity, other CPU architectures were leveraging the Arduino form factor.  So, I decided to construct software that would target an Arduino footprint, but on non-AVR architectures.

So, let's take a quick tour of the available Arduino-format boards that I have acquired and am developing for:

• SolderCore, of course.  Stellaris.
• Freedom Board.  Kinetis.
• BugBlat Cortino.  STM32F1.
• Olimexino-5510.  MSP430F5510.
• Olimex STM32-E407.  STM32F4.
• Maple.  STM32F1.
• Netduino.  SAM7X.
• Netduino Plus 2.  STM32F4.
• freeSOC.  PSoC5.
• Olimexino-328P. Yes, a clone, but pretty nice anyway.
• mbed, using a TestBed board.  LPC1000.
• Arduino Due.

There are, of course, other Arduino-format boards, such as the chipKIT, but I am not directly developing the CrossWorks Platform API for these because CrossWorks doesn't support them!

These is one other board that is having the Platform API ported to it, but we'll park that on one side for the moment.

As of today, I have a whole set of software that I can compile for SolderCore, the Freedom Board, the Olimexino-5510, and the Arduino Uno.  No source changes.  The sensor libraries work on each of these different architectures because the Platform API takes care of dealing with the tedious nature of getting hardware set up for GPIO, I2C, SPI, PWM, and ADC functions.  On top of those libraries, I've written mid-level libraries for driving LCDs and getting graphics onto them, supporting mass storage with FAT file stores, and using TCP/IP over Ethernet.  And sitting on top of that is a bunch of demonstrations that will exercise sensors and do interesting things using them.

So, the question is, I guess, when to release all this?  Well, it takes a lot of testing, but then CoreBASIC and SolderCore is built upon the CrossWorks Platform API.  I think that I will release them when CrossWorks 3 debuts, as I use some of the CrossWorks 3 library features to have the software work nicely.

What I can say is that it's pretty cool writing an application that uses the Platform API and then seeing that application run on completely different hardware "just like that."  Sort of the way reusable software is meant to be.

What are the downsides?  Well, of course, writing generic software means that many device-specific features simply get washed away and are just not supported by the Platform API.  That's intentional: if you need those features, write a device-dependent module for it!

The other downside is that you're a bit further away from the hardware and performance may suffer because of the calling overhead.  Well, that's tough, what you pay to get a clean API is a small performance penalty.  It's worth it.