On Fri, 2 Mar 2018 19:46:17 +0000
"Obrien, John J" <jobri...@gatech.edu> escribió:

> Hello,
> 
> 
> My team is working on a project that involves transmitting sensor data from a 
> data logger module to a mobile application via Bluetooth. I am interested in 
> finding a relatively fast, reliable way to store the data that was collected 
> by the data logger. Since we aren't guaranteed to always have a reliable 
> Bluetooth connection between the mobile app and the data logger, we will need 
> a way to mark which records are synchronized with the mobile application and 
> which still haven't been sent up, so that the data logger can continue to 
> collect data even when the mobile application is out of range. We collect 
> data continuously at 4Hz, so I anticipate that we will have far too much data 
> to use a flat file and manually traverse each record prior whenever the 
> mobile application requests data.
> 
> 
> I am very new to embedded programming (almost no prior experience) but have 
> prior mobile application development experience. My first thought is to store 
> the data in a SQLite database table and include one column called 
> "IsSynchronized" that can store a boolean value to indicate which datapoints 
> have been synced. When the mobile application requests data, the records 
> where "IsSynchronized == false" will be transmitted to the mobile app. Once 
> successful, the mobile app will let the data logger know that the 
> transmission succeeded and set the IsSynchronized column to true for each 
> synchronized record. This is how I would do it if the data were traveling 
> from a mobile app to a server, but I don't know if this is a good idea for an 
> embedded database to a mobile application.
> 
> 
> Our data logger uses an Atmel-SAM4S microprocessor. We have 8GB of flash 
> memory, so storage isn't an issue. Our RAM is very limited; we only have 
> 160KB. We are working with an external vendor to design the data logger. They 
> have developed an custom, handrolled operating system, but since it contains 
> no Virtual File System, we aren't sure if SQLite will be an option for us. 
> I've heard of other folks using uClinux or other Unix based Operating Systems 
> on the SAM4S to accommodate SQLite 
> (http://sqlite.1065341.n5.nabble.com/VFS-for-an-MCU-internal-flash-td83079.html),
>  but I don't know how practical this is.
> 
> 
> My question is this:
> 
>   1.  First, am I on the wrong track by pursuing an embedded database to 
> solve my data synchronization issue?
>   2.  Are there other embedded database alternatives that might make more 
> sense in my scenario. I've heard a lot about NoSQL DBs like BerkleyDB and 
> UnQlite, but I don't know is they are practical for my case either.
>   3.  If we do need to implement a VFS, does it make sense to use a 
> unix-based embedded operating system? If so, are there any recommendations as 
> to which one may be a good fit for my hardware
>   4.  Last, are we wasting our time with the SAM4S processor to solve this 
> problem? We would like to take advantage of existing code, the nice 
> power-consumption characteristics of the SAM4S, and would rather not have to 
> go through the time and expense of upgrading our processor, but, if our 
> processor choice is a non-starter, it would be good to know sooner rather 
> than later.
> 
> To summarize, my question is regarding what direction I should ask the 
> hardware vendor to take. Does it make sense for them to spend time optimizing 
> the SAM4S for SQLite or should we consider another approach?
> 


For the first, yes, but.... should it be a 'real' db? If your queries to your
data structure (a table in sql) will be for '=' only and not for '>' '<' or
other more complex, a simple data structure (list, double queue,.. whatever)
will be faster and lighter.

For the second, I use sqlite, naked from every cloth I don't need and added via
virtualtables or functions the ones I want. UnQlite derives from Sqlite (there
were 2 projects with the same name), BerkleyDB is easy to use but
bigger/heavier than sqlite.

For the third, I used contiki-os for embedded (10 years ago or more) with
sqlite. Check it. If you need something more linux like, some friends use
zephyr, but don't know what processors support.

FOr the fourth, depends on what are you trying to solve. If you only want to
send data in IoT, I'll use contiki without anything, a double queue (or list),
one for not synch and other for synch data, moving from the first to the second
a struct will make the work. Don't think big in embedded world



-- 
Eduardo <eduardo.mor...@mobelservices.com>
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to