I’m trying to write new firmware to the Logomatic V1 using the LPC2000 serial programmer sold by Sparkfun. My idea was to add a bootloader like the one on V2 so that you can reprogram it by putting the new firmware on the SD card. However I have no luck in getting contact with the LPC on the Logomatic using the serial programmer. I’ve tried with LPC flash utility and FlashMagic but I got no communication. Probably due to the fact that I have no idea which settings to use. Which crystal frequency should I use? Any pointers ? Also the LPC flash utility does not have a choice for LPC2038, which sould I use instead. Any help would be greatly appreciated.
UhClem:
It probably isn’t quite ready for prime time but it works so here are links to the source tree and a quick description of the new operating mode I have added.
160,000 SPS looks to be about the upper end unless I work on the ADC IRQ routine some more.
Comments, suggestions, bug reports, etc. are requested.
Hi David, just been reviewing your v4 logomatic code and have some queries?
1/ Is the zip/gz file complete? that is it contains all the files needed to successfully compile the firmware through winARM?
2/ I couldnt see any reference to the USB files. Does this firmware still allow the user to connect the logomatic to a pc via USB and have it present as a mass storage device?
nbl1268:
1/ Is the zip/gz file complete? that is it contains all the files needed to successfully compile the firmware through winARM?
2/ I couldnt see any reference to the USB files. Does this firmware still allow the user to connect the logomatic to a pc via USB and have it present as a mass storage device?
Thanks Neil
It is complete but is for the V1 hardware that doesn’t have USB. I compiled it using an evaluation version of Crossworks since that was used by the stock firmware.
UhClem:
(Note: My first attempt to post this ran afoul of some sort of filter. The message claimed I used a forbidden word but it might have just been spam filters.)
I have a high speed version of the code in work right now. The first step will be to replace the general purpose FAT code it uses now with something a bit more specific. Thrashing of the FAT table just slows things down so it will only be updated at file close time.
Second up is to shift to using the multiple sector write command.
If that isn’t fast enough the last step is to pre-erase most of the card prior to starting the write.
As I don’t have a Log-O-Matic in hand (yet) I have just been looking over the code. But I found some of the code in main.c offended me and I just couldn’t leave it alone. Along the way I did a number of things:
Replaced the ten copies of the ADC code with one general purpose subroutine.
Replaced the many copies of code to add a byte to the output buffers with a single subroutine that inserts a byte into the buffers.
Replaced the three copies of code that checks for a full buffer to write with a single subroutine.
Replaced the buffer code with something that can handle N buffers.
Removed the calls to fat_flush(). These appear to generate a write to update the directory and were called after every write.
Deleted a lot of variable declarations that were never used.
Decreased power consumption by entering idle mode when waiting.
Stomped a nasty bug in the code to read the configuration file. For some reason it declared a 256 byte buffer and then read 512 bytes into it. Never a good thing to do.
As I have never worked with an ARM processor before there is a good chance that I have missed some little detail plus the usual chances of bugs. But at this point the code at least compiles. I don’t see any way to post it here. It can be found at:
UhClem:
It is complete but is for the V1 hardware that doesn’t have USB. I compiled it using an evaluation version of Crossworks since that was used by the stock firmware.
Thanks David, I had interpreted the opening line in the main.c file to mean it was for the version 2 product.