From sailors3 at comcast.net  Fri Apr  1 09:05:26 2005
From: sailors3 at comcast.net (David Eicher)
Date: Fri, 1 Apr 2005 07:05:26 -0800
Subject: [Efi332] XFI555 status
In-Reply-To: <410-22005354145412700@earthlink.net>
Message-ID: <mailman.3.1311919742.4788.efi332@diy-efi.org>

Hello list:

The EABI API is compiling and assembling without errors now using the GNU C
toolset (target = PHYTEC MPC555). I have a small test program written that
toggles LEDs on/off and responds to commands from QSCI and outputs to QSCI.
I'm working my way through linker errors now. The GNU linker doesn't like
line 38 (shown below with ERROR HERE). There is no command defined in the
GNU documentation for LOAD(  ), doesn't anyone know what the author intended
to do using this load command? I took this linker script from the CME-555
Diab demo library. Any Diab experts out there? 

It seems like the intent is to cause the linker to place the .data section
at the address of __DATA_ROM but I've not been able to find a GNU equivalent
that will be accepted.

Thanks for any insight you might be able to offer,

Dave


SECTIONS
{
	/* The first GROUP contains code and constant data. */
	GROUP : {
		.reset : {}
		.text (TEXT)	: {
			*(.text)
			*(.rdata)
			*(.rodata)
			*(.frame_info)
			*(.init)
			*(.fini)
			*(.eini)
		}
		/* .eirtable ALIGN(2048) : {} */
		.sdata2 (TEXT)	: {}   /* small CONST area */

	/* The second GROUP allocates space for initialized data and
uninitialized data. */
		
	GROUP : {
		__DATA_ROM	= .;
		__DATA_RAM	= .;
		.data  (DATA) LOAD(__DATA_ROM) : {}		<-ERROR HERE
		.sdata (DATA) LOAD(__DATA_ROM+SIZEOF(.data)) : {}
		__DATA_END	= .;




From sailors3 at comcast.net  Sun Apr  3 09:20:56 2005
From: sailors3 at comcast.net (David Eicher)
Date: Sun, 3 Apr 2005 07:20:56 -0700
Subject: [Efi332] XFI555 GNU C Questions
Message-ID: <mailman.4.1311919742.4788.efi332@diy-efi.org>

Hello list:

I ultimately ended up deleting those "LOAD(  )" commands in the linker
script, I couldn't find any mention of such a command in the GNU
documentation. I believe the .data section will be placed correctly just
because of the relocation counter. Then I added a statement:

. = . + SIZEOF(.data);

To move the relocation counter to the correct place to locate the .sdata
section right after .data. I assume that is all working but have not been
able to confirm yet because of other problems.

Everything in the EABI API quickstart package is compiling and assembling
without errors now. Then the linker runs I get the following:

Powerpc-elf-ld -melf32ppc -Tdebug.dld -Map=main.map -nostartfiles -o
main.elf <includes (all .o files> > main.map 
Signal 11
Make: *** [main.elf] Error 139

After the makefile ends this way, I check the main.elf and main.map files
and they are empty. So, I'm not getting any output from the linker. It
appears to me the linker is terminating without completing because of an
error (Signal 11), and then make quits because the linker ended with errors.
But, I can't find any documentation on GNU that tells me what these errors
mean and I don't have a clue what to change to deal with them. 

I did tinker a bit with the command line options, after performing a make
clean followed by a make (to get a fresh build), the errors above stopped
happening. But I the main.map file is still empty, and main.elf is never
generated. So..., I feel like I'm close to having a working solution but
stumped at the moment on this issue.

Any ideas?

Thanks for any help you might be able to offer.

Dave



-----Original Message-----
From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
Behalf Of David Eicher
Sent: Friday, April 01, 2005 7:05 AM
To: 'A list for people building efi332systems.'
Subject: [Efi332] XFI555 status

Hello list:

The EABI API is compiling and assembling without errors now using the GNU C
toolset (target = PHYTEC MPC555). I have a small test program written that
toggles LEDs on/off and responds to commands from QSCI and outputs to QSCI.
I'm working my way through linker errors now. The GNU linker doesn't like
line 38 (shown below with ERROR HERE). There is no command defined in the
GNU documentation for LOAD(  ), doesn't anyone know what the author intended
to do using this load command? I took this linker script from the CME-555
Diab demo library. Any Diab experts out there? 

It seems like the intent is to cause the linker to place the .data section
at the address of __DATA_ROM but I've not been able to find a GNU equivalent
that will be accepted.

Thanks for any insight you might be able to offer,

Dave


SECTIONS
{
	/* The first GROUP contains code and constant data. */
	GROUP : {
		.reset : {}
		.text (TEXT)	: {
			*(.text)
			*(.rdata)
			*(.rodata)
			*(.frame_info)
			*(.init)
			*(.fini)
			*(.eini)
		}
		/* .eirtable ALIGN(2048) : {} */
		.sdata2 (TEXT)	: {}   /* small CONST area */

	/* The second GROUP allocates space for initialized data and
uninitialized data. */
		
	GROUP : {
		__DATA_ROM	= .;
		__DATA_RAM	= .;
		.data  (DATA) LOAD(__DATA_ROM) : {}		<-ERROR HERE
		.sdata (DATA) LOAD(__DATA_ROM+SIZEOF(.data)) : {}
		__DATA_END	= .;


_______________________________________________
Efi332 mailing list
Efi332 at diy-efi.org
http://lists.diy-efi.org/mailman/listinfo/efi332



From sailors3 at comcast.net  Wed Apr  6 21:29:27 2005
From: sailors3 at comcast.net (David Eicher)
Date: Wed, 6 Apr 2005 19:29:27 -0700
Subject: [Efi332] XFI555 build
In-Reply-To: <20050405055217.GA18510@mailhub.intra>
Message-ID: <mailman.5.1311919742.4788.efi332@diy-efi.org>

Hello list,

Well, after long last, and lot's of help from Gunter, Jeff, and Andrei, I am
at least able to complete the build of a test program using the quickstart
package from Motorola. 

I am now trying to debug it, I will have to tinker with the OCD Commander to
get the BDM to work right, my first attempt seemed to accept the download of
the elf file, but the "go" command and the "step" command both failed to
respond.

But.., I AM making progress, thanks for all your help!

Dave


-----Original Message-----
From: Gunter Magin [mailto:gm at ib-magin.de] 
Sent: Monday, April 04, 2005 9:52 PM
To: David Eicher
Cc: 'Gunter Magin'; BowTieVette at aol.com
Subject: Re: New Info: [Efi332] GNU errors

Hi David,

On Mon, Apr 04, 2005 at 08:42:06PM -0700, David Eicher wrote:
> So..., it is linking now without that crash, I just have to fix some
> unresolved addresses and such and I should have a successful build.

That sounds good. 

Next thing is to download and debug that beast. If you have a decent BDM
debugger, it is a nice job to check block by block, module by module if
the SW does what you have envisioned.

Seeing a "hello world" over the serial line is usally a big milestone.

> How did you know what to change?

10+ years experience with GNU in cross environments... 

> What type of project are you working on? Fuel injection? Some kind of car
> EFI?

These are commercial projects. Basically test stand measurment
and stimulus devices for engine reseach of a big car manufacturer.
Think of it like this: Some engineer comes up with a smart idea how
to improve combustion, or what else, and lots of people contribute
to build this particular engine prototype. Sometimes, I get called to
provide the intelligent IO controller. However, the real thing happens
in the matlab/simulink framework in big fat computer racks.  They just
cannot disclose what they are really doing, and therefore I have no idea.
So it may well be that I have already controlled fuel injectors, however
without knowing... :)

gm



From sailors3 at comcast.net  Fri Apr 15 08:38:18 2005
From: sailors3 at comcast.net (David Eicher)
Date: Fri, 15 Apr 2005 06:38:18 -0700
Subject: [Efi332] cMOS
Message-ID: <mailman.6.1311919742.4788.efi332@diy-efi.org>

Hello list,

I'm told some folks are using cMOS for MPC555 based applications. Can anyone
articulate some of the major benefits of using an OS (assume this is
real-time OS) as opposed to a simple control loop and some interrupts?

Thanks,

Dave




From agchichak at compusmart.ab.ca  Fri Apr 15 13:28:02 2005
From: agchichak at compusmart.ab.ca (Andrei Chichak)
Date: Fri, 15 Apr 2005 12:28:02 -0600
Subject: [Efi332] cMOS
Message-ID: <5.2.1.1.0.20050415122717.02708a78@mail.compusmart.ab.ca>

At 07:38 AM 4/15/2005, you wrote:
>Hello list,
>
>I'm told some folks are using cMOS for MPC555 based applications.

Umm, do you mean uC/OS? CMOS is a complimentary metal oxide semiconductor, 
uC/OS is an RTOS (real time operating system).

>Can anyone
>articulate some of the major benefits of using an OS (assume this is
>real-time OS) as opposed to a simple control loop and some interrupts?

(SET RandomRamblings 1)

Can you walk? Can you chew gum? Can you sing "Psycho Killer"? How about 
juggle? Now do them all at the same time. How about if you had four people 
and a cart, a hot dog vendor pushing the cart and on the cart you had a 
teenage girl, David Byrne, and one of the Brothers Karamazov? Same result? 
 From a black box point of view, yes.

Okay, using four people is actually a case of multi-processing. If you 
could push the cart for a second, stop, chew gum, stop, sing a couple of 
words, stop, and juggle for a second, then start all over again, that would 
be easier, but if the juggling pins are in mid air, that would be a 
problem, but with enough coordination and speed we could learn. Now your 
agent says that for your next gig you have to tap-dance at the same time.

I have found that, in a non-rigorously defined development project, using 
an RTOS saves your butt so often that it is a very small price to pay for 
the flexibility it affords.

(what the hell am I talking about?)

Here's the scoop, if you had a project where all of the design has been 
figured out down to the last state machine transition and going from an 8K 
memory footprint to 16K would mean changing processors or including a 
memory chip which would make your project too big, too expensive, or too 
slow, then you craft a program that does the absolute minimum.

But if someone then says, "hey let's put in a data logging feature", or 
"hey I want a serial port LCD screen", then you have to figure out where to 
shoehorn in the extra functionality so it doesn't affect your finely tuned 
timing. You quit and go on to the next job.

Running an RTOS might take more space, time, and money  than a simple event 
loop and it is almost impossible to convince someone to use an RTOS if they 
have never used one, until they do a project that NEEDED one. By then a lot 
of people have ended up writing their own and they are typically less 
flexible, poorly documented, and are less space, time, and money efficient.

The structure of a process within an RTOS is a simple infinite loop that 
does some work and goes to sleep until the next scan is required. The RTOS 
takes care of what to do when the system is not busy doing something else, 
like passing messages back and forth or running another process that does 
data logging or a serial communications remote control interpreter. 
Meanwhile, the simple infinite loop just keeps on looping and sleeping, 
completely oblivious to the other task gyrations.

The interrupts are still used and are at the core of the task switching 
system. The RTOS does some very clever gymnastics that make it look like 
only one process is running. Then when the task timer interrupt fires, the 
running process is put on hold, the process with the highest priority that 
is ready to run has its stack pointer and registers restored and a return 
from interrupt is executed. The second process continues like it never 
stopped. UNIX does this, windows does this, your Linksys router does this, 
your iPod does this.

Since the RTOS takes care of the sleeping and waking of processes, you 
don't have to write that part. Since you can have more than one 
simultaneous process, they can be simpler than if they were combined in a 
"simple" control loop.

It is like having the TPU to take care of the timing stuff while the CPU 
takes care of the high level control stuff. You could do the timing stuff 
in the CPU and just send out pulses on parallel port bits.

In the case of an engine management system, I would have one process to 
take care of the ignition system, one to take care of the injection system, 
a monitor process to grab the values off of the ADCs periodically and make 
them available to the rest of the system, one to act as an error logger, 
one as a serial comm interpreter, one to act as a human interface 
controller, and the main process to watch the other processes and reset the 
system if any of them quits working properly. To wrestle all of these 
activities into a single monolithic program is doable, people do it every 
day, but I have had to debug someone else's monolith and I wouldn't wish it 
on anyone.

The system that I developed for work runs on a 16MHz 68332, has 11 
processes, 33 channels of ADC, just about uses up all of the TPU channels, 
and typically runs at about 22% of the CPU's capacity. The high priority 
processes are very time constant, you could set a clock by them, and the 
low priority processes have very little time wobble. Our other processors 
do not use an RTOS, their function is small and very specific, they are 
required to run without external memory, and their timing is required to be 
"as fast as possible". We count calculation loop cycles on these machines.

RTOS's should not be applied to all projects and processors, and the same 
is true for monolithic control loops. The more you know about how a system 
works, the less you need an RTOS. If you expect the system to evolve, the 
more an RTOS makes sense.

The best thing about uC/OS is the price. For hobby stuff, it's free. For 
commercial purposes, it's cheap. The full source code is published in a 
book. It is robust and is not feature poor. The author is actively working 
on extensions, but is not altering the interfaces. The user community is 
porting it to a raft of processors (from the micro to the mega) and 
compilers (from the free to the $$$$$$$$$). Did I mention it is cheap.

How that?

Andrei

>Thanks,
>
>Dave


------------------------------
Andrei Chichak

4024-120 Street                         (780)434-6266
Edmonton, Alberta                       agchichak at compusmart.ab.ca
Canada
T6J 1X8

Lat: 53? 28' 40" N
Lon: 113? 32' 27" W  



From sailors3 at comcast.net  Sat Apr 16 10:18:43 2005
From: sailors3 at comcast.net (David Eicher)
Date: Sat, 16 Apr 2005 08:18:43 -0700
Subject: [Efi332] Loading address in register on MPC555
Message-ID: <mailman.7.1311919742.4788.efi332@diy-efi.org>

Hello list,

 

I'm still having trouble properly loading the address of a linker generated
symbol into a register (r1) in the 555. This is a GNU C environment. My code
so far looks like this:

 

                        UWord32 tmp;

 

                        tmp = &(__SP_INIT);

                        asm ("lis                       r1,%0" : : "g" ((tmp
>> 16) & 0xFFFF));   /* __SP_INIT is generated by linker */

                        asm ("ori                       r1, r1,%0" : : "g"
((tmp) & 0xFFFF));

 

I'm trying to load the "address of" __SP_INIT which is the top of the stack
into register GPR1 (or r1).  But this code doesn't get it done, I'm not sure
what I'm doing wrong. The seems to be some little sutle point I'm missing.

 

Thanks for any insight you might be able to offer,

 

Dave

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050416/5ba269e8/attachment.html 

From Steve.Ravet at arm.com  Fri Apr 22 14:36:59 2005
From: Steve.Ravet at arm.com (Steve Ravet)
Date: Fri, 22 Apr 2005 14:36:59 -0500
Subject: [Efi332] test
Message-ID: <DBB2E4C4173F1749B6C74341406117831D8646@NASDAQ.usa.Arm.com>

Had to some archive maintenance so the lists were shut off briefly...
Checking to make sure everything is OK.

--steve

--
Steve Ravet
steve.ravet at arm.com
ARM,Inc.
www.arm.com