Unoffical empeg BBS

Quick Links: Empeg FAQ | RioCar.Org | Hijack | BigDisk Builder | jEmplode | emphatic
Repairs: Repairs

Topic Options
#262825 - 15/08/2005 22:31 Need implementation tips
Andre81
new poster

Registered: 13/08/2005
Posts: 28
Loc: Germany
I have written an Win32 and Pocket PC (WinCE) application for a standalone engine control unit (ECU) from Apex'i.

Here is a Screenshot.

Normally the ECU is programmed with a handheld commander.

Most of the app is written in ANSI C and compiles with gcc under Linux. It runs on little endian as well as on big endian CPUs.

When i've read the first time about the empeg i thought it would be cool to program and monitor the ECU with the car stereo. That's the reason why i've bought the empeg.

But i don't know yet how i integrate it into the player and I have some questions about the ARM cpu.

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?

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.

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?

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.

Thanks
Andre

Top
#262826 - 16/08/2005 07:24 Re: Need implementation tips [Re: Andre81]
bonzi
pooh-bah

Registered: 13/09/1999
Posts: 2401
Loc: Croatia
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.

I would dedicate a partition (or perhaps even second disk) to this.

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?

Gah, I am getting senile... I think that you need to replace stock init program, but yes, it is definitively possible.
_________________________
Dragi "Bonzi" Raos Q#5196 MkII #080000376, 18GB green MkIIa #040103247, 60GB blue

Top
#262827 - 16/08/2005 11:32 Re: Need implementation tips [Re: bonzi]
frog51
pooh-bah

Registered: 09/08/2000
Posts: 2091
Loc: Edinburgh, Scotland
judging by emphatic etc, you can definitely do this from hijack - need to look at how screen and keypress control is handled though
_________________________
Rory
MkIIa, blue lit buttons, memory upgrade, 1Tb in Subaru Forester STi
MkII, 240Gb in Mark Lord dock
MkII, 80Gb SSD in dock

Top
#262828 - 16/08/2005 13:30 Re: Need implementation tips [Re: Andre81]
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
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.
_________________________
- Tony C
my empeg stuff

Top
#262829 - 16/08/2005 14:37 Re: Need implementation tips [Re: tonyc]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
Quote:
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.

This is true, but "getting it right" is a slippery term: if you know what the C standard guarantees and what it doesn't, you'll be fine, but if you assume that anything which works on x86, also works on ARM, you'll be in great trouble. For instance, the following C exhibits undefined behaviour and does not work on ARM:

Code:
struct foo_t {
short s;
int x;
} __attribute__ ((packed));

int f(struct foo_t *ft)
{
int *p = &(ft->x);
return *p;
}


The assignment to p of an unaligned pointer is undefined, and f will give the wrong answer. If you remove the __attribute__((packed)) then you get valid and working C, but then sizeof(struct foo_t) will be 8, not the 6 one might otherwise expect.

Peter

Top
#262830 - 16/08/2005 14:53 Re: Need implementation tips [Re: peter]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
Quote:
not the 6 one might otherwise expect.

And if you need sizeof(struct foo_t) to be 6, this is the only way to write a working f():
Code:
int f(struct foo_t *ft)
{
int i;
memcpy(&i, &(ft->x), sizeof(int));
return i;
}



Peter

Top
#262831 - 16/08/2005 14:59 Re: Need implementation tips [Re: peter]
wfaulk
carpal tunnel

Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
Are pointers guaranteed to be of int size?
_________________________
Bitt Faulk

Top
#262832 - 16/08/2005 15:21 Re: Need implementation tips [Re: wfaulk]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
Quote:
Are pointers guaranteed to be of int size?

No. They happen to be so on ARM, but on alpha-linux, for instance, pointers are 64-bit and ints are 32-bit. (Sparc64 too?) But those snippets don't assume anything about the size of pointers.

Peter

Top
#262833 - 16/08/2005 15:31 Re: Need implementation tips [Re: peter]
wfaulk
carpal tunnel

Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
Quote:
But those snippets don't assume anything about the size of pointers.

Oh, you're right. I misread them.
_________________________
Bitt Faulk

Top
#262834 - 16/08/2005 15:32 Re: Need implementation tips [Re: wfaulk]
Andre81
new poster

Registered: 13/08/2005
Posts: 28
Loc: Germany
In Antwort auf:
Are pointers guaranteed to be of int size?




Win32 uses ILP32, Win64 LLP64 and 64-bit Unix systems LP64. Not sure about the empeg but i guess it's ILP32.

Top
#262835 - 16/08/2005 15:47 Re: Need implementation tips [Re: Andre81]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
Quote:
[Win32 uses ILP32, Win64 LLP64 and 64-bit Unix systems LP64. Not sure about the empeg but i guess it's ILP32.

The Empeg is ILP32 (as are all ARM26/ARM32 systems). All 64-bit Linux ports are LP64, but IIRC there was at least one OS for Alpha that was ILP64 (Ultrix? VMS?). Pure P64, like Win64, is nasty because there's no ISO C90 type that can contain a size_t: you have to use the C9x type "long long". Technically such systems are not ISO C90 compliant.

Peter

Top
#262836 - 16/08/2005 15:55 Re: Need implementation tips [Re: peter]
wfaulk
carpal tunnel

Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
Quote:
IIRC there was at least one OS for Alpha that was ILP64 (Ultrix? VMS?)

Ultrix, AFAIK, was never available for Alpha. It ended with DEC's use of MIPS. Their Alpha Unix was named OSF/1, Digital UNIX, and Tru64. Digital UNIX was the 32/64 hybrid period.
_________________________
Bitt Faulk

Top