Hello everyone, I'm trying to organize the way my project is storing information on the SD card. I need to store the information about a network of my devices. Each device has a few commands and each command has a few arguments. Number of commands and arguments varies from device to device. However, besides commads' and parameters' numerical IDs I want to store their names for UI.

So far I decided to have a 32-byte structure:

struct SDBlock
{
        char blockID[18];
        uint32_t devID;
        uint16_t command;
        uint16_t lParam;
        uint16_t hParam;
        uint32_t next;
}

In the memory, the first block will point to the first device (devID == nnn). SDblock->next will point to the next device's address, or 0 if this is the last device.

The second block will contain the first command (command == nnn), and its name. SDblock->next will point to the next command or 0 if this is the last command.

The third block will contain the first command's first parameter, and the possible range of valiues to set (range between lparam and hparam). SDblock-> next will point to the next parameter of the current command, or 0 if this is the last parameter.

Is this a good organization of memory for my needs or would someone recommend anything better?

Thanks. Stan.

Hi Stan,

I haven't thoroughly thought about what you are trying to do, but at first glance it doesn't sound like a bad idea. If you had three different structs defined, one for a device, one for a command and one for a parameter you might save a bit of space, since you won't be allocating space for parameters on command structs, or command names on device id's.

Is this structure completely defined at compile time? If new devices are coming in out of this structure you are probably going to have trouble deleting them and reclaiming the space without a file system of some sort.

Humberto

It's called a linked list and is a common way to keep track of items in memory when the list grows or shrinks as the program is running. Typically malloc() and free() are used to dynamically allocate and give back memory as the list changes.

If you have a fixed number of items, a simple array of structure elements will work just as well and then you can save a bit of space since the pointer (next) is not necessary.

Hi Noter,

I totally agree that if he were doing this in RAM you would probably want to use a more traditional data structure. I think Stan is trying to write this stuff out to an SD card though, and by the sound of it he is just writing the bits straight out to the card over SPI without having a file system on the card. This is why he is having to resort to scheme hatchery.

Humberto

Noter and Humberto, thanks for answering!

I'm using the SD card to keep track of dynamically added devices, and that would take up quite a lot of memory to keep all names of every device and its commands. Linked lists is exactly what I had in mind, except SD-card version of those. I can't really afford having a file system on the SD card, because then it'd require 512 bytes buffer, and uC I'm using doesn't have enough RAM for the FS buffer and the rest of program stack.

That's why I wanted to have a 32-byte buffer/structure to do all the reads and writes, and when I need to delete the device record from the middle of the list, I'd just shift all the data from further locations back.

However I had another idea today - to save only the 4-byte long device IDs, and when the need comes, query the rest of the information from this or that device with given ID. I think that would not only save some SD card space, but also remove the need for writing all the linked list functions I'd use.

Sounds like an interesting project Stan. Could you give a brief description of your what you're up to? I'm wondering what devices you are dealing with and the size of your SD card, etc.

Well, my code supports any standard capacity SD card (2.0Gb or less), Because high-capacity memory cards have to have 512 byte buffer no matter what. The card that I have is 2.0Gb

As far as the project itself, I've been slowly working on it since last year. I already got all the parts for it, it's just the programming left, and in this case it is the hardest part.

Essentially, there is a "host" device, that will talk to a bunch of "client" devices via digital RF signals. A user can do various commands on client devices either using buttons + screen on the host device, or using a computer, navigating the browser to the ip address of the host device.

So far my host can read IDs off the memory card, send a hand-shake command, and receive client's name.

I still need to write the whole RF protocol that the devices will use, and then I need to write some sort of a web-server.

Seems programming is always the bulk of the work on my mcu projects. I usually spend minutes hooking up hardware and then hours/days to make functional software.

Sounds as though you're building a generic control network that can be used for a variety of applications. It will be a good base for going forward.