mmmmm...mbed on OpenSolaris

mbed A while back, Bob from hacman mentioned that there was a competition running for the mbed microcontroller, and that to encourage people to enter the organisers were giving away mbeds for free, so I filled in the web application form and promptly forgot about it. Yesterday I got an email telling me I'd been allocated an mbed and that ot could take up to three weeks to arrive, so I was a little surprised to find it pop through the letterbox this morning.

The mbed NXP LPC1768 is quite a beastie:

  • ARM Cortex-M3 Core running at 96MHz
  • 512KB FLASH, 64KB RAM
  • Analogue, digital and PMW I/O.
  • On-board Ethernet
  • On-board USB
  • CAN bus (vehicle data bus)
  • SPI bus
  • I2C bus
  • On-board filesystem

The development environment is fairly novel as well, they've opted for what you might call a 'Cloud' solution. You plug the board in to a USB port and it appears as a USB disk drive. The compiler is hosted at mbed.org where there's web-based IDE. You develop your code using that, and when you hit 'compile', you get a downloadable binary image that you save onto mbed's USB drive, then hit the 'reset' button on the board and it runs your code. For debugging, the board also appears as a serial device, so you can read/write from/to the device using that.

I had no idea if it would work on Solaris but it works just fine on build 150 - I plugged it in and it appeared as a USB disk and Gnome filemanager duly popped up so I could copy images onto it. I loaded up one of the serial demo programs and tip -b 9600 /dev/term/0 connected to the board and allowed me to interact with it as expected.

I'm not entirely sure about the online IDE - sure, it's quick and easy to get started, but a bit like the Arduino IDE, I suspect you'd grow out of it pretty quickly, plus having to be online just to compile code is a bit limiting on a planet that's still not got 100% network coverage. There's some information out there on how to set about doing things yourself, but it looks like it would be a bit of a faff to get set up - you need Code Sourcery's ARM EABI toolchain, which of course isn't available in binary form for Solaris, plus there's a whole heap of other messing about that's necessary. In fact, as far as mbed goes I'd pretty much echo these sentiments.

So, I'm not sure quite what I'll be using my mbed for - the Ethernet support seems interesting, as does the USB support, but at £50 each I don't think I'll be rushing out and buying a load soon, when the AVR is so much cheaper and perfectly adequate for most hack projects. I think the mbed will probably end up being a gateway between the physical and virtual worlds, for example as a bridge between the internet and a collection of wirelessly-connected Arduinos.

Categories : Solaris, Tech

Waiting for O(1)

Due to a misconfiguration the notification emails from my blog weren't reaching me, so I missed a couple of interesting comments on my earlier HL1606-related posts. The ones from Dan from over at Waiting for O(1) were particularly interesting, and he's written a SPI library for driving the HL1606 as well as other similar LED drivers such as the LPD6803 and WSC2801 - if you are looking for alternatives to the HL1606 he has some links on the googlecode page for his project. Dan is actually doing PMW fading of the strips, so he's driving them via timer-generated hardware interrupts. Dan has a lot of useful tips and observations about speed and power limitations he's run into and how he's solved them that are well worth checking out, check out his blog.

Categories : Tech, AVR

Facebook lives up to my worst expectations

In January 2008 I made this prediction:

it would be far more effective to use a Facebook application to harvest personal information whilst apparently offering a useful service, and then use the data elsewhere and/or at some time after the application harvested it.

And sure enough, Facebook application providers such as FarmVille and FrontierVille have been hoovering up user data via the Facebook API and selling it to 3rd party advertisers. This has been all over the web today, and is just the latest in a long line of Facebook security cockups. Of course, it's been known about for ages as well, as I pointed out in this February 2008 post:

Researchers from the University of Virginia recently announced that in a study of the top 150 Facebook applications, more than 90% were given access to information that was not needed to function correctly. That Scrabble or Superpoke application you really like? Its developers get access to your religion, sexuality and home town.
-- slashdot.org

Because the WSJ has run the story today, the webosphere is all a-flutter with the 'news':

The apps reviewed by the Journal were sending Facebook ID numbers to at least 25 advertising and data firms, several of which build profiles of Internet users by tracking their online activities.
-- WSJ

There are currently more than 550,000 Facebook apps, they haven't been audited by Facebook, and they don't run on Facebook's servers. As an application developer, you are responsible for hosting your application, not Facebook, so you have complete control to the data Facebook feeds to your application. As a developer, to get access to all this juicy data all you need to do is click on an "I agree to behave" agreement on Facebook's developer site. There is absolutely no technical means Facebook can determine what the apps are doing with user's data after the have transmitted it to the application.

Next time someone sends you an application invite, rather than blindly clicking 'Accept' ask yourself why it needs the information it is asking for access, and if you don't think it's reasonable, reject the invitation. Personally I won't use any Facebook apps at all, because I barely trust Facebook, let alone some unknown and unaccountable external company who I have absolutely no recourse against.

I think part of the reason that Facebook has become popular, apart from the 'social networking' aspects is because people believe it's somehow 'safer' than the rest of the internet because you have to log in, and there's a veneer of apparent control over your data. However, that's a dangerous assumption. You are not significantly safer on Facebook than you are on any random internet site, and in practice probably less so as Facebook is set up to encourage you to disclose information that you probably wouldn't disclose on an 'open' website.

As Scott McNealy said 11 years ago:

You have zero privacy anyway. Get over it.
Categories : Tech