Re: [SLUG] Looking for embedded processor help

From: Ian C. Blenke (icblenke@nks.net)
Date: Fri Sep 23 2005 - 11:56:29 EDT


Pete S. wrote:
> Hello Folks,
>
> Friend of mine who is looking for some insite wrote "Processor will
> have a 512K Non-volitile RAM that I need to always keep loaded with
> the current state of the application. My state is about 400K in size
> and updates about every 100 msec. On the 186/386 with no OS I simply
> allocated my current status registers to the memory location of the
> NVRAM at compile time. The problem I have with Linux is that with the
> virtual address space, the application CAN NOT access a physical
> address. I have attempted to create a JFFS RAM drive on the NVRAM and
> simply open, write status and close a file in this RAM space but
> updates going through the OS was way to slow. I really need to have a
> way for the application to directly use this memory without going
> through the OS. My last idea, which I have no idea how to do, would be
> to write my entire application as a device driver, and thus would have
> unlimited access to all physical addresses, but then again things
> would get ugly if the program went rogue. Any ideas???"
Updating NVRAM, 10 times a second... you would want something like JFFS
to keep the writes from writing the same page too often. Flash NVRAM
memory does have a finite number of write cycles.

"A flash memory does not work like an ordinary block device; it is not
possible to write twice to the same memory location without first
performing a very time-expensive erase. An erase must be done on whole
sector at a time and a common sector size is 64kb"

As such, I think he's a bit confused about accessing the same "location"
over and over again. it just isn't going to work like he thinks it will.

If he needs to access a physical address, he will need to play in kernel
space. User space isn't going to hack it otherwise.

"Every 100 msec" is 10 times a second. Flash can be slow, very slow if
you're erasing pages between each write.

What I would recommend for his application would be a "live" state in
RAM, followed closely by a "transaction log" of changes over time to
flash to keep the state. If power is lost at any point, you've lost only
the most recent state not committed as a transaction. This is
effectively what JFFS is doing underneath. The directory structure is
kept in RAM, and write commits are applied to a transactional log (JFFS
doesn't use the buffer cache).

Hope this helps.

 - Ian C. Blenke <icblenke@nks.net>

-----------------------------------------------------------------------
This list is provided as an unmoderated internet service by Networked
Knowledge Systems (NKS). Views and opinions expressed in messages
posted are those of the author and do not necessarily reflect the
official policy or position of NKS or any of its employees.



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 17:13:21 EDT