feilipu's posterous

Melding freeRTOS with ChaN's FatF & HD44780 LCD on Freetronics EtherMega

This post is a bit of a mixed bag, describing some software and hardware integration, together with some raving about a great tool I've been using. So, let's get started.

Platform

Some time ago I got a Freetronics EtherMega, which is essentially an Arduino Mega2560 with an integrated Wiznet W5100 Ethernet interface, and a MicroSD card cage. I've introduced this product and the use of freeRTOS here.

EtherMega (Arduino Mega 2560) and freeRTOS

One great thing about the ATmega2560 used in the EtherMega, and the Arduino Mega2560, is the availability of an external memory bus. I've been using a Rugged Circuits QuadRAM, and now have ordered three more of their MegaRAM devices, and intend to make the ATmega2560 my standard platform. Why three? Well everyone knows that good things come in threes.

QuadRAM (512kByte) on Freetronics EtherMega (Arduino) ATmega2560 with freeRTOS

I'm actually preferring the Rugged Circuits MegaRAM which has only 128kBytes of RAM, so it won't be as flexible for bank switching as its big brother. Also its chip select line is reversed (note to self to fix this in the driver). But, simply having 64kBytes of normal extended RAM plus another 56kBytes of special purpose (bank switched) RAM seems like it wil be sufficient for the duration. I've bought a couple to go on some Android ADK devices, that I'll write about soon.

Recently, I also acquired a Freetronics 16x2 LCD-keypad-shield to use as a drop-on display for debugging and status, and anything really. It works really nicely and with its single pin switch analogue interface (which will be useful for navigation). Unfortunately there is a conflict between the SD Card device select pin on the EtherMega (Arduino pin D4) and one of the data pins on the 16x2 LCD.

My rectification of this pin usage conflict can be seen on the pictures below, where the yellow wire joins Pin D4 to Pin D2. What can't be seen is that the leg of Pin D4 has been cut off, so it doesn't insert into the EtherMega, so there is no elecrical connection between the D4 pin on the 16x2 LCD, and the D4 Pin used on the EtherMega.

(download)

Click here to download:

melding-freertos-with-chan-s-fatf-hd44780-lcd-on-freetronics-ethermega-loyflvIDdJjeclxbclae.zip (12.55 MB)

Tools

Recently I purchased a Saleae Logic to use in developing. I have got to say that this is probably the best $149 that I have spent on any tool, ever. Having the ability to capture long periods (minutes) of data, with 24MHz resolution, and zoom, shrink, drag, flick around in it, and also compare many windows of alternative samples is just so great. It saves so much time being able to simply "see" what the device is actually doing on the SPI, I2C and serial ports, simultaneously, is well great. But I already said that.

Software - FatF File System

As usual, the code is on AVRfreeRTOS on Sourceforge.

My main work was to put the existing ChaN's FatFs Generic FAT File System Module v0.9 into my existing ATmega2560 freeRTOS system, using my existing libraries, and generally being fully integrated into the system, as a plaform for some further work.

This was fairly time consuming (until I got my Saleae Logic), because the SPI bus transfers required to initiate and drive a SD card are complex, and depend on which version of SD card (MMC, SD, HDSD) is being used.

Now that everything is working, I've also done some SPI optimisation, to speed up multi-byte SPI bus transfers used for reading and writing to the SD card.

In testing with a Freetronics EtherMega driving an 4GByte HDSD card the system achieved the following results.

• Byte transfer cycle time: MOSI 3.750us, MISO 3.6250us
• Multibyte transfer cycle time: MOSI 1.3333us, MISO 1.3750us
• Gross Performance increase: MOSI 2.8x, MISO 2.64x

Measured performance for a multi-MegaByte file copy is about 140kBytes/s which includes both read and write operations to the same SD card.

Software - HD44780 LCD

As usual, the code is on AVRfreeRTOS on Sourceforge.

This was pretty straightforward, once I'd recognised the pin confict issue between the two Freetronics devices, and perhaps the most interesting things to say are:

• Using a macro to control the pin assignment means that it is very easy to change the pins used for any display type. Simply renumber them in the macro and it is done.
• Also, using the standard avr-libc stdio utility vsprintf formatting allows me to choose how much library I want to bring in. The standard library doesn't support float formatting, but with a simple link switch either a simpler (smaller) or more fully featured (larger) standard library can be included. I also use the standard avr-libc tools for the serial port, so there is no additional overhead specifically for the LCD.

To Do - Wiznet W5100

Now I've finished the W5100 drivers from Wiznet, incorporating their new v1.6 changes (because they screwed up the silicon ARP state machine). And also, a fix for a subtle bug caused by writing to the W5100 Tx buffer before it was finished with a previous transmission. This was fixed by checking the Tx read pointer and comparing it with the Tx write pointer. When the chip is idle, they are the same. That took me 3 weeks to isolate.

Now the fun part starts, which will be to re-learn the IP protocol suites, through re-implementing some of the standard network tools, like HTTP, FTP, NTP, DHCP, DNS, that we just take for granted. DHCP is done.

QuadRAM (512kByte) on Freetronics EtherMega (Arduino) ATmega2560 with freeRTOS

I've been spending some time integrating the Rugged Circuits QuadRAM extension for the Arduino Mega (or Freetronics EtherMega) into the freeRTOS environment. And, it is now my standard environment. Actually, the MegaRAM, a slightly cheaper 128kByte version is my standard, as I've not found an application yet that needs more than 64kBytes total RAM. But, that will happen.

Without adding any complexity into the environment, I can address up to 56kBytes of heap variables, effectively leaving the entire 8kbyte of internal RAM for the stack. With no complexity or overhead.

In addition, with some simple commands within a task can implement bank switching to access up to 7 additional banks of RAM, each up to 56kBytes.

A further degree of integration into freeRTOS is to completely automate memory bank switching, to give each of either 7 or 15 tasks a bank of RAM for its exclusive use. But this is a goal for the next few months.

Here are some pictures.

(download)

Click here to download:

quadram-512kbyte-on-ethermega-arduino-atmega2560-with-freertos-AlmaEyflrajmgkutqjvH.zip (8.84 MB)

And here are the links to the products described.

Rugged Circuits QuadRAM

Freetronics EtherMega

I'm very happy with my Saleae Logic too. Must write a review on this, one day. Great tool, more useful every day.

The described code is all available on Sourceforge, if you're intending to try this at home.

The only finished example using the memory routines is the MegaSD project. Take a look at it on Sourceforge to see how to use the extra RAM.

HOW TO

What do we have to do to get this build working? Well it is pretty simple really, once everything is figured out. It is really only three steps.

1. Initialise the RAM, and tell the AVR that it should enable its extended RAM bus.
2. Tell the compiler that you're moving the heap into the new extended RAM address space.
3. Tell freeRTOS to move its heap to the new extended RAM address space.

Initialise the RAM

The RAM should be initialised prior to building the standard C environment that comes along for the ride. It can be done in the .init1 (using assembler) or in .init3 in C. I built both methods, but elected to just use the C method, as it is more maintainable (legible).

There are a number of references for this code. Some of the older ones refer incorrectly to a MCUCR register. That is not correct for the ATmega2560.

This example covers what Rugged Circuits suggest for their testing of the QuadRAM, but it doesn't put the initialisation into .init3, which is needed to make the initialisation before heap is assigned. It makes the initialisation carefree.

// put this C code into .init3 (assembler could go into .init1)

void extRAMinit (void) __attribute__ ((used, naked, section (".init3")));

void extRAMinit (void)

{

// Bits PL7, PL6, PL5 select the bank

// We're assuming with this initialisation we want to have 8 banks of 56kByte (+ 8kByte inbuilt unbanked)

DDRL  |= 0xE0;

PORTL &= ~0xE0;  // Select bank 0

// PD7 is RAM chip enable, active low. Enable it now.

DDRD |= _BV(PD7);

PORTD &= ~_BV(PD7);

// Enable XMEM interface

XMCRA = _BV(SRE); // Set the SRE bit, to enable the interface

XMCRB = 0x00; 

To ensure that this .init3 function, that I've put into lib_ext_ram, is included in your linked code, we need to call something from the lib_ext_ram library. If you're planning to use the banks of RAM, then this is easy as you'll naturally be calling the bank switching functions.

However, if you only want to use the extra 56kByte of RAM for simplicity (it is after all 7x more than you have available with just the internal RAM), then just call this function once from somewhere, possibly main(). I have added it to the freeRTOS stack initialisation function in port.c, so I don't need to see it ever again.

extRAMcheck();

It returns the XMCRA value, that can be tested if you desire. But there's no need as things will anyway have gone badly pear shaped if the RAM is not properly enabled. Calling this once is all that is needed to ensure that the .init3 code is properly inserted into the linked code.

Note: that the above code is specific to the QuadRAM device. The MegaRAM device has different IO in use, and the differences are noted in my code on Sourceforge.

Move the heap

The standard C heap has to be moved to the new location above the stack. There are other memory allocation options, but in my opinion this is the most sensible one and the only one I'm planning to implement.

The __heap_start and __heap_end symbols describe the addresses occupied by the extended RAM, and inform malloc() of the location of the heap. This is described in more detail here http://www.nongnu.org/avr-libc/user-manual/malloc.html. This is a great diagram showing the situation.

avr-gcc -Wl,-Map,MegaSDTest.map -Wl,--gc-sections -Wl,--section-start=.ext_ram_heap=0x802200  -Wl,--defsym=__heap_start=0x802200,--defsym=__heap_end=0x80ffff -mmcu=atmega2560 -o "MegaSDTest.elf" $(OBJS) $(USER_OBJS) $(LIBS)

Tell freeRTOS

Now freeRTOS has to be made aware of these changes to the heap location. There are three heap management options available for the AVR port. The two most memory economical (lol in this case) options use a fixed array of memory defined in the .data section on initialisation. Clearly, this is not going to be useful. For the third option heap_3.c, which uses malloc(), we have nothing more to do.

However, getting heap_1.c and/or heap_2.c to work is not that complicated either. There are three parts to this. Firstly, creating a new section name, and locating it at the start of the desired heap space. We've already done that, above, with the --section-start command.

Secondly, we have to make a small modification to both heap_1.c and heap_2.c to inform the compiler that the freeRTOS heap will be located at this .ext_ram_heap location. That is done in this manner (heap_2.c shown).

static union xRTOS_HEAP

{ ... edited ...

unsigned char ucHeap[ configTOTAL_HEAP_SIZE ];

#if defined(portEXT_RAM)

} xHeap  __attribute__((section(".ext_ram_heap"))); // Added this section to get heap to go to the ext memory.

#else

} xHeap;

#endif

And finally, now we've (probably, just because we can) allocated a large (up to 32kByte) freeRTOS heap, we need to ensure that the loader omits this section from its preparations for writing the .hex file to flash (in a similar manner to the way the .eeprom section is removed).

avr-objcopy --remove-section=.eeprom --remove-section=.ext_ram_heap -O ihex MegaSDTest.elf  "MegaSDTest.hex"

Something to watch for is that none of your other code is calling malloc(), because if it does its memory allocations will collide with the freeRTOS heap. Either check that malloc() is not being linked in or, for the paranoid, just asign the heap_1.c or heap_2.c heap to a region separate to your new malloc() heap addresses.

And that's all there is to getting an easy 512kByte of fast no-wait-state RAM on your Freetronics EtherMega or Arduino Mega2560. Enjoy!

EtherMega (Arduino Mega 2560) and freeRTOS

This is an unboxing and porting review of the Freetronics EtherMega.

It is an Arduino Mega 2560 compatible product, with the added goodness of a Wiznet W5100 Ethernet module and a MicroSD card cage on board.

http://www.freetronics.com/products/ethermega-arduino-mega-2560-compatible-with-onboard-ethernet

Obviously, my first job is to port the freeRTOS code to run on the EtherMega ATmega2560 microcontroller. There are some things about the ATmega2560 that are different from other ATmega devices, making it necessary to modify the standard freeRTOS code for it to work correctly. But the main difference is that because of the size of its flash memory, it has a 3 byte program counter (rather than 2 byte in every other ATmega device).

There are only a few references to making the ATmega2560 work. This reference is the most compelling guide.

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=70387

Stu_San has proposed a port, and I have used it as an accurate guide to getting things running. There are some changes. freeRTOS has changed significantly with regard to how the port.c file is built. Also, I've already implemented options for Timer selection. So the resultant code on the Sourceforge AVRfreeRTOS Project is slightly different to what Stu_San proposed.

https://sourceforge.net/projects/avrfreertos/

The avr-linker script needs to have a small addition to support Stu_San's suggestions. For the purposes of simplicity (only change a little as possible, to get things working), I've only included the .task tag into the avr6.x file, that will replace the normal avr-binutils file in /usr/lib/ldscripts

At this stage the EtherMega is nicely flashing its LED at me, which means that the scheduler and IO addressing using my digitalAnalogue tools are working correctly. But, I'm sure there are many things still to improve over the coming days and weeks.

Update - 25 January 2012

Corrected an error calculating the serial port baud rate. The (all) AVR data sheet has an error in it, that only exhibits at certain CPU frequencies. Unfortunately, I've normally only used Arduino and Freetronics kit over-clocked to 22.1184MHz, which provides perfect baud rates with no error. This CPU frequency does not exercise the faulty data sheet calculation, to generate errors.

WormFood's AVR Baud Rate Calculator

The standard Arduino CPU frequency of 16MHz causes the serial port to run too slow by 3.7% at 115200 baud (well outside the recommended range of 2%), and more importantly the data sheet calculation chooses the wrong set up value for the UBRR value driving the baud clock, causing the serial port to become unworkable. The calculation method has been improved in the AVR <util/setbaud.h> file, and that calculation method is now used in my serial library. New code uploaded.

Update - 8 March 2012

Completed the ChaN FatF library port to freeRTOS for driving the microSD card. Supports both SD and HCSD. Code in usual place.

Update - 5 April 2012

Completed the Ethernet library port to freeRTOS for driving the Wiznet W5100. Supports TCP, UDP and Raw IP modes. Code in usual place.

The standard Arduino Mega stk500v2 bootloader used by default in the Freetronics EtherMega does not work when loading more than 64kB into flash. I've found a modified version by msproul that works, or at least does now that I've changed it a little more, to be found here.

Nintendo 3DS System Transfer - workflow fail - what were they thinking?

Review of (Amazon) Panasonic Lumix G X Vario PZ 14-42mm/F3.5-5.6 Lens

Thanks for submitting a customer review on Amazon. Your review could not be posted to the website in its current form. While we appreciate your time and comments, reviews must adhere to the following guidelines: http://www.amazon.com/review-guidelines We encourage you to revise your review and submit it again. A few common issues to keep in mind:

Panasonic Lumix G X Vario PZ 14-... ~Panasonic

Written reviews must be at least 20 words long. The ideal length is 75 to 500 words. Your review should focus on specific features of the product and your experience with it. Feedback on the seller or your shipment experience should be provided at www.amazon.com/feedback. We do not allow profane or obscene content. This applies to adult products too. Advertisements, promotional material or repeated posts that make the same point excessively are considered spam. Please do not include URLs external to Amazon or personally identifiable content in your review. We welcome your honest opinion about products - positive or negative. We do not remove reviews because they are critical. We believe all helpful information can inform our customers buying decisions. If you have questions about the product or opinions that do not fit the review format, please feel free to use the Customer Discussions feature on the product page.

AVR Pong - Peggy2 & Danger Shield

This post should really be titled "AVR Pong, and some other non-firsts".

Anyway, to make a point out of this, I decided to make a Pong game, using the Peggy2 and a Danger Shield courtesy of Little Bird Electronics

So why is this interesting? Well there are somes significant firsts in there for me.

1. Not just multi tasking (using freeRTOS), but real multi-processing using 2 AVR devices. The two AVRs communicate using the I2C bus.
2. Developing an I2C code base that can simultaneously be Master and Slave, and is interrupt driven. I hope that the code can do MultiMaster too, but I haven't fully tested it.
3. Building a robust efficient video transfer protocol between the game mechanics AVR and the video (Peggy2) AVR. Using prioritised row updating and a CRC8, which I think it is pretty robust.
4. Building a buzzer routine that can play melodies, with real notes, again fully interrupt driven, using Timer 2 (the Danger Shield buzzer is connected to PD3).

None of these things are original. In fact most of the code is borrowed from elsewhere, and the sources can be found in the files. But, I'm pretty stoked to have made it all work together, under freeRTOS. Small things, as they say, amuse small minds.

Code at AVRfreeRTOS at Sourceforge.

Updates with more detail when it is not so late.

Our NBN; make it better, please.

I've written my personal thoughts on the difficulties in creating a successful outcome for the NBN in Australia previously here. Our NBN Co is Engineering Fail

And today I made some comments on the "jumping the shark" article on ZDNet, which got me soundly voted off this small Island. Jumping the shark.

But, before I pack my bags and depart, I thought that I should leave some positive words on what the NBN Co could do better, and remove my humble objections to the path they've taken.

1. Commit to a public "rising tide" deployment strategy. 

The principal of providing broadband access to all of Australia is commendable, and should be pursued. But, the current deployment strategy is opaque and leaves us open to believe that it can be gamed for political grounds.

Secondly, it is clear that as a result of the existing deployment strategy, existing functional high performance broadband networks are destined to be switched off earlier than necessary.

The deployment strategy should pursue the path of providing broadband to those with no broadband first, before any customer with an existing DSL service is overbuilt. Once this is achieved, then those with a ADSL 1 or other slow or older broadband technology should be over built.

Radio and satellite deployment schedules should clearly be continued.

Obviously this strategy would reach those with ADSL2+ next to last, and those with HFC network access last of all. This is a good thing, as it would focus the initial effort and money on the areas where no network service currently exists.

This deployment strategy would allow the average national broadband speed to float quickly upwards on a "rising tide" of performance, as the lowest performance outliers are removed.

2. Devolve all vendor contracts into contestable segments of no greater than $100 million. 

There is no technology that can't be devolved into contestable packages of around $100 million or less. The idea that the NBN Co can sign off exclusive contracts for $1+ billion dollars, without any competitive options, and without sufficient in-house resource for intense contractual performance scrutiny, is just lunacy.

Experience shows that smaller contracts ensure that deliverables can be more closely aligned with outcomes, and are much less likely to have significant cost over runs. Agile delivery of outcomes is required here.

3. Establish competitive tension in procurement.

The NBN Co should ensure that each and every technology package is procurable from at least 2 geographically diverse technology vendors, with demonstrably different supply chain mechanics. It takes just one geo-tectonic event (Icelandic dust clouds, or tsunami for example) to lay waste to an entire geography for months. Disruptions to a single vendor’s supply chain should not have a downstream effect on every supplier to the NBN and the resulting build schedule.

Vendors also sometimes take mis-steps in their development processes, leading to obsolete equipment being placed into the field. Over a 10 year build process, it is relatively difficult to keep watch that procured equipment remains fresh, when no competitive tension is in play.

NBN Co should ensure that two "equal" vendors are selected for each and every contestable product and service segment, and that no favoured vendor is driving the NBN Co architectural outcomes.

4. Recognise NBN Co is a utility and national standards provider and rewrite their business plan based thereon.

The political expediency to have a "positive" business case has shackled the NBN Co to an unrealistic build schedule, and elevated long term wholesale costs to Retail Service Providers.

The NBN Co should be recognised as a utility, and our wholesale network provider of last resort, to provide a broadband service where no commercial service provider is prepared to invest for a commercial return. And in return, the NBN Co should be freed from the need to cross subsidise from low cost urban deployments to higher cost deployment regions.

NBN Co should be financed from general revenue, in the same way that other major infrastructure projects are financed.

NBN Co should tender for operating companies to build and operate geographic sectors of the Australian continent's fixed wholesale network infrastructure (based on the "rising tide" principal above) to the standards set by NBN Co, to secure the maximum involvement from private enterprise.

freeRTOS and libraries for AVR ATMEGA with Eclipse IDE

I've created a Sourceforge project as a place to host all my current tools and working environment.

Sourceforge freeRTOS & libraries for AVR ATMEGA

That's the thing about open source. Sometime you have to give back.

Things I'm really happy about:

• Freetronics EtherMega (Arduino Mega2560) ATmega2560 scheduling and IO works.
• Being able to use any Timer on the AVR as the system Tick. In practice this means Timer0 on 328p (Arduino) and Timer3 on 1284p (Pololu SVP) and 2560 (Arduino).
• Converting all of the relevant libraries to be friendly to a RTOS system. No nasty delay wait loops etc. Everything defers to (is interruptible by) the scheduler when waiting, or is driven from interrupts.
• Having several finished projects, that are good demonstrations of lots of AVR and freeRTOS capabilities.
• Having the Sparkfun LCD Shield working properly, with printf string formatting.
• Having the Rugged Circuits QuadRAM and MegaRAM working on ATmega2560.
• Porting ChaN FatF microSD card support for Freetronics EtherMega.
• Porting Wiznet W5100 Ethernet drivers for Freetronics EtherMega.
• Properly implementing semaphores for access to resources (ports, interfaces, ADC, LCD).
• Properly implementing queues for transferring data between tasks (threads).

The repository of files is a working collection for a freeRTOS based platform using the AVR-GCC and AVRDUDE platform. The development environment used was Eclipse IDE. With some luck the included file structures will simply import into Eclipse.

With Eclipse the AVR plug-in is needed. It is assumed that the AVR libraries are installed. For the retrograde project, it is assumed that Pololu libraries are installed. I've added an old (now unmaintained) make file in case the compile and link parameters for Eclipse are not readily available.

The freeRTOS folder contains the most recent version 7.1.0 of freeRTOS, but it has been abridged down to only those files relevant for AVR GCC. The port.c file has been extensively modified to allow the use of either of the 328p Timer0 or Timer1 timers. And, the use of Timer3 on the Pololu SVP which has uses a 1284p. Timer 3 for EtherMega (Arduino Mega 2560) also works.

If you want to use 16bit PWM on Arduino 328p platform, then you'll need to enable the Timer0 system Tick. The freeRTOSConfig.h file contains most of the variables that you'll need to change.

There are some relevant and often used libraries added to the basic freeRTOS capabilities.

• lib_digitalAnalog: contains often used I/O routines borrowed from Pololu.
• lib_i2c: contains the tools to use the TWI or I2C bus. contains integrated master and slave routines. Multi-master arbitration / back-off has not been tested.
• lib_spi: contains the tools to use the SPI bus.
• lib_servo: contains routines to enable accurate PWM using the 16 bit Timer1, used in the retrograde clock example.
• lib_serial: contains routines to drive the serial interface. there are two versions; avrSerial for use before the freeRTOS scheduler has been enabled, and xSerial for normal operations. xSerial is interupt driven.
• lib_ext_ram: contains routines to drive the Rugged Circuits QuadRam on Arduino Mega2560, or Freetronics EtherMega.
• lib_crc: simple 8 bit CRC calculation.
• lib_rtc: drivers for the DS1307 RTC using I2C.
• lib_fatf: contains ChaN's FatF libraries for driving the microSD card on the Freetronics EtherMega.
• lib_W5100: contains the W5100 drivers from Wiznet v1.6. Even fixed a subtle bug caused by not waiting for Tx to complete before additional packets are written to Tx buffer.
• lib_inet: contains a DHCP implementation. This will grow.

Some more recent posts are here:

Melding freeRTOS with ChaN's FatF & HD44780 LCD on Freetronics EtherMega

Rugged Circuits QuadRAM on Freetronics EtherMega

Quick review of Freetronics EtherMega

Description of the AVR Pong multi-processor game.

Step-by-step Instructions

Our Destination:

On completing these instructions you should have an Eclipse IDE (Integrated Development Environment) installed with all relevant libraries installed, to use the freeRTOS, and the libraries I've modified, to build projects (Eclipse term for a set of code) of your own.

We're Assuming:

These instructions are based on a Ubuntu 11.10 install, but the path to the destination is not complex, and can be roughly followed for any installation platform.

Step 0. As usual on an Ubuntu (Debian) system, refresh the software sources.

sudo apt-get update

Step 1a. Install the AVR Libraries.

Step 1b. Install the Arduino environment.

Doesn't hurt to have the Arduino environment available. It can be used for programming bootloaders (using AVR-ISP code), and generally for checking health of equipment, using known good example code.

This will pull in some extra libraries that the Arduino platform needs.

Step 2a. Obtain the Pololu Libraries (optional).

The Pololu Libraries are used for the multi-line LCD tools (such as in the retrograde clock) together with their quite powerful and efficient methods of doing many things. Where I'm using a Pololu controller such as an Orangutan SVP it makes sense to use their libraries too.

Rather than incorporating all their libraries in all my projects, I integrated the analogue and digital line control libraries (the functions I used most) into another smaller library of my own, so I tend not to use their libraries because it makes for one additional dependency.

Never-the-less, we will install the Pololu libraries, as they are needed for the retrograde clock project. If you don't want to use their libraries, just skip this Step 2.

Download the Pololu libraries from here, to a suitable place.

http://www.pololu.com/docs/0J20/2

Unpack the entire archive and open a command prompt within the libpololu-avr directory.  If avr-gcc is correctly installed on your system (Step 1a), you will be able to type "make" to compile the entire library. Pay attention to any errors that occur during the build process.

Step 2b. Change the LCD pin definitions in lib-pololu to allow access to both 16 bit PWM lines on an arduino compatible device.

If there are no compile or linking errors, then you can grab my updated OrangutanLCD.h file from sourceforge, and swap it for the one in the source folder of Pololu, then recompile.

This only needed for retrograde clock project. If it seems too difficult, come back and do it later. The retrograde clock project needs to use 16bit PWM to drive 2 servo motors. One of the needed PWM pins is in conflict with Pololu's standard LCD pin assigment. See the file for the changes.

sudo make clean

 sudo make

Step 2c. Install the Pololu Libraries.

The libraries will be found in the same directory branch as the avr libraries when this step is successful.

Step 3. Fix avrdude chip erase delays.

There is a long standing bug in avrdude configuration files, that prevents proper programming of the 324p, 644, 644p and 1284p devices. These are relevant to Sanguino and Pololu users.

http://savannah.nongnu.org/bugs/?28344

The chip_erase delay for four AVRs in avrdude.conf is too short, so the chip erase command times out and avrdude prints an error message. The error is not fatal; it doesn't prevent the user from programming the chip. This bug should be very easy to fix. 

In avrdude.conf, change the chip_erase_delays to the following values: 

part chip_erase_delay =

ATmega324P: 45000 (us)
ATmega644: 55000
ATmega644P: 55000
ATmega1284P: 55000

Currently they are all 9000, which is too short. So in your favourite editor, open the avrdude.conf file, and make the changes to the chip definitions.

sudo gedit /etc/avrdude.conf

Step 4. Install the Eclipse IDE.

It is not necessary to use or install an IDE to develop with freeRTOS, or with any other system. It is easy to use makefiles and the command line. In fact, I didn't use Eclipse for a long time. And, when I first started to use it, it felt very unnatural and clumsy.

However now I've been using it for some time I highly recommend it, for the ability to see deeper into the code (definitions are detailed on mouse over), and to compare (live differences) and roll-back code to any step of your editing process.

Again, installation is easy with Ubuntu (Debian), but it can take a while. Lots of things get installed along with it.

sudo aptitude install eclipse

Step 5a. Select the C & C++ development tools within Eclipse.

Eclipse is a Java based platform, but it works just as well with C, and C++, as it does with a wide variety of languages. Getting the C Development Tools (CDT) is the first step to a C environment that we'll be using.

Open Eclipse, and lock it to your launcher. You'll be using it frequently.

Using the Menus, click:

Help>>Install New Software...>>Add...

CDT Indigo http://download.eclipse.org/tools/cdt/releases/indigo

Select only "CDT Main Features", and install these plugin development tools.

Step 5b. Select the AVR development environment within Eclipse.

The AVR environment includes direct access to the avrdude downloading tool for one-click programming of your AVR devices.

Using the Menus, click:

Help>>Install New Software...>>Add...

AVR Plugin http://avr-eclipse.sourceforge.net/updatesite/

Select "CDT Optional Features", and install these plugin development tools.

Step 5c. Select C/C++ Perspective

First you need to select the right perspective, being C/C++. Top right there is a button showing "Java". Just to the left is a button (like a window) for selecting perspective. Select

Other...>>C/C++

When that is finished, you should have Eclipse menu button containing a AVR* with a green down arrow. That is the button used to program the arduino or Pololu device.

Step 6. Define a freeRTOS static library project.

There are lots of short cuts, and alternative ways to achieve things using context sensitive menus in Eclipse. I'll concentrate on the top menu bar options, though you can get most things from a context menu click in the right window.

File>>New>>C Project: AVR Cross Target Static Library: Empty Project

A static library project is never run by itself. It is always linked to by other projects, called AVR Cross Target Applications.

Give the project a name (perhaps freeRTOS710).

Now a project will apear in the "Project Explorer" window. Select it. We are going to set some options relating to this project.

Project>>Build Configurations>>Set Active>>Release

Project>>Properties

AVR:Target Hardware: MCU Type: ATmega328p (or other depending on hardware)

AVR:Target Hardware: MCU Clock Frequency: 16000000 (or other depending on your hardware)

C/C++ Build: Configuration: [All Configurations] (make sure this is set for all following configurations)

C/C++ Build: Environment: AVRTARGETFCPU: 16000000

C/C++ Build: Environment: AVRTARGETMCU: atmega328p

C/C++ Build: Settings: AVR Compiler: Symbols: Define Syms (-D): Add... GCC_MEGA_AVR

C/C++ Build: Settings: AVR Compiler: Optimisation: Other Optimisation Flags: -mcall-prologues -mrelax (and use -Os or -O2)

Now we are going to add the freeRTOS files, from the freeRTOS710.zip file that you have downloaded from sourceforge, and extracted somewhere sensible.

File>>Import...>>General:File System

Select the "into folder" as the project name you just created, and "Select All" for the import. That should import the entire file system. Spend some time browsing, if you like.

Now we define the include library for the build. Remember to select [All Configurations] first.

Project>>Properties>>C/C++ Build>>Settings: AVR Compiler: Directories 

Add the from the "Workspace...": freeRTOS710/include

"${workspace_loc:/${ProjName}/include}"

Now there are three alternative memory management routines, explained in the freeRTOS documentation. We are going to use the heap_2.c version, so we need to exclude the other two files from the build. In the project explorer RIGHT CLICK (context menu) each one then exclude them.

./MemMang/heap_1.c

./MemMang.heap.3.c

Resource Configurations>>Exclude from Build...: Select All

Following this step, it should be possible to compile the library.

Project>>Build All

If there are any ERRORS, then go back and check the configurations for the project. Sometimes they may be changed, forgotten, or otherwise different from what you expected.

There will be some WARNINGS, relating to the usage of different Timers. I added these warnings to keep these things front of mind, as depending on which hardware I'm using the ./include/FreeRTOSConfig.h file needs to be managed to suit.

Step 7. Define an Application Project.

An Application will generate the final hex code that you upload to the AVR with avrdude. This final code is created from the freeRTOS static library code generated above, together with code contained in the avr-libc and pololu-avr libraries, and any other linked projects.

We are going to import the MegaBlink project (or the retrograde project, using the pololu-avr libraries) as it makes a good example. Without a display, or real-time-clock module, it will only flash a LED. But, least we know it is alive.

To get started create a new project as below.

Give the project a name (perhaps MegaBlink or retrograde).

Now a project will apear in the "Project Explorer" window. Select it. We are going to set some options relating to this project.

Project>>Build Configurations>>Set Active>>Release

Project>>Properties

AVR:AVRDUDE:Programmer:New...

Configuration name: Arduino or Freetronics 2010

Programmer Hardware: Atmel STK500 Version 1.x firmware

Override default port: /dev/ttyUSB0

Override default baudrate: as or if required.

AVR:Target Hardware: MCU Type: ATmega328p (or other depending on hardware)

AVR:Target Hardware: MCU Clock Frequency: 16000000 (or other depending on hardware)

C/C++ Build: Configuration: [All Configurations] (make sure this is set for all following configurations)

C/C++ Build: Environment: AVRTARGETFCPU: 16000000

C/C++ Build: Environment: AVRTARGETMCU: atmega328p

C/C++ Build: Settings: AVR Compiler: Directories: "${workspace_loc:/freeRTOS710/include}"

C/C++ Build: Settings: AVR Compiler: Symbols: Define Syms (-D): Add... GCC_MEGA_AVR

C/C++ Build: Settings: AVR Compiler: Optimisation: Other Optimisation Flags: -mcall-prologues -mrelax (and use -Os or -O2)

C/C++ Build: Settings: AVR C Linker: General: Other Arguments -Wl,--gc-sections

C/C++ Build: Settings: AVR C Linker: Libraries: Add two "m" & "pololu_$(AVRTARGETMCU)" without quotes. m is the standard math library, which should be included in most projects. (pololu library is an optional step, if using the retrograde project).

C/C++ Build: Settings: AVR C Linker: Objects: Other Objects Here you need to add the compiled freeRTOS library. And this is the only place where the Debug and Release builds are different.

With Release Build selected, paste "${workspace_loc:/freeRTOS710/Release/libfreeRTOS710.a}"

With Debug Build selected, paste "${workspace_loc:/freeRTOS710/Debug/libfreeRTOS710.a}"

Or select the Workspace option to navigate to the actual assembler files to be linked into the project.

Project References: freeRTOS710 ticked.

Now we are going to add the MegaBlink (or retrograde) files, from the MegaBlink.zip (or retrograde.zip) file that you have downloaded from sourceforge, and extracted somewhere sensible. If you downloaded the freeRTOSxxx_All_Files.zip, you have all the sources.

File>>Import...>>General:File System

Select the "into folder" as the project name you just created, and "Select All" for the import. That should import the 2 files shown inro the project file system. Spend some time browsing, if you like.

Following this step, it should be possible to compile and link the project.

Project>>Build All

If this step completes successfully, with no additional ERRORS, then the final step is to upload the new application into your Arduino or Freetronics device.

Make sure that you have your device plugged into the USB port, then simply hit the AVR* button in the row of buttons. You will see some green text showing the status of the upload, finishing with the words

avrdude done. Thank you.

Now, you should have a flashing LED.

Now you can import any additional projects, in the same way. However, the Pololu library can be omitted for most of my other code.

Step 8. Things to watch.

Turn on the serial port by removing the comments around the serial port definitions, and watch to see aspects of the program in action.

Expect to manage the amount of heap allocated in the ./include/FreeRTOSConfig.h file, to ensure that the total SRAM utilised (as noted in the final link stage when using heap_1.c or heap_2.c) remains less than 100% or for ATmega328p 2048 bytes.

Expect to manage the amount of stack space allocated to each task during the set up, to ensure you're not wasting space, nor (worse) you're over writing another task's stack.

Keep the total number of tasks to below 4, otherwise too much SRAM is consumed.

We could really do with a ATmega1284p based Arduino. It has 16kbyte of SRAM available. Which leaves about 15,000 Bytes SRAM available, rather than just 1,500 Bytes with 328p. Party on!

Windows 7 Starter with (up to) 128GB RAM

So most of my computers run a version of Ubuntu, Debian or Android. Used to be contrarian, but these days seems more devices are built on Linux kernels than almost any other type, so I'm just part of the mainstream.

Unfortunately, I also love the occasional First Person Shooter video game, or spend hours in an immersive Virtual Reality environment. It is an addiction, which I can mostly control. But sometimes, well, game on.

The one thing that Linux doesn't do well is gaming. All the best games these days are released on the DX10 or DX11 platform on Microsoft Windows 7. So, like an alcoholic with a whiskey stash, I need to keep a Windows version stashed somewhere to appease the addiction.

Recently, I purchased a HP Netbook. The Windows 7 system it came loaded with was erased within 90 minutes of unboxing, and that was that.

When it came to rebuilding and upgrading my gaming machine, I thought why not repurpose that Windows 7 Starter licence as my DX11 gaming platform. A few hours later, with my shiny new Windows 7 Starter SP1 was installed, validated, and perfectly legal, I found only two issues with the Window 7 Starter SP1 operating system.

1. No Aero. Being used to Compiz on Ubuntu, being stuck on one screen with few decorations seemed pretty last millennium. But since this is a gaming stash, that I will always be playing full screen, there is really no downside.
2. Limit to 2GB RAM. The Windows 7 Starter version does not support more than 2GB of RAM, though other versions reportedly support up to 4GB. This was a problem for me, as my machine runs much more RAM, and I hate waste.

Microsoft provides this table describing the limits on X86 (32bit) Windows 7.

The dirty little secret

The secret that Microsoft doesn't want to tell you is that 32-bit editions of Windows 7 are limited to 4GB is not because of any technical constraint on 32-bit operating systems. All the 32-bit editions of Windows 7 contain the code required for using physical memory above 4GB. Microsoft just doesn’t license you to use that code.

I sourced the information I'm quoting from Greg Chappell's web site, and I've found it to be completely true.

There are other resources on the Internetz and Torrentz that provide some patch code together with mysterious installers that may or may not address the memory limitation issue, too. But, since we're dealing with the Kernel of my operating system, I was not sure that they would or would not add any Trojans, Malware, or similar. So let's stay away from that stuff.

Following the recipe

Following Greg's recipe to create a kernel is relatively simple. He lists all the things to do very clearly. I have extracted some of his words below, and modified them for my simple minded clarity.

The only executable that we're going to touch is the PAE kernel, named NTKRNLPA.EXE, from 32-bit editions of Windows 7 SP1. The known builds have a routine named MxMemoryLicense in which there are two sequences of nearly identical code, one for each relevant license value. Each sequence calls the undocumented function ZwQueryLicenseValue and then tests for failure or for whether the data that has been read for the value is zero. In the known builds, each sequence has the following instructions in common:

7C xx

jl      default

8B 45 FC

mov     eax,dword ptr [ebp-4]

85 C0

test    eax,eax

74 yy

je      default

So the idea is to get A COPY of your NTKRNLPA.EXE and rename it ntkr128g.exe This is the file you are going to patch. Use a Hex/Byte editor to search for the byte string 8B 45 FC 85 C0 74. You will find approximately 25 occurrences of this byte string within the ntkr128g.exe file found in my Windows 7 Starter SP1 system. You need the PATCH THE LAST TWO OCCURRENCES ONLY.

Both occurrences are to be patched the same way. The patch is designed to vary the ordinary execution as little as possible. The kernel is left to call ZwQueryLicenseValue as usual and to test for failure, but the last three of the above instructions are changed so that the kernel proceeds as if the retrieved data is the value that represents 128GB (which is the least value that removes licensing from the kernel’s computation of maximum physical address). Change the 7 bytes starting from 0x8B so that you now have the following instructions:

B8 00 00 02 00

mov     eax,00020000h

90

nop

90

nop

This means that you replace the last two occurrences of 8B 45 FC 85 C0 74 yy with B8 00 00 02 00 90 90 in the file. Great. You're done. Well not really. You have to follow Greg's instructions to add a digital signature to the kernel, so that it can boot properly.

To add the digital signature, you need to download the Microsoft Software Development Kit, and install the tools (only tools required) to get access to the certification and signing tools to enable the kernel to boot. I did it. It is not hard. Just a little time consuming.

In Test Mode, the loader relaxes its integrity checking such that any root certificate is accepted. For suitable tools, with documentation, look in either the Windows Software Development Kit (SDK) or the Windows Driver Kit (WDK). To make your own certificate, run some such command as

makecert -r -ss my -n "CN=On My Authority"

This creates a root certificate for an invented certification authority named "On My Authority" and installs it in the Personal certificate store, which is represented by “my” in the command. You can view the new certificate by starting the Certificate Manager (CERTMGR.MSC), which also lets you set a Friendly Name for the certificate if you want to keep it. To sign your modified kernel with this certificate, run the command

signtool sign -s my -n "On My Authority" ntkr128g.exe

If you want to save some time, you can get a signed kernel here.

ntkr128g.exe

Once you have a kernel, then the rest is pretty straight forward. You need to use the bcdedit command to create an alternative booting information, following Greg's instructions.

bcdedit /copy {current} /d "Windows 7 128GB"

Interesting commands to add to the kernel (which you put back in the same directory as the original NTKRNLPA.EXE, of course) are below

{guid} refers to the id of the BCD entry that you're editing.

bcdedit /set {guid} kernel ntkr128g.exe

bcdedit /set {guid} testsigning on

bcdedit /set {guid} pae ForceEnable

bcdedit /set {guid} increaseuserva 3072

These instructions tell the BCD boot loader to:

• Load the ntkr128g kernel.
• Ignore that Microsoft has not signed it. Treat it as a test kernel.
• Force on PAE (Physical Address Extension). Which is irrelevant really, as it is automatically turned on when DEP (Data Execution Prevention) is enabled, which is the default case for Windows 7.
• Increase the maximum amount of memory that a single application can address to 3072kB (up from 2048kB).

Update

On December 13 2011 Microsoft released an advisory that updates the kernel. 

The above kernel has been updated to reflect this change and is now version 6.1.7601.17713.

Everything is working as usual.

Update

On April 10 2012 Microsoft released an advisory that updates the kernel. 

The above kernel has been updated to reflect this change and is now version 6.1.7601.17790.

Everything is working as usual.

Presto up to 128GB RAM

Once this kernel is booted, you will note that the screen comes up with a small note in the lower right corner of the Desktop that Windows 7 is in "Test Mode", which is to note that you're testing your own kernel. Well great. Thanks.

That's it. Testing with real games (eg Battlefield 3) show that over 2.3GByte can be allocated to one application. Game on!

Dogbot - Post 6 - Back on (PID) track

Exactly a year has passed since my last post on the Dogbot. I ended up getting very frustrated with my inability to get sensible odometry out of the Pololu Encoders using the Orangutan SVP auxiliary processor, and needed to put the project aside for a while.

I believe that I spend a good few weeks digging into the code, to see why I wasn't getting sensible readings from either, or at times both, of the sensors. Then I gave up, and took up an easier challenge being learning PWM control, and started building the Retrograde Clock.

Recently, I picked up the Dogbot again, and determined that I would make it work. I worked out that one of the Encoders was not right, using my excellent new Seeedstudio DSO Nano. So, then I ordered a new Encoder. At the same time I ordered a new chassis for Dogbot, as the old one was damaged by my cleaner, and decided to replace the medium capacity Liquidware Backpack, used for driving the motors, with a high capacity variety.

I took the opportunity to rebuild the dogbot onto the new chassis, and to simplify the system to make it more robust. One construction change was to use the Wall Plugs as a flexible structure, and screw into their ends, rather than using them as a spacer with a bolt through the middle. This allowed me to use the ends of the wall plugs as mounting points, because they could be fastened tight. Previously, because of the angles, they had needed to remain relatively loose.

(download)

Click here to download:

dogbot-post-6-back-on-pid-track-wsqiHBhzCpBgoIaIzxvw.zip (5.31 MB)

I have removed the rear mounted PIR sensor at this stage. It is easy to add again, at the appropriate time.

(download)

Click here to download:

dogbot-post-6-back-on-pid-track-ADqgCkEHfpfEnHljiFiC.zip (5.46 MB)

Following reconstruction, I found that the Encoders continued to give unusual (wrong) results. Finally, I looked into the details of the encoder outputs again, using the DSO, and realised that their outputs really NEED to be exactly tuned, using the tiny pots, to 50% duty square waves, otherwise the Orangutan SVP cannot get an accurate count. With this fixed, then the Odometry was built up accurately, measuring the count to travel a fixed distance. With this figure, the actual diameter of each wheel can be calculated, and hence the travel required to go in a straight line.

It is important to note, that Dogbot doesn't go in anything like a straight line, with full power applied to each motor. The friction, and wheel size differ enough to make it curve quickly from the straight and narrow. So PID is absolutely necessary to keep it running straight. With PID implemented properly then, finally, Dogbot runs straight.

These photographs are taken with the display indicating two items. On the top line, the target distance, represented in x and y distance to travel, is noted. Also the deviation from correct heading to target. The instruction is requesting Dogbot to travel 50cm along what it has been told is the x dimension. The instruction is also implying that the Dogbot is initially facing in y direction, and needs to rotate its poise 90deg clockwise to face along x, before it begins its travels.

The code is set up to all allow specification of an initial poise, and a final poise, as well as x and y distances to travel, for the Transport Task to undertake.

The bottom row of the display shows the distance reading indicated by each of the three sensors across the front of Dogbot. Central indication being the I2C ultrasonic sensor, which is very accurate, but not at all directional. Left being the long range IR sensor, and Right being the medium range IR sensor. These sensors are very directional and can differentiate a thin rod or edge of a hand placed in front of them. Combination of these sensors will enable Dogbot to travel safely in a forward direction.

Not displayed is the output from the I2C thermal sensor. It has been tilted back, so that its vertical array of 8 pixels is looking up from +5deg to +70deg. It can see very small differences in temperature from ambient, which it also reports.

At this stage my work continues to get the Dogbot to consistently travel from one location/poise to another location/poise. Whilst I have the code in a state that it can achieve this, it doesn't yet do it consistently, because of variables in the drive system that need to be properly tuned. And, I could improve the code a lot too. The code is a bit amateurish.

Notes to photographs

(download)

Click here to download:

dogbot-post-6-back-on-pid-track-biJmbtnFJoGcAvelrryi.zip (13.3 MB)

Liquidware battery packs have a on/charge switch that effectively isolates the battery. This has proven useful, as I can turn the motors off, whilst still programming the Orangutan SVP. Not designed, but in hindsight very useful.

To counter sagging voltages, and noise on the supply lines, I have fitted 1uF Tantalum capacitors on all of the sensors. This helps to ensure that they are getting a good supply when they are firing.

Both Thermal array sensor, and Ultrasonic distance sensor are canted up to get their cone of vision away from the floor. I have left the IR distance sensors facing parallel with the floor, as they don't get false readings from the floor (assuming it is flat), and I don't want to miss low objects that might interfere with the Dogbot.

I added the fishing weights to the rear of Dogbot to ensure it had good balance. It has sufficient weight to rear from the batteries to stand up properly, but when braking it is quite top-heavy. So, the low heavy weight at the rear helps to ensure that it doesn't tip over.

Although there are no other items on the motor circuit, I have added some 1nF bypass capacitors on the motors. Can't hurt.

It is alive. Here the IR glow from the sensors has been captured by the camera. Perhaps Skynet lives?

My next steps are to finish the Transport Task so that it can reliably go from point to point. Then, I'll integrate more information into the Transport task from the accelerometer sensors, to improve directional accuracy. Then to build some mapping code to allow obstacles to be located and avoided.