[ECOS] communications channel concepts

[ECOS] communications channel concepts

[Fabrice Gautier]

Hi,

I'm still confused about the communication channel concept in eCos.
What I'm saying is based on what I've seen on the 1.3.1 release and
particulary in the i386 platform.

For example I think there is a confusion between the diag channel and the
gdb channel.
And for what I've seen in the code, the gdb debug channel is always com1 and
38400 bauds (except if you hack the stub).

But either the diag channel is com1 or com2, there is still an
initialization of the com port. When the diag channel is the same as the gdb
channel we shouldn't need this. And it don't understand very well how the
gdb stub and the diag channel send and receive chars. It would be logical to
have a read function for the stub and a read function for the diag channel,
and maybe when the channel is the same one would call the other but in the
current code i can't see a clear distinction between waht belong to the
stub, and what belong to the diagnostic stuff.

It seems that the last cvs update bring a lot of new stuff, Redboot and all,
Is there any stuff adressing this problems ?
I've seen that RedBoot only use ethernet for the moment. What shoudl be the
amount of work to have serial support for Redboot? What kind of driver does
redboot would use? the common eCos serial driver or a special serial driver
(like this is the case currently for the gdb stubs) 

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

Re: [ECOS] communications channel concepts

[Jonathan Larmour]

Fabrice Gautier wrote:
> 
> Hi,
> 
> I'm still confused about the communication channel concept in eCos.
> What I'm saying is based on what I've seen on the 1.3.1 release and
> particulary in the i386 platform.

The i386 platform is not a good example unfortunately. No-one is currently
keeping it up-to-date.

> For example I think there is a confusion between the diag channel and the
> gdb channel.
> And for what I've seen in the code, the gdb debug channel is always com1 and
> 38400 bauds (except if you hack the stub).

That is a failing fairly specific to the i386 pc target.

> But either the diag channel is com1 or com2, there is still an
> initialization of the com port. When the diag channel is the same as the gdb
> channel we shouldn't need this.

There is rarely any harm in reinitializing it - it's not like it could
possibly work if you tried to use different baud rates on the same port
anyway, so the settings must be the same.

> And it don't understand very well how the
> gdb stub and the diag channel send and receive chars. It would be logical to
> have a read function for the stub and a read function for the diag channel,
> and maybe when the channel is the same one would call the other but in the
> current code i can't see a clear distinction between waht belong to the
> stub, and what belong to the diagnostic stuff.
> 
> It seems that the last cvs update bring a lot of new stuff, Redboot and all,
> Is there any stuff adressing this problems ?

Yes, but not for the i386-pc target. We now use a system called virtual
vectors which rationalizes the stub and diag output, and allows better
interworking between a ROM stub and a running program.

Look at the ARM PID target in CVS. It has a good example of how it works
because it (like the PC) has two serial ports.

> I've seen that RedBoot only use ethernet for the moment.

No, it uses serial as well. 

> What shoudl be the
> amount of work to have serial support for Redboot? What kind of driver does
> redboot would use? the common eCos serial driver or a special serial driver
> (like this is the case currently for the gdb stubs)

The i386 pc target would need to be converted to use virtual vectors for
the diag routines. There would need to be some extra work involved to port
RedBoot as well. It doesn't use a special serial driver.

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