LeafLabs Garden

A place to share, learn, and grow...

1. 

   raymadigan
   Member

   I have a maple mini application I have been working on for the past year. it works well as it is. I just decided that it would be good to add the code to make the sd card reader that I have on the board work.

   The application has migrated to a class oriented project with 90% of the software in a set of classes. I implement this through libraries. The basic structure is

   Device[Can be several]
   Manager[one per Device]
   Sampler[one per device]
   Duty[one per device]

   I have started implementing the sd card as a Logger class with the Device creating the instance. The logger has an instance of the HardwareSPI class, with two devices there are two HardwareSPI instances. This works and each Device can write to the card successfully. Each device completes its writing task before it gives up control.

   The problem is that I also need the Manager and the Sampler to be able to write to the sd card. This brings up all kinds of memory allocation issues if I just pass the logger instance to the Sampler or Manager.

   I am heading to the model where each class that needs to write to the sd card inherits from a logger base class. The issue is there will be potentially many instances of the HardwareSPI class instantiated and don''t understand it well enough to know if this causes an issue.

   I can post as much code as is needed, I didn''t think it would help.

   Any advise would be appreciated.

   Posted 2 years ago #
2. 

   higwoshy
   Member

   Personally, I'd use a global hardwareSPI as there are only 2 SPI ports available and probably only one SD card. Keep it simple. The Maple isn't a multi-tasking system, so unless your writing to SPI from a interrupt (probably not a good idea) then each class has exclusive use of the SD card until it finishes. Your classes would just need to keep a file handle open for each logger file, allowing each class to write to it's own file (or one file if you keep the file handle the same between all classes).

   That's one option, I'm sure there a lots of others.

   Posted 2 years ago #
3. 

   raymadigan
   Member

   The problem is I don''t know how to create a global variable that can be seen by the Libraries. I don''t think I have access to main, or don''t know how to get it.

   I have a temporary work around where I create a global SdFile and have any class that needs to write to the logger extern this variable. Then I can pass the logger from class instance to class instance. As long as everyone who writes to the logger is well behaved then it will work until I figure out the real solution.

   I haven''t tried it with multiple devices yet, I will do that test tonight.

   Thanks for your help.

   Posted 2 years ago #
4. 

   higwoshy
   Member

   I seem to remember I tried something similar and ran into the problem of HardwareSPI not having a default initialiser. i.e. it needs HardwareSPI blob(2);

   Which is fine in main etc, but inside a class definition it won't allow it to be 'initialised here'. So if you have HardwareSPI blob it complains about blob not being initialised, but if you try to initialise it ...blob(2), the compiler complains about 'you can't do that here'. (I'm C++ rusty, but I think it's because the class definition is only a definition so you can't init something that doesn't exist).

   I got round the problem by just having it global, and maybe that's why it was done that way - having several classes that operate on a hardware port may leave it in an undefined state??? You probably know more about this than I do, I'm not 100% c++ orientated.

   If you just have one logger file opened, then I see no problem with making it global and allowing classes to use it - so setup() would setup the logger files(s), then pass this file handle on initialising of the class - if you see what I mean. Either leave it open all the time and periodically flush it, or open/write/close the file each time.

   When you work out a better solution, feel free to share it.

   Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.