Using SD card as parameter storage

TC

Hello all,

I have not tried playing with this yet, and I figured I would ask for some advice before I do.

I am working on a project that has 1000 capative touch inputs. Each input is tied to an audio file. There are going to be 1000 audio files.

I was thinking of using the SD card that holds the WAV files, to store the touch sensor parameters, and how the audio files are linked.

One idea I had was....

With a fresh (formated) SD card, the prop would not see a parameter file. It would then make the file, then scan to see how many touch sensors are installed. It would then read the default parameters from each touch sensor chip (cap1188), and save the parameters to the SD card.

Then the prop would make a file for the audio file linking. The file would have a list of all the attached sensor inputs.

Both of these files would be in CSV format. That way EXCEL could be used as an easy way to edit the parameters, and the audio file linking.

My questions are....

What would be the best way to set up the parameter file for ease of use on EXCEL, and ease of use for the prop?

How difficult would it be to read the parameter file, and load each touch sensor chip with the values in the file? (Just need help with reading the file).

For the audio link file, I was planing to have just 2 columns. Column 1 for the sensor number, column 2 for what audio file to link to. What would be the best option for the audio file name that would be easy for the prop to use? ("Audio file.wav", or something else)

I hope these questions are understandable. I did not want to jump right in, without first having some idea on how I should do it.

Thanks
TC

DavidZemon

Everything you're asking for sounds quite reasonable and not too hard at all. Before anyone can offer up code examples though, we'll need to know what language you're using. There are ready-to-go libraries for Spin, C, and C++ at the very least (not sure about Basic or Forth) which will all make communication with an SD card quite simple. I know Forth can communicate easily with an SD card, but I also know it uses its own filesystem by default (perhaps it also has the option for a FAT32 partition?).

TC

DavidZemon wrote: »

Everything you're asking for sounds quite reasonable and not too hard at all. Before anyone can offer up code examples though, we'll need to know what language you're using. There are ready-to-go libraries for Spin, C, and C++ at the very least (not sure about Basic or Forth) which will all make communication with an SD card quite simple. I know Forth can communicate easily with an SD card, but I also know it uses its own filesystem by default (perhaps it also has the option for a FAT32 partition?).

Sorry about that. Knew I would forget something.

I am using Kwabena's V2-WAV player for the audio. I was going to use his FAT driver since it is already taking up prop ROM space. I used Parallax's Learn code to test the setup I have. I can make files, and import data to excel, but I can't find anything that explains how the prop can read parts of a file to get the values needed.

TC

Peter Jakacki

Tachyon supports FAT32 out of the box, it's just that it can treat the card and/or files as virtual memory. So you open a file and read and write to it as if it is a memory chip with up to four files open at a time. There is also WAV file support so these files can easily be played. Rather than CSV look at fixed fields instead so your code can find stuff easily and you could also consider editing the files on the Prop itself perhaps via a terminal, be that a PC or a tablet on Bluetooth or even over the Internet.

Dave Hein

I haven't use Kye's driver myself, but there should be an easy way to read one line at a time from an Excel file. You would probably want to use a comma-delimited format, so you would just need to search for commas to find parameters. It would be best to stick with integer parameters, but you could also use floating point values. It just that floating point will have required more code to support it.

TC

Peter Jakacki wrote: »

Tachyon supports FAT32 out of the box, it's just that it can treat the card and/or files as virtual memory. So you open a file and read and write to it as if it is a memory chip with up to four files open at a time. There is also WAV file support so these files can easily be played. Rather than CSV look at fixed fields instead so your code can find stuff easily and you could also consider editing the files on the Prop itself perhaps via a terminal, be that a PC or a tablet on Bluetooth or even over the Internet.

I have never used tachyon before, and I don't know if it would be a good idea to learn it right now. I am on a deadline. I would not be around to change the parameters, so I wanted to find a way to make it somewhat easy for others to change the parameters and the audio file linking without additional software. Again, just to make it easy. Personally, I would be using the EEPROM to store the parameters and the audio linking. But that is not easy for others.

TC

TC

Dave Hein wrote: »

I haven't use Kye's driver myself, but there should be an easy way to read one line at a time from an Excel file. You would probably want to use a comma-delimited format, so you would just need to search for commas to find parameters. It would be best to stick with integer parameters, but you could also use floating point values. It just that floating point will have required more code to support it.

It would only be 8-bit values. I would be storing the exact parameters the sensor chips need. That way the prop doesn't have to do anything extra. Just read the file, and send the data to the chips.

I was thinking of the prop just looking for the comma to make things easier, but I didn't know it it would be.

TC

kwinn

From your description I gather that each touch pad will play one specific song. Since each touch pad has to have a unique address to be able to tell which one has been pressed why not use some derivative of that address for the file name. For example if touch pad #3 of chip #131 was pressed why not have the file it plays named "1313". Converting the chip address and touch pad number to the equivalent ascii text is simple compared to looking up the file in a table.

DavidZemon

kwinn wrote: »

From your description I gather that each touch pad will play one specific song. Since each touch pad has to have a unique address to be able to tell which one has been pressed why not use some derivative of that address for the file name. For example if touch pad #3 of chip #131 was pressed why not have the file it plays named "1313". Converting the chip address and touch pad number to the equivalent ascii text is simple compared to looking up the file in a table.

If the intention is to allow co-workers/customers/users/whatever to easily change the sound mapping in the future, I could see that becoming more difficult than changing an excel sheet full of:

1,beep.wav
2,moo.wav
3,vroom.wav

Cluso99

My Prop OS uses Kye's FAT drivers and there is a whole set of dos style command with source so you can see how to copy files, etc in spin. Itseasy to search for files.
For a link see my signature.

TC

kwinn wrote: »

From your description I gather that each touch pad will play one specific song. Since each touch pad has to have a unique address to be able to tell which one has been pressed why not use some derivative of that address for the file name. For example if touch pad #3 of chip #131 was pressed why not have the file it plays named "1313". Converting the chip address and touch pad number to the equivalent ascii text is simple compared to looking up the file in a table.

I was thinking at one time around the same idea. I was thinking of just naming the audio files with the sensor number. "1043.WAV" would be the audio name with your example ( (130 chips * 8 sensors) + 3 more sensors = 1043 )

I will have to bring up the idea to the person I am doing this for. I see it being a simple idea for linking the audio files.

TC

Cluso99 wrote: »

My Prop OS uses Kye's FAT drivers and there is a whole set of dos style command with source so you can see how to copy files, etc in spin. Itseasy to search for files.
For a link see my signature.

I will have to look more into that. Currently I dont have the time to look through the code, since I am at work. But when I get home, I will have some time to look it over

TC

JonnyMac

I wrote a parser last year so that 1) I can deal with on-the-fly commands from a serial port, and 2) read configuration data from a file. For the latter, you simply read a line (I prefer FSRW) and pass it to the parser. If there are valid tokens then you deal with them. I don't have a configuration demo that I can share, but I can knock one together for you if you need. I do have a live command demo which shows how to setup the parser.

If you run the attached demo on an Activity Board and enter

HIGH 26

... the LED on P26 will turn on. You can also do this:

HIGH, 26

That is to say that you can pass it a CSV formatted line to the parser. As long as "," is not a valid character, it will be considered a field separator (I tend to use spaces in my configuration files). That said, if you need a string field that includes spaces, you can enclose them in double quotes (I added this for the Hackable Badge congituration code which uses my parser).

A note on audio file naming. I do a lot of this, as I co-created the AP-16+, am presently working on the AP-8+, and do lots of custom audio projects. With FSRW, anyway, you can use long file names on the SD card as long as you use 8.3 notation in your code. Since you want to associate audio with a sensor number, using the number in the file name is a good idea. Put it at the head of the name. From a user perspective, just a number is not very friendly. Here's the trick: Use a long file name but make sure that the first six characters are unique. For example:

00001_JONS_VOICE.WAV

... will be seen by FSRW as

00001_~1.WAV

By adopting this format you can do something like this:

dat

  WavName       byte    "00000_~1.WAV", 0


pub play_file(n) | divisor, idx

  divisor := 10000

  repeat idx from 0 to 4
    WavName[idx] := "0" + (n / divisor)
    n //= divisor
    divisor /= 10

  audio.play(@WavName)

TC

JonnyMac wrote: »

I wrote a parser last year so that 1) I can deal with on-the-fly commands from a serial port, and 2) read configuration data from a file. For the latter, you simply read a line (I prefer FSRW) and pass it to the parser. If there are valid tokens then you deal with them. I don't have a configuration demo that I can share, but I can knock one together for you if you need. I do have a live command demo which shows how to setup the parser.

If you run the attached demo on an Activity Board and enter

HIGH 26

... the LED on P26 will turn on. You can also do this:

HIGH, 26

That is to say that you can pass it a CSV formatted line to the parser. As long as "," is not a valid character, it will be considered a field separator (I tend to use spaces in my configuration files). That said, if you need a string field that includes spaces, you can enclose them in double quotes (I added this for the Hackable Badge congituration code which uses my parser).

A note on audio file naming. I do a lot of this, as I co-created the AP-16+, am presently working on the AP-8+, and do lots of custom audio projects. With FSRW, anyway, you can use long file names on the SD card as long as you use 8.3 notation in your code. Since you want to associate audio with a sensor number, using the number in the file name is a good idea. Put it at the head of the name. From a user perspective, just a number is not very friendly. Here's the trick: Use a long file name but make sure that the first six characters are unique. For example:

00001_JONS_VOICE.WAV

... will be seen by FSRW as

00001_~1.WAV

By adopting this format you can do something like this:

dat

  WavName       byte    "00000_~1.WAV", 0


pub play_file(n) | divisor, idx

  divisor := 10000

  repeat idx from 0 to 4
    WavName[idx] := "0" + (n / divisor)
    n //= divisor
    divisor /= 10

  audio.play(@WavName)

Thank you Jon, that is great. I am going to do some playing around with it and see what I can come up with. You did make my life so much easier right now.

TC

JonnyMac

Look over the attached demo and see if it helps -- it shows how to parse values out of a CSV file. As coded, it expects three fields per line.

TC

JonnyMac wrote: »

Look over the attached demo and see if it helps -- it shows how to parse values out of a CSV file. As coded, it expects three fields per line.

That works great!! Thanks for the help. I was a little confused at the beginning, all the values had blank spaces in front of them, and they were not in hex. Then I seen

  repeat field from 0 to 2
    term.rjdec(value[field], 5, " ")

It then made sense

This was a good touch. Had to try it.

term.str(string("You're kidding, right?"))

Thanks
TC

PaulRowntree

How will you multiplex the 1000 touch pad to the Prop ?

TC

PaulRowntree wrote: »

How will you multiplex the 1000 touch pad to the Prop ?

The chips will be in SPI mode. The they will share the clock, data in, data out, reset, and alert lines (with buffers, and other logic gates to help). The chip selects will be hooked to a single flip-flop, creating a massive (physically) shift register.

Check out my other post for the conversation.

TC

JonnyMac

That works great!! Thanks for the help. I was a little confused at the beginning, all the values had blank spaces in front of them, and they were not in hex.

Keep in mind:
-- this is a demo and values are extracted to a local array
-- you need to do something app-specific with the extracted values
-- Internally, everything is binary; notations (decimal, binary, or hex) are for humans

My strings object has the ability to detect and convert decimal, binary (requires %), and hex (requires $) values.

TC

JonnyMac wrote: »

That works great!! Thanks for the help. I was a little confused at the beginning, all the values had blank spaces in front of them, and they were not in hex.

Keep in mind:
-- this is a demo and values are extracted to a local array
-- you need to do something app-specific with the extracted values
-- Internally, everything is binary; notations (decimal, binary, or hex) are for humans

My strings object has the ability to detect and convert decimal, binary (requires %), and hex (requires $) values.

That little demo helped me out a lot. I already made the prop create a file (master config) that stores all the general register values that will be loaded on all the sensor chips. For example, if the "ALERT" line is active high, or active low (they all should be set the same). I want to make a second file that has parameters for each sensor chip, values that can not be part of the master file.

I am now using your example to make a way to change registers on the fly. It will read the SD card, display the value, and if needed change the value. The new value would be loaded to the sensor chip. If we want to keep the value, we can load the new value to the SD card.

TC