Message	Date	From	Subject
14683	2018-05-01 00:02:16	QRP Labs	Re: Digest Number 3036
Hi Allison Yeah all well said. I think the Arduino is fantastic, it really lowers the barriers to entry for newcomers to come in and get into programming. You can also do a LOT with even a basic 32K Arduino UNO, if you put your mind to it! Personally however I very rarely use the Arduino and even when I do, never for anything other than something very small I want to throw together very quickly. I've been programming for ages and I don't like the clutter that comes with Arduino. > An example I needed a lot of storage (megabytes). The microSD chips easily > interface to Arduino but the software libraries to use that device usiverally used > SDfat file system which is huge. The SDFAT file system was not needed as I could > use a simpler tag and bag. The problem is no one did bare uSD. I had to dig through > the libraries and then clean up what I found and add the tag and bag cost under > 4.5k program storage for the whole ap, the SDfat library would have used at least > 8-10K and much too much of the limited ram I'd need more code to live with it. > One of the things that was interesting is the almost religious you can't write to > a uSD without using fat file system. FYI you can but you have to do your > own accounting as in where did you put it. Reminds me of some years back when I developed this commercial wind speed logger project http://hanssummers.com/wind2 which recorded wind speed onto an SD card. There was no SD FAT Arduino library and I had to do a lot of research and investigation to figure out how to do it. I needed the storage on the SD card but I also needed it to comply with the FAT filesystem, so that the SD card could be plugged into a cardreader on a PC to read off the data. What I came up with was a minimal FAT file handler, the firmware erased anything that was on the SD card and created a single text file "data.txt" into which it appended the data. It was highly simplified FAT because there was only ever one file and it was contiguous. Nevertheless it was all correct and the PC could read it fine. The whole system ran at 32.768kHz clock speed with a watch crystal. Current consumption in sleep was only a uA or so on average, including waking up briefly every 10 seconds to take a measurement; rising to about 40mA during the SD-card write once every 100 minutes, for around 1.5 seconds. Power consumption was low enough for at least 6 months operation on the PP3 9V battery. The firmware included realtime clock, analogue sensor readings (wind direction, temperature, solar intensity), averaging of analogue readings, standard deviation of wind speed, LCD driver (8x2 LCD), as well as the SD and FAT stuff. Programmed in C. All in an ATmega88 (8K Flash) though if I recall it actually would have fit into an ATmega48, I was just conservative in case future enhancements were needed (they weren't). More recently during development of the QCX CW transceiver http://qrp-labs.com/qcx I even managed a panadapter in the ATmega328, alongside all the other stuff... 10-bit audio sampling at 12kHz, and a simple FFT running with 20 buckets each 50Hz wide, centered on 700Hz; then I used the right 4 x 2 characters of the LCD with custom-generated LCD characters (since the HD44780 LCDs support 8 custom pixel maps); the right 4 x 2 characters made a 20 x 16 pixel display to show the results of the FFT. Surprisingly it did work! Very cool! But it was rather complex to integrate it with all the other stuff I needed to include and I ran out of time, trying to make it work! So it is not in the final QCX firmware. I grew up on 8-bit home computers like the Sinclair ZX Spectrum (Z80), Acorn Electron (6502). Those processors were a lot less capable than an ATmega328. I think growing up around those early computers was a great education in how to squeeze out the most from modern microcontrollers. 73 Hans G0UPL http://qrp-labs.com

Hi Allison

Yeah all well said.

I think the Arduino is fantastic, it really lowers the barriers to entry for newcomers to come in and get into programming. You can also do a LOT with even a basic 32K Arduino UNO, if you put your mind to it! Personally however I very rarely use the Arduino and even when I do, never for anything other than something very small I want to throw together very quickly. I've been programming for ages and I don't like the clutter that comes with Arduino.

> An example I needed a lot of storage (megabytes). The microSD chips easily

> interface to Arduino but the software libraries to use that device usiverally used

>

SDfat file system which is huge. The SDFAT file system was not needed as I could

>

use a simpler tag and bag. The problem is no one did bare uSD. I had to dig through

>

the libraries and then clean up what I found and add the tag and bag cost under

>

4.5k program storage for the whole ap, the SDfat library would have used at least

>

8-10K and much too much of the limited ram I'd need more code to live with it.

>

One of the things that was interesting is the almost religious you can't write to

>

a uSD without using fat file system. FYI you can but you have to do your

>

own accounting as in where did you put it.

Reminds me of some years back when I developed this commercial wind speed logger project http://hanssummers.com/wind2 which recorded wind speed onto an SD card. There was no SD FAT Arduino library and I had to do a lot of research and investigation to figure out how to do it. I needed the storage on the SD card but I also needed it to comply with the FAT filesystem, so that the SD card could be plugged into a cardreader on a PC to read off the data.

What I came up with was a minimal FAT file handler, the firmware erased anything that was on the SD card and created a single text file "data.txt" into which it appended the data. It was highly simplified FAT because there was only ever one file and it was contiguous. Nevertheless it was all correct and the PC could read it fine.

The whole system ran at 32.768kHz clock speed with a watch crystal. Current consumption in sleep was only a uA or so on average, including waking up briefly every 10 seconds to take a measurement; rising to about 40mA during the SD-card write once every 100 minutes, for around 1.5 seconds. Power consumption was low enough for at least 6 months operation on the PP3 9V battery.

The firmware included realtime clock, analogue sensor readings (wind direction, temperature, solar intensity), averaging of analogue readings, standard deviation of wind speed, LCD driver (8x2 LCD), as well as the SD and FAT stuff. Programmed in C. All in an ATmega88 (8K Flash) though if I recall it actually would have fit into an ATmega48, I was just conservative in case future enhancements were needed (they weren't).

More recently during development of the QCX CW transceiver http://qrp-labs.com/qcx I even managed a panadapter in the ATmega328, alongside all the other stuff... 10-bit audio sampling at 12kHz, and a simple FFT running with 20 buckets each 50Hz wide, centered on 700Hz; then I used the right 4 x 2 characters of the LCD with custom-generated LCD characters (since the HD44780 LCDs support 8 custom pixel maps); the right 4 x 2 characters made a 20 x 16 pixel display to show the results of the FFT. Surprisingly it did work! Very cool! But it was rather complex to integrate it with all the other stuff I needed to include and I ran out of time, trying to make it work! So it is not in the final QCX firmware.

I grew up on 8-bit home computers like the Sinclair ZX Spectrum (Z80), Acorn Electron (6502). Those processors were a lot less capable than an ATmega328. I think growing up around those early computers was a great education in how to squeeze out the most from modern microcontrollers.

73 Hans G0UPL

http://qrp-labs.com