[ECOS] [Fwd: MBX Board]

[ECOS] [Fwd: MBX Board]

[Jonathan Larmour]

Anyone?
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault


To : Jonathan Larmour <jlarmour at redhat dot co dot uk>
Subject : Re: MBX Board
From : "amassa at cts dot com" <amassa at cts dot com>
Date : Fri, 2 Jun 2000 11:35:05 -0700 (PDT)

Thanks for the response.

I see that there is SMC1 port support in the hal as well as with the serial
device drivers.

What is the difference between the two modules?

Should both of these be enabled in the ecos configuration to use the SMC?


I want to implement a command parser, to interpret incoming user commands
from the SMC1 port.

How can I set this up to wake up my code when a complete command comes in
from the SMC1 port?


Thanks,
Anthony


Jonathan Larmour <jlarmour@redhat.co.uk> writes:
>"amassa@cts.com" wrote:
>> 
>> Is that patch a cygwin patch?  Does that mean my other stuff won't work
>> again if I need to upgrade the cygwin1.dll?
>
>When the upgrade comes out, it will include the fix that got things
working
>for you again.
>
>> I also have a question that I didn't get answered about the MBX board. 
Last
>> time you forwarded the message to another maintainer there and he was
quite
>> helpful - I imagine because he is familiar with the MBX board.
>> 
>> My question is after I flash the gdb stub in flash memory on the MBX
board,
>> when I re-power up the board, does that stub send out any indication (a
sign
>> on message, etc.) to the serial port that it is alive - or how do I know
it
>> is operating properly.
>
>It will send out a GDB `t' packet on the serial port. If you miss it, you
>should be able to press RETURN, and it should send out another one.
>
>> Also, I didn't understand if I needed to add any options to the call of
>> powerpc-eabi-objcopy in order to reset or remove any address offsets
when
>> creating the srec file for flashing on the board.  If I could have the
exact
>> command to use that would be great.
>
>Use powerpc-eabi-objcopy -O srec --change-address=0x02040000
gdb_module.bin
>gdb_module.srec 
>
>But I think building GDB stubs produces an srec format file anyway,
doesn't
>it?
>
>Jifl
>-- 
>Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223)
728762
>"Plan to be spontaneous tomorrow."  ||  These opinions are all my own
fault

Re: [ECOS] [Fwd: MBX Board]

[Jesper Skov]

>>>>> "amassa" == "amassa@cts.com" <amassa@cts.com> writes:
amassa> I see that there is SMC1 port support in the hal as well as
amassa> with the serial device drivers.

amassa> What is the difference between the two modules?

The one in the HAL is a minimal device driver, only supporting what's
necessary to run the GDB stubs.

The serial device driver is a more complete driver, allowing different
configurations and asynchronous operation (i.e., read/write buffers
with IO being interrupt driven).

amassa> Should both of these be enabled in the ecos configuration to
amassa> use the SMC?

No, disabling the HAL driver is not normally done (but is possible)
since it handles diagnostic output and GDB communication.

But the drivers have been written to share the SMC if they are both
enabled.

amassa> I want to implement a command parser, to interpret incoming
amassa> user commands from the SMC1 port.

amassa> How can I set this up to wake up my code when a complete
amassa> command comes in from the SMC1 port?

Well, I'd probably have the parser run in its own thread and have it
call blocking read() on the device, requesting the length of a command
to be read. As soon as that amount of data has been read, the call
will return and you can do the parsing. Use semaphores to communicate
commands to worker threads.

Jesper