Quote:
The data in the ECU and the communication packets are byte-aligned, therefore i've used a pragma to byte-align the structs (only 8 and 16 bit members). Could this cause any problems with gcc and the ARM cpu?
Not if you're doing it right, generally *not* byte-aligning things is what causes problems.
Quote:
I would like to log the data from the ECU on the harddisk. I guess it would not be the best idea to write it immediately to the HD. How much memory can i allocate for a buffer? I need about 500 bytes per second. And when and where should i write the data? I don't want to mount the music partition with read/write access.
How much memory is available depends on a few things, the most obvious being how much your player has. Then there's the footprint of the program itself, and then the player's cache memory, which you can tune with the ReserveCache parameter in config.ini. At 500 bytes/second, I'd go ahead and allocate a 32K buffer and write it to disk once a minute.
Quote:
Also once started the app should log the data automatically in the background. Is it possible to run the player app and an own app at the same time?
Yes, but it depends on what you mean by "in the background." Which is somewhat elucidated by your next questions...
Quote:
I want a new menu item in the Hijack menu and if the user selects the item i want my own menu to pop up. Can Hijack send a signal to my process to notify it to take over the display?
And last but not least, how do i get the events if the user presses a button? I guess this has been discussed many times but i can't find it in the FAQ or forum.
Both of these things are possible, though technically, Hijack isn't sending a signal; you just tell the app to wait to be selected from the menu.
Actually, there is (or was) a sample code fragment in hijack.h which shows you how to do these things. If that's not enough, you can take a look at the source for my apps (link in my signature) particularly emphatic, which does some of the more "cutesy" stuff.
Previous Topic
Index
