Storing/Reading intial values on/from a SD card - Which object to use?

pacman

On power-up my application needs to load some parameters (serial address/baud rate/ + some other bits and pieces (each 'fittable' into single integer)).

I'm thinking on power-up why not read this data off the SD card. Read "Setup.txt" (or .ini or .WhateverItNeedsAsAnExtension) and then parse that data.

I could either just go the line 1 = Address, line 2 = baud, etc, etc or the Windows '.ini' way where you search for the text "Address=1". At this stage I have no preference.

Is there an object in the OBEX that is already doing all this?

I'm looking at the ummc object at the moment, but perhaps there is a hidden gem I'm not seeing or there a plethora of Gotchas with this object that someone might warn me of...

As always, Thanks heaps in advance....

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
=================
The future is in our hands.
Which way to the future?
=================

Post Edited (pacman) : 3/29/2010 2:17:59 AM GMT

localroger

The main problem with using sequential SD files is that all of the existing public objects are geared toward reading data from the file in fixed chunks. There is no function in any of them I've seen that will read characters from the card until it encounters CR and stop. This means you would have to read fixed blocks, implement your own cursor, and scan to build your input strings in a buffer loading new blocks as necessary when you run out of characters midstring. This would probably take 50 lines or so of Spin code, and wouldn't be very fast, but that wouldn't matter for reading .ini files.

Dr_Acula

This should be possible - it is just a matter of structuring the file. Eg on the dracblade code is a very simple routine to open a file, read 8 bytes and close it. It uses rather old fsrw code on a fat16 sd card, and yes there are more up to date versions, but it is simple to use.

I'll copy the relevant bit of code and obviously this would change a bit

PUB GetMyname | r
    ' reads 8 bytes from MYNAME.TXT and puts them in the DMA starting at address 80
  r:=sd.popen(string("MYNAME.TXT"),"r")
  r:=sd.pread(@myname,8)                                  'get 8 bytes Alpha... Beta.... etc
  if r => 0           ' *** note => not >= ***
    'vgatext.str(@myname)
    RamLatches.DoCmd("W", @myname, 128, 8) ' move 8 bytes from myname array to address 80H
  sd.pclose

The biggest issue is how you store data. If you store a number you could store it as the ascii value 0-255 ie a byte. But you can't edit that with a text editor. Or you could store three bytes eg 159 and then you need to multiply by 100 for the first byte and 10 for the second etc to recreate the byte. Do you need the .ini file to be easily read? The simplest is to store just numbers but you can't see what the numbers are and down the track you might forget. I've sometimes used fixed width fields
variable1 020
variable2 025

where there are n bytes before the value and you always pad to the same number. Then when reading the file you discard n bytes, then read 3 bytes, discard n bytes etc. Or you can comma seperate and there are all sorts of methods of varying complexity to decode.

I'd probably go for fixed width descriptors in text that are a multiple of 4 bytes eg 16 bytes, then 4 bytes for the integer. Then it is easier to manipulate with longs. Read 4 longs and discard. Read 1 long and convert to an integer. etc

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller

MagIO2

I think those values are better to be stored in the EEPROM. What happens if the SD card is not inserted? What happens if it's broken? Is it a good usecase that you have to change the .INI-file just for changing the baudrate? (unplug SD card, insert into PC, change file , insert into propeller system, restart ) Isn't it easier to have a menu on the prop which allows to change those settings and writes the changes to EEPROM? Writing it directly into the variable means no additional parameter read on boot. It's simply there.

Just my 2 cents.

pacman

MagIO2 said...
I think those values are better to be stored in the EEPROM. What happens if the SD card is not inserted? What happens if it's broken? Is it a good usecase that you have to change the .INI-file just for changing the baudrate? (unplug SD card, insert into PC, change file , insert into propeller system, restart ) Isn't it easier to have a menu on the prop which allows to change those settings and writes the changes to EEPROM? Writing it directly into the variable means no additional parameter read on boot. It's simply there.

Just my 2 cents.

I would normally agree with you, as your suggestion is what I would _normally_ do...

but the application needs an SD card to work (the SD card contains 256 'pre-canned' wav files) anyways. So no SD = no work.

Seeing as the {in the event of unit failure} the recovery method is "take the old SD card out and put it in the new device" I thought it would be a good way of making the settings portable between units.

Perhaps there is a another method I haven't thought of - I would welcome the suggestions

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
=================
The future is in our hands.
Which way to the future?
=================

Post Edited (pacman) : 3/29/2010 10:38:35 AM GMT

Timothy D. Swieter

I too am interested in the solution that you implement Pacman. In some of my design sketches for the Propeller Web Server product I have been considering the advantages/disadvantages of storing or retrieving settings data on the SD card. There are some settings that the system will keep in the EEPROM, but there could always be some sort of reconfiguration file that upon bootup changes the settings as desired.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
www.tdswieter.com

MagIO2

What I currently have is a parser, which can read a user input and converts the given line to 32 bit-values in an array. You can enter decimal numbers, hex-numbers and binary numbers. All other data is handled as string and only the pointer to that string is stored in the parameter array. Feeding that by a line read from a file should not be a big problem.
The first part of the line in my case is a command and treated a special way- it's converted to a hash value. So, all you need to do is create a case statement with all allowed hash-values. In this case statement the parsed parameters are copied to the variables where you need that value.

So, a ini-file could look like that:
BaudRate 9600
SerialBasePin 12

or

SerialPort 12 9600

I think the needed changes could be done in minutes. - Only problem ... currently I'm at work ;o)

Dr_Acula

So what exactly is the problem again?

Seems pretty easy to me. The zicog/dracblade/triblade/ramblade suite already do this. You can even read in the wav file as human readable numbers - hex or decimal. Plus all the parameters you would ever need. It just needs some simple string manipulation on the data in that file. Is that the problem - lack of easy string manipulation code?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller