3

I haven't done much programming for Embedded Systems before, and now I have to create some scripts for something relatively tiny (<60MB RAM, almost all of which is already used by other more critical processes, the processor is less ~ 500MHz). I can't run something that is on all the time, so Firebird is out. I suggested sqllite, but people more familiar with the platform have told me that even that is likely to consume too much memory and processing power.

I will be programming the prototype in Perl, and will likely need to re-write the scripts I create in c for better performance later on down the road. I'd like to be able to reuse the data structures I create when I re-do it later on. Most of my experience thus far has been in MySQL, so it would be great if the syntax was simliar to that. Any suggestions?

Sorry I can't be more descriptive about the platform I'm working on.

Dan Carlson
  • 996
  • 1
  • 12
  • 18
  • 14
    *cough* thats not tiny! thats pretty generous in terms of embedded systems. – Keith Nicholas Jul 05 '10 at 22:53
  • 1
    What sort of and how much data do you need? What sort of access patterns will you have to the data? If you need really interesting queries against the data, then perhaps something like a database (others have been mentioned) might be appropriate, but if it's something that you access in a linear fashion (you load all your settings before running), then a text file might be more appropriate. I think a little more info about the problem domain is probably in order. – Michael Kohne Jul 05 '10 at 23:01
  • Keith, that just highlights my ignorance of the field; which means i need your suggestions all the more! ; - ). – Dan Carlson Jul 05 '10 at 23:30
  • Michael, that's a good point. I probably won't be doing many 'interesting' queries, but I'm not convinced yet that I my interaction with the data will be purely linear. There will be something similar to user accounts that need to be configured and saved. These accounts will each have their own configurations. Other scripts (in a somewhat real-time application) will need to read these configurations and act on them. – Dan Carlson Jul 05 '10 at 23:30
  • be careful with the term "real time". It has a specific meaning (especially in the embedded world) of a system in which a given event (a process or interrupt) is guaranteed to be handled in a certain period of time. – daotoad Jul 06 '10 at 18:58

3 Answers3

2

Berkeley DB.

Zan Lynx
  • 53,022
  • 10
  • 79
  • 131
0

as a suggestion, you may want to consider lua for scripting, its pretty fast, and can be used in production systems and very easy to bind to c.

do you need a relational database?

quite often on embedded systems you use a simple storage system, like a file based system. in general the more flexibility you want, the more overhead you will need.

  • simplest, treat entire memory as a large sequential file.
  • slightly more complicated, an allocation table to keep track of multiple files

and so on...

Perhaps a key / value store would give you the best compromise for query and storage.

Keith Nicholas
  • 43,549
  • 15
  • 93
  • 156
0

From what you describe I'd look at Berkley DB or a similar key value store.

You can also serialize your data to C structures from Perl. The traditional way to handle this is to use pack, but its a pain for more complex structures. I have found that Convert::Binary::C is great for working with data destined for C structures.

You can feed CBC a struct declaration and configure it to handle your compiler's endianness, int size and so forth. You can also provide code to execute when packing or unpacking a value. For example if you have a typedef for a fixed point number, you can configure CBC to unpack it into a float in Perl, and then convert back to fixed point when the number is packed.

I have had great success using this tool to work with memory dumps and to prepare images for deployment to embedded systems.

daotoad
  • 26,689
  • 7
  • 59
  • 100