If sorted out the problems I was encountering with lseek, so it's no longer
an issue.

I'm no longer inclined to model the data manager as a straight device
(CDev) since there are unresolvable issues with using a sd card file within
a device. Specifically in the case of close, the i_node list is locked when
I attempt to close the sd card file (which tries again to lock the i-node
list).

I've re-implemented the same algorithm as simple procedure calls that turn
out to be also more straightforward to use.

__EXPORT void        dm_initialize(void);
__EXPORT int        dm_open(void);
__EXPORT void        dm_close(int fd);
__EXPORT ssize_t    dm_read(int fd, unsigned char item, unsigned char
index, char *buffer, size_t buflen);
__EXPORT ssize_t    dm_write(int fd, unsigned char item, unsigned char
index, unsigned char persistence, const char *buffer, size_t buflen);
__EXPORT int        dm_restart(unsigned char restart_type);

At some point after a reset, the algorithm needs to be told to clean up
volatile entries depending on the type of reset. This determination is done
in px4io.cpp for fmu+io combos. An equivalent needs to exist in fmu.cpp for
those just running fmu, even if it does not support in-flight reset.


On Thu, Oct 10, 2013 at 1:58 PM, Lorenz Meier <notifications@github.com>wrote:

> In src/drivers/px4fmu/fmu.cpp:
>
> > @@ -260,6 +261,18 @@ class PX4FMU : public device::CDev
> >  	/* reset GPIOs */
> >  	gpio_reset();
> >
> > +	/* Start the data manager */
>
> Why is the data manager accessed in the FMU low level board driver?
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/PX4/Firmware/pull/452/files#r6894677>
> .
>