Freertos Database
Josephina
When I run the below code it runs to create a database and a query "create a table cars". But when query "insert" is run then fails with following error:-error no: 26(SQLITE_NOTADB) error: "file is encrypted or is not a database"
I have a requirement for a database on an embedded platform.Currently, I have looked at SQLite ( ) and MySQL
( ).Does anyone have any other suggestions?Does anyone have any comments on either of these two regarding
performance (specifically SELECT speeds and memory footprint)?Any pointers appreciated!Ciao,Peter K.--
"And he sees the vision splendid
of the sunlit plains extended
And at night the wondrous glory of the everlasting stars."
MySQL is not an embedded database IMHO, way too big. The licensing is also
very commercial since you're only really entitled to use it if for free you
are an open-source programmer.I'm using SQLite in many projects and the performance is excellent and the
memory footprint very, very small (several KBytes). There's also an
in-memory version of the database in development (or maybe already
available).
** Posted from **
If an 'in memory' database is satisfactory, take a look at my GPLd
hashlib. It is written in pure standard C, so extremely portable.
I own it, so arrangements can be made if the GPL requirement to
release your code is a problem. See: --
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]:
Try the download section.
Hmm my working gateway email server uses mySQL, originally on a sub GHz
processor and 256MB of RAM, Got upgraded to a newer nano-ATX board
1GHz and 1GB RAM. System runs Apache and email server and several other
apps, some of them using the half dozen databases.However the system is so lightly loaded, the real question on SELECT
speeds and memory footprint depends onSize and complexity of database
Number of concurrent users (access to database)
Number of SELECT requests per min/per hour...
What forms of caching are being used
etc....--
Paul Carpenter pa...@pcserviceselectronics.co.uk
PC Services
Timing Diagram Font
GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
For those web sites you hate
> Hmm my working gateway email server uses mySQL, originally on a sub GHz
> processor and 256MB of RAM, Got upgraded to a newer nano-ATX board
> 1GHz and 1GB RAM. System runs Apache and email server and several other
> apps, some of them using the half dozen databases.
> However the system is so lightly loaded, the real question on SELECT
> speeds and memory footprint depends on
>
> Size and complexity of database
> Number of concurrent users (access to database)
> Number of SELECT requests per min/per hour...
> What forms of caching are being used
> etc....
The database will be large (e.g. tables of 1,000,000 or more entries),
but not particularly complex.There weill only be one application accessing the database at a time
(or at all).Assuming only one (concurrent) connection, I wonder why the number of
select requests per time period is a factor (it clearly will be for
multiple connections).I suppose what I'm looking for is how long it takes to do:SELECT * FROM SomeTable WHERE SomeField = 'SomeValue'and SomeField is the primary key. By "how long" I mean mean, standard
deviation, and [if possible] worst case times.
This is an embedded newsgroup. How can 1Gbyte of RAM be
considered "superb"?The caveat doesn't seem like much of an endorsement. It
seems more a statement that a brick can be made to fly
if enough brute force is applied.
This will determine
how much data is moving around,
so determines how fast a storage unit (and interface),
how much needs to be buffered in memory, to keep up.
Could the serving be better served by being done from a RAM copy.
Can the processor/OS/database software keep up with the expected
number of requests.
Are the vast majority of database operations ONLY Read, and the
database updated once a day/hour/week/etc...What sort of response time is a MUST have, would be nice, or would
be great! In other words how fast *must* the data be returned.If you only make 1 request a second, there are a hell of a lot of
solutions, whereby cost of processor/RAM and size become more of the
issue in determining what software to use.If you make 10,000 requests a second, you better have a really fast
processor with lots of RAM, possibly with RAM copy (or RAMdisk) for
the database in live use. Here the software becomes more of an issue
that determines the host hardware/software.
To read a 10 byte or 10MB record? (yes some people have fields in the
SAME database that is a large picture or other document!)Standard deviation on a system doing NOTHING else?What type of system are you using to benchmark this on?The other important issue is What else is running
How much processor time available
How much storage access time available?
(i.e. does this application have near total
allocation of storage unit or is somebody
streaming video to/from the storage unit
at the same time!)There is NO simple answer to questions like this.Consider this analogyTake a deck of cardsShuffle the deck (our database)Now consider these requests
Find the 15th card down - very fast and easy to findFind a heart of any size - slower but easy.Find All the Three's - More complicatedFind the 5 of hearts - more complicatedA lot depends on how your data is organised and normalised and
many other issues, you have not given the details on.
It was pure sarcasm (its a British thing) and not meant to be taken
literally or in any way as fact. The OP had a 'requirement' for an embedded
database, but without giving any clue what that requirement was wants advice
about memory footprint. I don't know if it is to run on an 8bit device or a
dual core Pentium - hence the sarcasm.
> It was pure sarcasm (its a British thing) and not meant to be taken
> literally or in any way as fact. The OP had a 'requirement' for an embedded
> database, but without giving any clue what that requirement was wants advice
> about memory footprint. I don't know if it is to run on an 8bit device or a
> dual core Pentium - hence the sarcasm.
Richard,It came across to me that you hadn't read the question. Your
'sarcasm' comes across as something quite else.Thankfully there have been more useful, and thoughtful, responses from
others.
Apart from RAM data bases, on a virtual memory machine, the most
primitive data base would be just mapping the tables into virtual
memory and let the OS do the data loading with page faults as well as
the caching of frequently used data.
If you are only interested in accessing through the primary (and even
secondary keys) any COBOL style ISAM (Indexed Sequential Access
Method) file system should do. With current amount of memory and only
a very small (one million) amount of records, the whole key tree
could be in memory, so the SELECT time is not an issue. Retrieving the
actual data from disk will of course cost some extra. Unfortunately,
none of the popular (Windows and Unix variants) operating systems
support ISAMs at the OS level, so some drivers are required.Paul
For your purposes one advantage is that the code is very compact.
The system still gobbles memory to store the data, but that is
inherent for anything. The code is sharable, so only one code
instance can handle any number of completely independent data
tables. The code module will occupy about 1.5k when compiled for
the 80386.
> For your purposes one advantage is that the code is very compact.
> The system still gobbles memory to store the data, but that is
> inherent for anything. The code is sharable, so only one code
> instance can handle any number of completely independent data
> tables. The code module will occupy about 1.5k when compiled for
> the 80386.
Thanks. I've set myself up with a test case, and I've run MS SQL
Server (yes, not really embedded, but what the hey), MySQL and SQLite
through it.I hope to do the same now with various other potential solutions.I'll let you know how things go.Regards,
eXtremeDB/rt is the first hard-real-time database system for mission- and safety-critical real-time systems. Real-time, in this context, means that eXtremeDB/rt enforces transaction deadlines and thereby maintains temporal consistency of the data while maintaining internal consistency through the well-known ACID properties. eXtremeDB/rt is built on the foundation and solid reputation of eXtremeDB, the first in-memory embedded database system written explicitly for embedded systems, released in 2001 and now found in over 30,000,000 deployments worldwide.
eXtremeDB/rt delivers real-time capability through adaptable transaction managers that developers can choose from to match workloads. The High Priority Earliest Deadline First transaction manager is the workhorse, while the more nuanced Priority Inheritance transaction manager can be a superior choice when a mixture of non-database- and database-related tasks execute concurrently.
McObject and eXtremeDB are registered trademarks of McObject LLC. FreeRTOS is a trademark of Amazon Web Services. All other company or product names mentioned herein are trademarks or registered trademarks of their respective owners.
FreeRTOS is a real-time operating system that offers a fast, dependable, and responsive kernel. FreeRTOS is implemented in over 40 architectures, providing developers with a broad choice of hardware along with a set of prepackaged software libraries.
TTIA DB IoT for MCUs is a time series data management platform for real-time IoT data processing and management. IoT devices benefit from ITTIA DB IoT stream processing capabilities to gain rapid insights from large volumes of raw data, separate and store valuable information and act. ITTIA software development lifecycle (SDL) is conformant to the principles of IEC/ISO 62443.
c80f0f1006