One of the development boards I've been using recently is the LPC1830-Xplorer from NXP Semiconductors.  It is built around the LPC18xx series of Cortex M3+ based microcontrollers.  What makes this particularly interesting is that the LPC18xx series (and its M4 based LPC43xx siblings) have a high-speed USB 2.0 PHY built into the chip (along with a second USB controller).  The PHY is the physical driver for the USB port.  This eliminates an extra chip (along with about 10-15 wires) and a lot of complexity.  

Although many chips have full-speed USB 2.0 PHYs (capable of 12Mbps, 1.5MB)  built in (e.g. the KL25), I haven't seen another yet that has a high speed (480Mbps, or about 60MB per second).  The higher capacity is particularly important for some of the applications I am considering, which use large amounts of SD memory.  It also has a full SDIO controller so it will be able to communicate with SD cards at full bandwidth, and I hopefully should avoid many of the problems I ran into using the SPI bus.


The LPC1830 comes with a full development kit and IDE called LPC-Xpresso.  Here are some of my notes on getting the kit up and running, and on my first test application - combining the USB functionality with the SD card to make a basic USB-SD card reader.

I've begun working with a great product - the Spark Core from Spark.io, which is a development board/module that integrates the TI CC3000 wifi module and an STM32F103 controller.  Spark.io provides a complete open source firmware to drive the system.  

They are continuing to bring out new versions of their product - like the Photon (due in March) which uses a Broadcom chipset which can serve as a software access point - important if you want to serve applications from your module without it being connected to a local wifi network and Internet.  By developing against the Spark Core I should be able to transfer to this more advanced hardware as it comes available.

Their system is great for getting started with wireless modular computing.  The Spark Core comes preloaded with firmware that allows it to receive downloads wirelessly, and they provide a complete Web IDE for programming.  

The problem I need to solve is that I want faster download and debugging.  The current download/reset cycle via WiFi is fairly slow; there is no debugger.  There is a tutorial in Spark.io support for setting up a local development and debugging system on Windows.  But I am on a Mac.  How do I get my toolchain to work with the Spark Core?

I've recently gotten the Segger J-Link GDB server and was trying to get it to connect to my hardware.  The reason I want to try to GDB server is that I want an OSX-native GDB interface (up to now I have been using the P&E GDB Server for Kinetis, which only runs on Windows), I want to be able to connect to targets besides the Kinetis targets (STMF32 and LPC) and I wanted a backup interface.  Also I was getting frustrated with the P&E device as it seemed not very well supported and somewhat flaky (for a while it was crashing during routine debugging, forcing me to completely reset hardware and software).

The EcoReco M5 is a 'last mile' electric scooter.  It weighs ~36lbs and costs $1200.  Where does the weight and cost come from?

I'm currently working on a project where I am streaming data to an SD card.  The problem I am having is that it it pauses periodically while writing.  Grr...

One of the things I've been doing lately is been writing device drivers from bare metal, that is, without the help of Processor Expert or other libraries.  This is flipping bits in registers, using bits of assembly language, etc.  When I mentioned this to a friend of mine, he looked at me like I was insane.  Why would I waste that time?  The whole point of libraries and these tools is to abstract it away so you don't get lost in the weeds.

To be honest, I'm not totally sure if this is a good use of my time.  Part of me agrees with my friend.  It's a lot of horrible debugging - digging through documentation, trying a setting at a time and staring at uncooperative traces.  It takes forever.  It's work someone else has done.  I have plenty of things to do besides staring at a register map and doing binary-hex conversions in my head.

There are a couple of things I think I understand better now, though.  First, I am getting a deeper sense of what peripherals can do and what they can't do.  This is not always clear in the documentation (at least not for the Freescale devices I'm using).  

Second, I'm starting to see regularly the things that slow down debugging at this level.  I'm getting a little better at it.  And I'm starting to believe there are a few tools that would speed things up a lot. 

The reason I care is that I've noticed that probably 90% of my development time is wasted on 10% of bugs - which tend to be bare-metal bugs, or at least clearly visible in bare metal.  In these cases, you end up needing bare metal visibility - views of the registers and memory - to see where your code is not behaving as it should.  Having this visibility - just like being able to see what the variables in your code are doing - would speed this up incredibly.

So let's take a short walk through the SPI driver and its quirks...

Some notes on setting up external build settings in XCode 6.1.1:

I set up an XCode project to use external build settings.  I added all of my files to the project, then hit 'build'.  But it stalled, and complained: 

make: arm-none-eabi-gcc: No such file or directory

My build chain is using the standard /usr/bin/make, which invokes arm-none-eabi-gcc, the microcontroller compiler.

XCode was complaining that it could not find arm-none-eabi-gcc.  


I played around with all of the typical places where the path to that executable is found - .profile, .bashrc, .bash_profile, but nothing seemed to work.

After some searching, it turns out that the fix is simple.

I am staring at the board, the schematic, and my code.  I press the button.  A squeal comes from the left channel, only.  Urgh.  I am in the land of debugging I2S protocol.  Here are some notes:

In the last generation of the Tabata Timer I added an audio pass-through circuit so that someone could plug it into their existing stereo system and have the timer signals mixed into their music, and digital volume control using a MCP4013 digital potentiometer.   

I made some mistakes . My active ground mixer circuit is single ended so it clips the negative side of the input signal, resulting in horrible distortion.  Because I tried to split the timer mono output into two channels without using buffers, I'm getting leakage across channels.  My headphone detection circuit triggered the NMI interrupt.  But the digital pot works like a charm.  

These problems are fixable.  But I still worry about power, cost and performance.  The low power op-amps I'm using in my mixer circuit are expensive (averaging near $4.00) and I'll need more of them to solve the leakage problem.  I'm also not sure how they will do driving headphones - typical practice is to use big capacitors for headphone outputs and a proper headphone amplifier, and I don't know how my circuit will perform there.  The discrete components also take up a lot of board real estate and also begin to add to the cost (e.g. the digital potentiometer is ~$0.40).  

I get the sense this problem has been solved before....like, in every cellphone and MP3 player out there...and so I look online and find the world of inexpensive audio codec/mixer chips.