Re: [ECOS] TCP/IP Stack for eCos

Re: [ECOS] TCP/IP Stack for eCos

[Jay Lepreau]

	> It probably would take very little effort to get the OSKit's TCP/IP
	> stack working in eCos, [...]

	Do you know if it's a zero copy stack?

Yes, I believe it is but can't swear to it.  It's FreeBSD's
implementation with our wrapping code and environment.

Aside:
In Sec 5 of the SOSP paper on our site there's a discussion of a
networking example (ttcp) which might be enlightening in a general
way.  In that particular example an extra copy is incurred on the
outgoing path because BSD's scatter/gather `mbufs' in the protocol
component have to be copied into linear `skbuffs' in the (unchanged)
Linux driver component.  That is an artifact of the mismatch and would
not apply if you allowed yourself to change the Linux drivers or
provided other drivers.  (For maintenance and philosophical reasons,
we generally avoid changing foreign "encapsulated" code in the OSKit.)

Re: [ECOS] TCP/IP Stack for eCos

[Fred Fierling]

Jay Lepreau wrote:

>         > It probably would take very little effort to get the OSKit's TCP/IP
>         > stack working in eCos, [...]

I assume it's written in C?

It occurs to me that since eCos is written in C++ that it may be
an idea to write its TCP/IP stack in C++ as well.  Thoughts?

Re: [ECOS] TCP/IP Stack for eCos

[Brendan Simon]

It depends who is going to maintain the networking stack.  It probably makes sense
to maintain some C++ wrapper classes to an existing and maintained IP stack (eg.
FreeBSD, Linux, etc).

Brendan Simon.


Fred Fierling wrote:

> Jay Lepreau wrote:
>
> >         > It probably would take very little effort to get the OSKit's TCP/IP
> >         > stack working in eCos, [...]
>
> I assume it's written in C?
>
> It occurs to me that since eCos is written in C++ that it may be
> an idea to write its TCP/IP stack in C++ as well.  Thoughts?

[ECOS] Re: TCP/IP Stack for eCos

[Bart Veer]

>>>>> "Fred" == Fred Fierling <fff@microplex.com> writes:

    >> > It probably would take very little effort to get the OSKit's TCP/IP
    >> > stack working in eCos, [...]

    Fred> I assume it's written in C?

    Fred> It occurs to me that since eCos is written in C++ that it
    Fred> may be an idea to write its TCP/IP stack in C++ as well.
    Fred> Thoughts?

If somebody were to write a completely new TCP/IP stack for eCos then
C++ would be a reasonable choice of language - or rather a subset of
the language, some parts such as exception handling involve rather
major code size overheads which are usually unacceptable in embedded
systems. In practice I am not sure there is much justification for
writing yet another TCP/IP stack, there are plenty of them out there
already.

Bart Veer // eCos net maintainer

Re: [ECOS] TCP/IP Stack for eCos

[Fernando D. Mato Mira]

At 05:06 PM 5/4/99 -0700, you wrote: 
>Jay Lepreau wrote: 
> 
>> > It probably would take very little effort to get the OSKit's TCP/IP 
>> > stack working in eCos, [...] 
> 
>I assume it's written in C? 
> 
>It occurs to me that since eCos is written in C++ that it may be 
>an idea to write its TCP/IP stack in C++ as well. Thoughts?

No. Even if there was egcs support for Analog Devices and TI 
DSPs at least, egcs is not like Green Hills EC++ where you 
can span the continuum between EC++ and C++ by switching 
on/off features.
Most of our projects run on raw hardware because a kernel 
is not needed, even if there're multiple tasks running (eg: network, 
infrared in/out, audio in/out, video in, keyboard, display, `stuff').




Fernando D. Mato Mira                                                        
Real-Time SW Engineering & Networking
Advanced Systems Engineering Division                                                               
CSEM - Centre Suisse d'Electronique et de Microtechnique 
Jaquet-Droz 1                                                                    Email:   matomira AT acm DOT org
CH-2007 Neuchatel                                                            Phone:    +41 (32) 720-5157
Switzerland                                                                       FAX:        +41 (32) 720-5720

http://www.csem.ch/         http://www.vrai.com/          http://ligwww.epfl.ch/matomira.html

[ECOS] Connecting gdb to AEB

[Andreas.Karlsson]

Hi!

While following the "Getting Started with eCos" you shall connect to the
board using these gdb commands. 

(gdb) set remotebaud 38400 
(gdb) set mips-force-32bit-saved-gpregs 
(gdb) target remote COM1


This set mips.. command, should I replace it?
Entering the command I get:
(gdb) set mips-force-32bit-saved-gpregs
Error: No symbol table is loaded.  Use the "file" command.

/Andreas

Re: [ECOS] Connecting gdb to AEB

[Jesper Skov]

>>>>> "Andreas" == Andreas Karlsson <Andreas.Karlsson@combitechsystems.com> writes:

Andreas> Hi!  While following the "Getting Started with eCos" you
Andreas> shall connect to the board using these gdb commands.

Andreas> (gdb) set remotebaud 38400 (gdb) set
Andreas> mips-force-32bit-saved-gpregs (gdb) target remote COM1

Ignore that command. It's a documentation bug [Robert, this has been
fixed, hasn't it?]

Jesper

Re: [ECOS] Connecting gdb to AEB

[Robert Erskine]

At 11:52 AM 7/5/00 +0200, Jesper Skov wrote:
>>>>>> "Andreas" == Andreas Karlsson
<Andreas.Karlsson@combitechsystems.com> writes:
>
>Andreas> Hi!  While following the "Getting Started with eCos" you
>Andreas> shall connect to the board using these gdb commands.
>
>Andreas> (gdb) set remotebaud 38400 (gdb) set
>Andreas> mips-force-32bit-saved-gpregs (gdb) target remote COM1
>
>Ignore that command. It's a documentation bug [Robert, this has been
>fixed, hasn't it?]

That line appears in 1.3.1 and 1.3.2 (arm).

Robert

[ECOS] GDB Download on i386 target hangs

[Christian Plessl]

Hi everybody

I managed building a (hopefully) working ECOS kernel. Im able to start it 
using a bootdisk. When looking at the output of COM1: I see the typical 
cryptic GBD debug protocol. Up to here, everything seems to work ok.

When starting GBD or Insight, I'm able to connect to the target, I can even 
view the registers. But if I try to download an 'application' say one of 
the HAL tests for instance 'cache' the download stops after sending about 
3kB of data!

My development system is running Mandrake Linux 7.2 and I'm using the 
latest ECOS sources from CVS.

Does anybody have an idea, why the download immediately stops after 
downloading some 2-3k of data?

Thanks for your help.

Chris

Re: [ECOS] GDB Download on i386 target hangs

[Nick Garnett]

Christian Plessl <cplessl@ee.ethz.ch> writes:

> Hi everybody
> 
> I managed building a (hopefully) working ECOS kernel. Im able to start it 
> using a bootdisk. When looking at the output of COM1: I see the typical 
> cryptic GBD debug protocol. Up to here, everything seems to work ok.
> 
> When starting GBD or Insight, I'm able to connect to the target, I can even 
> view the registers. But if I try to download an 'application' say one of 
> the HAL tests for instance 'cache' the download stops after sending about 
> 3kB of data!
> 
> My development system is running Mandrake Linux 7.2 and I'm using the 
> latest ECOS sources from CVS.
> 
> Does anybody have an idea, why the download immediately stops after 
> downloading some 2-3k of data?
> 
> Thanks for your help.
> 

Have you built the test programs in a separate build tree from the
floppy monitor? If not, then it is very easy to get
cross-contamination and, for example, end up with you executables being
linked to the same memory locations as the monitor. The symptoms you
describe are consistent with the monitor being overwritten by the
download.


-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

Re: [ECOS] GDB Download on i386 target hangs

[Christian Plessl]

Hi Nick and others

>Have you built the test programs in a separate build tree from the
>floppy monitor? If not, then it is very easy to get
>cross-contamination and, for example, end up with you executables being
>linked to the same memory locations as the monitor. The symptoms you
>describe are consistent with the monitor being overwritten by the
>download.

Thanks a lot. You guessed right. Now I've built the tests in a different 
directory, using a i386 target configuration without stubs (is this right?).

Now I'm able to download the excecutables. But immediately after the 
download, when I start the program on the target, I get an SIGILL on the 
target:

GDB Warning:

Program received signal SIGILL, Illegal instruction
0x3270 in ?? () at /usr/local/pack/ecoscvs/ecos/packages/services/memalloc
/common/current/src/dlmalloc.cxx:1257

It's alway the same address, where the debugger claims to find a illegal 
instruction. But if I try to disassemble the code at this address in gdb, 
gdb complains:

(gdb) disassemble 0x3270
Error: No function contains specified address.

When looking at the symboltable of the elf binary using nm, there is no 
code located at 3270.

I'm somewhat confused and have the following questions:

a) Do I have to activate gdb stubs for my application?
b) Whats the matter with this error in dlmalloc? Do I need additional 
configuration for my dynamic allocatable memory on the heap?


A suggestion: Unfortunately there is AFAIK no FAQ on ECOS on i386, but when 
reading the mailing list, I get the impression, that a lot of people do 
have some trouble, when starting devolopment with the ECOS on i386. What 
about collecting these questions and answers in a FAQ.


Chris

Re: [ECOS] GDB Download on i386 target hangs

[Nick Garnett]

Christian Plessl <cplessl@ee.ethz.ch> writes:

> Hi Nick and others
> 
> >Have you built the test programs in a separate build tree from the
> >floppy monitor? If not, then it is very easy to get
> >cross-contamination and, for example, end up with you executables being
> >linked to the same memory locations as the monitor. The symptoms you
> >describe are consistent with the monitor being overwritten by the
> >download.
> 
> Thanks a lot. You guessed right. Now I've built the tests in a different 
> directory, using a i386 target configuration without stubs (is this right?).
>

Probably not, see later.

> Now I'm able to download the excecutables. But immediately after the 
> download, when I start the program on the target, I get an SIGILL on the 
> target:
> 
> GDB Warning:
> 
> Program received signal SIGILL, Illegal instruction
> 0x3270 in ?? () at /usr/local/pack/ecoscvs/ecos/packages/services/memalloc
> /common/current/src/dlmalloc.cxx:1257

What program are you actually running? Do any of the standard test
programs run? Do not take too much notice of what GDB says the
location is here. It is confused by the address being outside it's
known range and is making a guess.

> 
> It's alway the same address, where the debugger claims to find a illegal 
> instruction. But if I try to disassemble the code at this address in gdb, 
> gdb complains:
> 
> (gdb) disassemble 0x3270
> Error: No function contains specified address.
>

Try "x/1i 0x3270". On my machine this gives

0x3270: fild   (%edx)

which looks like it is halfway through an instruction in the stub
monitor. 


> When looking at the symboltable of the elf binary using nm, there is no 
> code located at 3270.
> 
> I'm somewhat confused and have the following questions:
> 
> a) Do I have to activate gdb stubs for my application?

You have to have GDB stubs included in the executable, there is not
sufficient support in the monitor for it to work. This should
happen by default, unless you have changed the configuration in any
way. Initially, just build the default RAM startup configuration
without changing anything, and make sure that something like the
kernel tm_basic test works.

> b) Whats the matter with this error in dlmalloc? Do I need additional 
> configuration for my dynamic allocatable memory on the heap?
>

As I said above, the problem is (probably) not in dlmalloc, that's
just GDB's guess at where it is.

> 
> A suggestion: Unfortunately there is AFAIK no FAQ on ECOS on i386, but when 
> reading the mailing list, I get the impression, that a lot of people do 
> have some trouble, when starting devolopment with the ECOS on i386. What 
> about collecting these questions and answers in a FAQ.
> 

That would be a good idea.


-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

Re: [ECOS] GDB Download on i386 target hangs

[Christian Plessl]

>What program are you actually running? Do any of the standard test
>programs run? Do not take too much notice of what GDB says the
>location is here. It is confused by the address being outside it's
>known range and is making a guess.
>
>Try "x/1i 0x3270". On my machine this gives
>
>0x3270: fild   (%edx)
>
>which looks like it is halfway through an instruction in the stub
>monitor.

Unfortunately, I still have troubles downlaoding.
I tried to run many kernel tests, but there is always the same problem.

I captured my attempt to run the tm_basicthe test:

I configured ecos in a new directory, using the commands

ecosconfig new pc
ecosconfig check
ecosconfig tree
make
make tests

then, chdir to the install/kernel/test directory ..


[cplessl@pluto tests]$ i386-elf-gdb -nw tm_basic
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=i386-elf"...

(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
0x334e in ?? ()
     at 
/usr/local/pack/ecos-cvs/ecos/packages/services/memalloc/common/current/src/dlmalloc.cxx:1257
1257      return chunk2mem(victim);

(gdb) load
Loading section .text, size 0xc118 lma 0x10000
Loading section .rodata, size 0xdfd lma 0x1c118
Loading section .data, size 0x288 lma 0x1cf18
Start address 0x10000 , load size 53661
Transfer rate: 20442 bits/sec, 76 bytes/write.

(gdb) continue
Continuing.
Program received signal SIGILL, Illegal instruction.
0x3273 in ?? ()
     at 
/usr/local/pack/ecos-cvs/ecos/packages/services/memalloc/common/current/src/dlmalloc.cxx:1257
1257      return chunk2mem(victim);

(gdb) x/1i 0x3273
0x3273: (bad)


As you see, It seems as if at location 0x3273 was no valid instruction..

Does anybody have an idea how to solve this problem?


--
Christian Plessl, Loorenstr. 20, 5443 Niederrohrdorf
Tel, Fax: 056 496 41 73    email: cplessl@ee.ethz.ch

Re: [ECOS] GDB Download on i386 target hangs

[Nick Garnett]

Christian Plessl <cplessl@ee.ethz.ch> writes:

> Unfortunately, I still have troubles downlaoding.
> I tried to run many kernel tests, but there is always the same problem.
> 
> I captured my attempt to run the tm_basicthe test:
> 


<snip>

Up to this point it all looks OK, I duplicated it here and got similar
results. But when I continue, the program runs as expected.


> 
> As you see, It seems as if at location 0x3273 was no valid instruction..
> 
> Does anybody have an idea how to solve this problem?
> 

I think the thing to do is to send me a copy of your tm_basic
executable so I can try running it here and see what happens for myself.
Send it direct to me, don't include the list, either MIME or UUCP
encoding should work.

I'm beginning to suspect either a hardware or a toolchain problem.

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

Re: [ECOS] GDB Download on i386 target hangs

[Jesper Skov]

>>>>> "Christian" == Christian Plessl <cplessl@ee.ethz.ch> writes:

Christian> (gdb) load Loading section .text, size 0xc118 lma 0x10000
Christian> Loading section .rodata, size 0xdfd lma 0x1c118 Loading
Christian> section .data, size 0x288 lma 0x1cf18 Start address 0x10000
Christian> , load size 53661 Transfer rate: 20442 bits/sec, 76
Christian> bytes/write.

Christian> As you see, It seems as if at location 0x3273 was no valid
Christian> instruction..

Christian> Does anybody have an idea how to solve this problem?

Yes, do the download, breakpoint 0x10000 and run. Then step your way
through the code using 'si'. Before you start stepping, do:

 (gdb) disp /i $pc

Happy huntin' :)

Jesper

Re: [ECOS] GDB Download on i386 target hangs

[Christian Plessl]

>Well, I just ran it and it worked perfectly. Excerpt below: [..snip..]

hmm, now I'm really confused. At least my toolchain is set up right. Maybe 
it's really a hardware problem. I'will check on an other pc.

>So, it looks like a hardware problem. What exactly is your hardware
>setup? One thought is that the tools by default probably build for a
>Pentium class machine. You may need to add a compiler option if you
>are running on a 386 or 486.

Currently I'm running on a Pentium-I 166 (no MMX), 64Mb EDO-RAM, Type 
Digital Celebris GL-5166ST. Since a have some other boxes around, I will 
try to run it on another PC.


My target system will probably be a 486 single board computer.
What compiler switches would this require?


Could it be, that my made a configuration mistake, when building the bootdisk?

Here my commands:

ecosconfig new pc stubs
ecosconfig tree
make

Should be ok, right?

Chris

--
Christian Plessl <cplessl@ee.ethz.ch>

Re: [ECOS] GDB Download on i386 target hangs

[Nick Garnett]

Christian Plessl <cplessl@ee.ethz.ch> writes:

> >Well, I just ran it and it worked perfectly. Excerpt below: [..snip..]
> 
> hmm, now I'm really confused. At least my toolchain is set up right. Maybe 
> it's really a hardware problem. I'will check on an other pc.

Yes, that's the next obvious step.

> 
> >So, it looks like a hardware problem. What exactly is your hardware
> >setup? One thought is that the tools by default probably build for a
> >Pentium class machine. You may need to add a compiler option if you
> >are running on a 386 or 486.
> 
> Currently I'm running on a Pentium-I 166 (no MMX), 64Mb EDO-RAM, Type 
> Digital Celebris GL-5166ST. Since a have some other boxes around, I will 
> try to run it on another PC.
>

That hardware should be fine. If you have other makes of PC around,
try one of those. 

> 
> My target system will probably be a 486 single board computer.
> What compiler switches would this require?
>

I'm not entirely sure, and it may not even be necessary if my reading
of the documentation is correct. Take a look at the GCC docs for the
i386 specific stuff. Adding "-march=i486" to the compile flags should
be safe, however.


> 
> Could it be, that my made a configuration mistake, when building the bootdisk?
> 
> Here my commands:
> 
> ecosconfig new pc stubs
> ecosconfig tree
> make
> 
> Should be ok, right?
> 

Yep, that's correct. The fact that you can download the executable
shows that this has been built correctly.

If you are still having problems with other PCs, perhaps the next step
is for me to send you an executable I built here, and seen whether
that runs for you.

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

Re: [ECOS] GDB Download on i386 target hangs

[Christian Plessl]

>If you are still having problems with other PCs, perhaps the next step
>is for me to send you an executable I built here, and seen whether
>that runs for you.

You wont belive it, my troubles disappeared. A friend emailed me a i386 
ecos bootsector and it worked. hmm, then I tried to copy my own bootsector 
on the floppy and it worked as well! The solution: I used another floppy. 
My first floppy seems to be somewhat broken! I cannot imagine how this can 
happen, but obviously, the floppydisk is damaged in that way, that ecos 
with stubs can start and download an executable, but after this it crashes! 
Lesson learned: never trust a floppy disk ;)

Thanks to Nick and Jesper for their help.

Re: [ECOS] GDB Download on i386 target hangs

[Nick Garnett]

Christian Plessl <cplessl@ee.ethz.ch> writes:

> >If you are still having problems with other PCs, perhaps the next step
> >is for me to send you an executable I built here, and seen whether
> >that runs for you.
> 
> You wont belive it, my troubles disappeared. A friend emailed me a i386 
> ecos bootsector and it worked. hmm, then I tried to copy my own bootsector 
> on the floppy and it worked as well! The solution: I used another floppy. 
> My first floppy seems to be somewhat broken! I cannot imagine how this can 
> happen, but obviously, the floppydisk is damaged in that way, that ecos 
> with stubs can start and download an executable, but after this it crashes! 
> Lesson learned: never trust a floppy disk ;)

This sounds really wierd. Maybe a strangely formatted floppy? 

> 
> Thanks to Nick and Jesper for their help.
> 

No problem, glad you're on your way at last. 


-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

Re: [ECOS] GDB Download on i386 target hangs

[Jesper Skov]

>>>>> "Nick" == Nick Garnett <nickg@cygnus.co.uk> writes:

>> is damaged in that way, that ecos with stubs can start and download
>> an executable, but after this it crashes!  Lesson learned: never
>> trust a floppy disk ;)

Nick> This sounds really wierd. Maybe a strangely formatted floppy?

Or just a bad sector in the right (wrong) place. I've never understood
why, in the PC world, it appears to be a defacto standard _not_ to
write-verify floppies. Incredible for a media with such a high failure
rate.

<rant>
Now, when I was a lad and used Amiga DOS, written data was always
verified. Yes, it was slower, but one could be fairly confident the
floppy actually contained the intended data whenever it was going to
be used. I took a lot of flak from PC friends using DOS which wrote
data to floppies much faster (verify disabled per default in DOS, but
could be enabled). At the time I didn't (unfortunately) grill them
about failure rates - my own experience is that the more important the
data, and the longer it travels from the source, the greater the
chance it'll be toast on arrival.
</rant>

Jesper

[ECOS] forwarded message from Peter Graf

[Jesper Skov]

To : Jesper Skov <jskov at redhat dot com>
Subject : Re: [ECOS] Hitachi SH7709 Serial drivers
From : pg-itk at t-online dot de (Peter Graf)
Date : Fri, 17 Nov 2000 10:57:21 +0100
References : <pg-itk@t-online.de's message of "Thu, 12 Oct 2000 16:17:54 +0200"><3.0.5.32.20001012161754.008f0560@pop.btx.dtag.de>

Hi Jesper,

thanks for your help with the Hitachi SH7709A serial drivers. One thing I
forgot to report is that the eCos bitrate computation doesn't work
correctly under all conditions. For 20 MHz all works well. The table below
shows the values computed by hand and the values computed by eCos.

Peripheral Clock = 20 MHz:

Bitrate
[bit/s]   n     N       min. error      N eCos  error eCos
4800      0     129     0,16%           129     0,16%
9600      0     64      0,16%           64      0,16%
14400     0     42      0,94%           42      0,94%
19200     0     32      -1,36%          31      1,73%
38400     0     15      1,73%           15      1,73%
57600     0     10      -1,36%          9       8,51%
115200    0     4       8,51%           4       8,51%
230400    0     2       -9,58%          1       35,63%

For 22 MHz eg. 38400 baud doesn't work reliably under eCos. The table below
shows the correct values and the values computed by eCos. (BTW 22 MHz
peripheral clock is very useful because it allows low bitrate errors up to
230 kBaud.)

Peripheral Clock = 22 MHz:

Bitrate
[bit/s]  n      N       min. error      N       error eCos
9600      0     71      -0,54%          70      0,87%
14400     0     47      -0,54%          46      1,58%
19200     0     35      -0,54%          34      2,31%
38400     0     17      -0,54%          16      5,32%
57600     0     11      -0,54%          10      8,51%
115200    0     5       -0,54%          4       19,36%
230400    0     2       -0,54%          1       49,20%

I have only worked around by using a fixed table. A parametric macro
without the rounding problems seems tricky, if you want to avoid
computation at runtime.

Peter

Re: [ECOS] forwarded message from Peter Graf

[Jesper Skov]

Peter> I have only worked around by using a fixed table. A parametric
Peter> macro without the rounding problems seems tricky, if you want
Peter> to avoid computation at runtime.

This is a better solution, IMO.

Jesper

Index: sh3/current/ChangeLog
===================================================================
RCS file: /local/cvsfiles/ecc/ecc/hal/sh/sh3/current/ChangeLog,v
retrieving revision 1.2
diff -u -5 -r1.2 ChangeLog
--- sh3/current/ChangeLog	2000/11/10 07:33:37	1.2
+++ sh3/current/ChangeLog	2000/11/20 07:40:41
@@ -1,5 +1,9 @@
+2000-11-20  Jesper Skov  <jskov@redhat.com>
+
+	* include/mod_regs_ser.h (CYGARC_SCBRR_N): Reduce rounding error.
+
 2000-11-10  Jesper Skov  <jskov@redhat.com>
 
 	* src/var_misc.c: Add spaces around ... used in ranges.
 
 2000-11-01  Jesper Skov  <jskov@redhat.com>
Index: sh3/current/include/mod_regs_ser.h
===================================================================
RCS file: /local/cvsfiles/ecc/ecc/hal/sh/sh3/current/include/mod_regs_ser.h,v
retrieving revision 1.1
diff -u -5 -r1.1 mod_regs_ser.h
--- sh3/current/include/mod_regs_ser.h	2000/11/01 10:00:35	1.1
+++ sh3/current/include/mod_regs_ser.h	2000/11/20 07:38:49
@@ -108,20 +108,24 @@
 #define CYGARC_SCBRR_PRESCALE(_b_) \
 ((((CYGHWR_HAL_SH_ONCHIP_PERIPHERAL_SPEED/32/1/(_b_))-1)<256) ? 1 : \
  (((CYGHWR_HAL_SH_ONCHIP_PERIPHERAL_SPEED/32/4/(_b_))-1)<256) ? 4 : \
  (((CYGHWR_HAL_SH_ONCHIP_PERIPHERAL_SPEED/32/16/(_b_))-1)<256) ? 16 : 64)
 
+// Add half the divisor to reduce rounding errors to .5
+#define CYGARC_SCBRR_ROUNDING(_b_) \
+  16*CYGARC_SCBRR_PRESCALE(_b_)*(_b_)
+
 // These two macros provide the static values we need to stuff into the
 // registers.
 #define CYGARC_SCBRR_CKSx(_b_) \
     ((1 == CYGARC_SCBRR_PRESCALE(_b_)) ? 0 : \
      (4 == CYGARC_SCBRR_PRESCALE(_b_)) ? 1 : \
      (16 == CYGARC_SCBRR_PRESCALE(_b_)) ? 2 : 3)
 #define CYGARC_SCBRR_N(_b_)     \
     (((_b_) < 4800) ? 0 :       \
       ((_b_) > 115200) ? 0 :    \
-       ((CYGHWR_HAL_SH_ONCHIP_PERIPHERAL_SPEED/32/CYGARC_SCBRR_PRESCALE(_b_)/(_b_))-1))
+       (((CYGHWR_HAL_SH_ONCHIP_PERIPHERAL_SPEED+CYGARC_SCBRR_ROUNDING(_b_))/32/CYGARC_SCBRR_PRESCALE(_b_)/(_b_))-1))
 
 
 //++++++ Module IRDA +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 #ifdef CYGARC_SH_MOD_IRDA
 
Index: sh4/current/ChangeLog
===================================================================
RCS file: /local/cvsfiles/ecc/ecc/hal/sh/sh4/current/ChangeLog,v
retrieving revision 1.3
diff -u -5 -r1.3 ChangeLog
--- sh4/current/ChangeLog	2000/11/09 11:23:04	1.3
+++ sh4/current/ChangeLog	2000/11/20 07:41:38
@@ -1,5 +1,9 @@
+2000-11-20  Jesper Skov  <jskov@redhat.com>
+
+	* include/mod_regs_ser.h (CYGARC_SCBRR_N): Reduce rounding error.
+
 2000-11-09  Jesper Skov  <jskov@redhat.com>
 
 	* include/mod_regs_ubc.h: Correct definitions.
 
 	* include/mod_7750.h (CYGARC_SH_MOD_UBC): Defined.
Index: sh4/current/include/mod_regs_ser.h
===================================================================
RCS file: /local/cvsfiles/ecc/ecc/hal/sh/sh4/current/include/mod_regs_ser.h,v
retrieving revision 1.1
diff -u -5 -r1.1 mod_regs_ser.h
--- sh4/current/include/mod_regs_ser.h	2000/11/01 10:00:37	1.1
+++ sh4/current/include/mod_regs_ser.h	2000/11/20 07:41:09
@@ -105,20 +105,24 @@
 #define CYGARC_SCBRR_PRESCALE(_b_) \
 ((((CYGHWR_HAL_SH_ONCHIP_PERIPHERAL_SPEED/32/1/(_b_))-1)<256) ? 1 : \
  (((CYGHWR_HAL_SH_ONCHIP_PERIPHERAL_SPEED/32/4/(_b_))-1)<256) ? 4 : \
  (((CYGHWR_HAL_SH_ONCHIP_PERIPHERAL_SPEED/32/16/(_b_))-1)<256) ? 16 : 64)
 
+// Add half the divisor to reduce rounding errors to .5
+#define CYGARC_SCBRR_ROUNDING(_b_) \
+  16*CYGARC_SCBRR_PRESCALE(_b_)*(_b_)
+
 // These two macros provide the static values we need to stuff into the
 // registers.
 #define CYGARC_SCBRR_CKSx(_b_) \
     ((1 == CYGARC_SCBRR_PRESCALE(_b_)) ? 0 : \
      (4 == CYGARC_SCBRR_PRESCALE(_b_)) ? 1 : \
      (16 == CYGARC_SCBRR_PRESCALE(_b_)) ? 2 : 3)
 #define CYGARC_SCBRR_N(_b_)     \
     (((_b_) < 4800) ? 0 :       \
       ((_b_) > 115200) ? 0 :    \
-       ((CYGHWR_HAL_SH_ONCHIP_PERIPHERAL_SPEED/32/CYGARC_SCBRR_PRESCALE(_b_)/(_b_))-1))
+       (((CYGHWR_HAL_SH_ONCHIP_PERIPHERAL_SPEED+CYGARC_SCBRR_ROUNDING(_b_))/32/CYGARC_SCBRR_PRESCALE(_b_)/(_b_))-1))
 
 
 //++++++ Module IRDA +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 #ifdef CYGARC_SH_MOD_IRDA
 

[ECOS] Hitachi SH7709A problems

[Peter Graf]

Jesper wrote:

[baudrate errors]

>Peter> I have only worked around by using a fixed table. A parametric
>Peter> macro without the rounding problems seems tricky, if you want
>Peter> to avoid computation at runtime.
>
>This is a better solution, IMO.

[New macro definition]

Yes it is, thanks very much!

At the moment I am struggling with two serious problems on the SH7709A target:

1. When I use the GDB stub compiled from the latest CVS sources, I can only
set one breakpoint. If I remove it and set the next and so on, everything
works fine. If I don't remove all old breakpoints before continuing, the
target keeps on running and ignores further breakpoint(s). An older stub,
compiled from sources probably around August, works fine. Could be related
to the use of the UBC, but I haven't been able to figure out.

2. ROMs compiled in ROMRAM startup mode don't work anymore, although the
pure ROM versions work. The ROMRAM feature has also worked fine using
earlier sources.

Has anyone else exprienced the same? Thanks.

Peter

Re: [ECOS] Hitachi SH7709A problems

[Jesper Skov]

>>>>> "Peter" == Peter Graf <pg-itk@t-online.de> writes:

Peter> Jesper wrote: [baudrate errors]

Peter> I have only worked around by using a fixed table. A parametric
Peter> macro without the rounding problems seems tricky, if you want
Peter> to avoid computation at runtime.
>>  This is a better solution, IMO.

Peter> [New macro definition]

Peter> Yes it is, thanks very much!

Good.

Peter> At the moment I am struggling with two serious problems on the
Peter> SH7709A target:

Peter> 1. When I use the GDB stub compiled from the latest CVS
Peter> sources, I can only set one breakpoint. If I remove it and set
Peter> the next and so on, everything works fine. If I don't remove
Peter> all old breakpoints before continuing, the target keeps on
Peter> running and ignores further breakpoint(s). An older stub,
Peter> compiled from sources probably around August, works fine. Could
Peter> be related to the use of the UBC, but I haven't been able to
Peter> figure out.

Hm, no clue. Maybe because you use a new(er) version of GDB which uses
stub breakpoints, which I believe were added to the stub recently by
Drew. Only, I don't think they should affect the HALs unless they
claim to support it somehow. I haven't looked at it. 

In mod_7709a.h you can comment out the UBC definition, and the stub
will fall back to the old way of single-stepping. But that should be
the only effect. I can't think of any reason breakpoints should be
involved.

Your target is indeed a 7709A, right? The UBCs differ between the
various CPU models.

Peter> 2. ROMs compiled in ROMRAM startup mode don't work anymore,
Peter> although the pure ROM versions work. The ROMRAM feature has
Peter> also worked fine using earlier sources.

I may have broken something when the code was split into variant
HALs. I probably won't have time to look at it until next year though
- so if it's something you need working ASAP, you are probably best of
(a) figuring out why it fails on your own, or (b) revert to the older
codebase. Sorry.

Jesper

Re: [ECOS] Hitachi SH7709A problems

[Peter Graf]

At 15:58 20.11.00 +0100, Jesper Skov wrote:

>Peter> 1. When I use the GDB stub compiled from the latest CVS
>Peter> sources, I can only set one breakpoint. If I remove it and set
>Peter> the next and so on, everything works fine. If I don't remove
>Peter> all old breakpoints before continuing, the target keeps on
>Peter> running and ignores further breakpoint(s). An older stub,
>Peter> compiled from sources probably around August, works fine. Could
>Peter> be related to the use of the UBC, but I haven't been able to
>Peter> figure out.
>
>Hm, no clue. Maybe because you use a new(er) version of GDB which uses
>stub breakpoints, which I believe were added to the stub recently by
>Drew. Only, I don't think they should affect the HALs unless they
>claim to support it somehow. I haven't looked at it. 
>
>In mod_7709a.h you can comment out the UBC definition, and the stub
>will fall back to the old way of single-stepping. But that should be
>the only effect. I can't think of any reason breakpoints should be
>involved.

Since single-stepping also doesn't seem work anymore, I will try removing
the UBC definition, thanks for the hint.

>Your target is indeed a 7709A, right?

Exactly.

>Peter> 2. ROMs compiled in ROMRAM startup mode don't work anymore,
>Peter> although the pure ROM versions work. The ROMRAM feature has
>Peter> also worked fine using earlier sources.
>
>I may have broken something when the code was split into variant
>HALs. I probably won't have time to look at it until next year though
>- so if it's something you need working ASAP, you are probably best of
>(a) figuring out why it fails on your own, or (b) revert to the older
>codebase. Sorry.

I've already started (a), but debugging by burning Flashroms is quite
tough. I'll let you know if I find something.

Thanks

Peter

Re: [ECOS] Hitachi SH7709A problems

[Jesper Skov]

>>>>> "Peter" == Peter Graf <pg-itk@t-online.de> writes:

Peter> 2. ROMs compiled in ROMRAM startup mode don't work anymore,
Peter> although the pure ROM versions work. The ROMRAM feature has
Peter> also worked fine using earlier sources.
>>  I may have broken something when the code was split into variant
>> HALs. I probably won't have time to look at it until next year
>> though - so if it's something you need working ASAP, you are
>> probably best of (a) figuring out why it fails on your own, or (b)
>> revert to the older codebase. Sorry.

Peter> I've already started (a), but debugging by burning Flashroms is
Peter> quite tough. I'll let you know if I find something.

Did you find the problem? It was the initial jump instruction at the
image entry address. It was fixed in late December in the CVS tree.

Cheers,
Jesper

Re: [ECOS] Hitachi SH7709A problems

[Peter Graf]

Hi Jesper,

sorry for the late reply, have been away from office for some time.

>Peter> 2. ROMs compiled in ROMRAM startup mode don't work anymore,
>Peter> although the pure ROM versions work. The ROMRAM feature has
>Peter> also worked fine using earlier sources.
>>>  I may have broken something when the code was split into variant
>>> HALs. I probably won't have time to look at it until next year
>>> though - so if it's something you need working ASAP, you are
>>> probably best of (a) figuring out why it fails on your own, or (b)
>>> revert to the older codebase. Sorry.
>
>Peter> I've already started (a), but debugging by burning Flashroms is
>Peter> quite tough. I'll let you know if I find something.
>
>Did you find the problem? It was the initial jump instruction at the
>image entry address. It was fixed in late December in the CVS tree.

Thank you very much for fixing the ROMRAM problem.

But no I didn't find it, seems I've looked at the wrong places. I gave up
the "ROMRAM" target. I started writing flash drivers and using Redboot
instead. Which I have now running (using a serial port) on our hardware. I
load a "RAM" binary from FIS, which is a good replacement for "ROMRAM" (and
more :-)). Pretty feature to be able to use the same code for debugging in
RAM and for the production version loaded from flash.

All the best

Peter

[ECOS] Help me !!, Hello world on out target

[°íÀç¿ë]

Hi All!
I am porting eCos on our target which is simmilar with CMA230.
Now, I am working with ecos-1.3.1 (net-release, 27-03-2000).
I was building and testing GDB stubs ROM.
Downloading is OK, but RAM application is not executed.
CPU core of our target is ARM7 and support  FIQ.  But IRQ is not supported.
Is there anything to change in HAL for FIQ ?
While downloading, Is GDB Stub ROM operated by polled or interrupt ?
Thanks a lot !

Re: [ECOS] Help me !!, Hello world on out target

[Jesper Skov]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 925 bytes --]

>>>>> "°íÀç¿ë" == °íÀç¿ë  <koh@bdtel.com> writes:

°íÀç¿ë> Hi All!  I am porting eCos on our target which is simmilar
°íÀç¿ë> with CMA230.  Now, I am working with ecos-1.3.1 (net-release,
°íÀç¿ë> 27-03-2000).  I was building and testing GDB stubs ROM.

You should use the CVS tree instead. 1.3.1 is way old now.

°íÀç¿ë> Downloading is OK, but RAM application is not executed.  CPU
°íÀç¿ë> core of our target is ARM7 and support FIQ.  But IRQ is not
°íÀç¿ë> supported.  Is there anything to change in HAL for FIQ ?

Yes. I can't tell you what off hand though. But I'm sure you'll need
to change some things.

°íÀç¿ë> While downloading, Is GDB Stub ROM operated by polled or
°íÀç¿ë> interrupt ?  Thanks a lot !

Polled mode only.

Jesper

Re: [ECOS] Help me !!, Hello world on out target

[Lewin A.R.W. Edwards]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

>°íÀç¿ë> with CMA230.  Now, I am working with ecos-1.3.1 (net-release,
>
>You should use the CVS tree instead. 1.3.1 is way old now.

I'm using 1.3.1 too (and can't get the TCP/IP stuff installed). Will a CVS 
checkout of today give the complete OS including TCP/IP stack or is the 
networking stuff in a different repository?

Also, is it possible to build the Win32-hosted graphical administration 
tool for the latest eCos version? I like that tool very much.


Lewin A.R.W. Edwards (Embedded Engineer)
Got any Commodore 16 or VIC-20 hardware, cartridges, tapes?
Visit http://www.larwe.com/vintage/
================================================
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

Re: [ECOS] Help me !!, Hello world on out target

[Jesper Skov]

>>>>> "Lewin" == Lewin A R W Edwards <larwe@larwe.com> writes:

>> =B0=ED=C0=E7=BF=EB> with CMA230.  Now, I am working with
>> ecos-1.3.1=
Lewin>  (net-release,
>>  You should use the CVS tree instead. 1.3.1 is way old now.

Lewin> I'm using 1.3.1 too (and can't get the TCP/IP stuff
Lewin> installed). Will a CVS= =20 checkout of today give the complete
Lewin> OS including TCP/IP stack or is the=20 networking stuff in a
Lewin> different repository?

I think it's all in the same repo now, but I must admit that I'm not
100% sure.

Lewin> Also, is it possible to build the Win32-hosted graphical
Lewin> administration=20 tool for the latest eCos version? I like that
Lewin> tool very much.

I believe a new version has been uploaded on sourceware somewhere that
handles the new CDL stuff. Again, I'm not sure though.

Jesper

Re: [ECOS] Help me !!, Hello world on out target

[Jonathan Larmour]

Jesper Skov wrote:
> 
> >>>>> "Lewin" == Lewin A R W Edwards <larwe@larwe.com> writes:
> 
> >> =B0=ED=C0=E7=BF=EB> with CMA230.  Now, I am working with
> >> ecos-1.3.1=
> Lewin>  (net-release,
> >>  You should use the CVS tree instead. 1.3.1 is way old now.
> 
> Lewin> I'm using 1.3.1 too (and can't get the TCP/IP stuff
> Lewin> installed). Will a CVS= =20 checkout of today give the complete
> Lewin> OS including TCP/IP stack or is the=20 networking stuff in a
> Lewin> different repository?
> 
> I think it's all in the same repo now, but I must admit that I'm not
> 100% sure.

It is in the same repository but you have to use separate steps to get it.
It's described at http://sources.redhat.com/anoncvs.html under "Optional
networking support".
 
> Lewin> Also, is it possible to build the Win32-hosted graphical
> Lewin> administration=20 tool for the latest eCos version? I like that
> Lewin> tool very much.
> 
> I believe a new version has been uploaded on sourceware somewhere that
> handles the new CDL stuff. Again, I'm not sure though.

It has indeed. Again there's a link at
http://sources.redhat.com/anoncvs.html

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

[ECOS] gdb/insight questions

[Lewin A.R.W. Edwards]

Well, practically everything works - I can compile apps, I can connect to 
the target board and I can load programs. I have a couple of gdb questions 
though.

Q1: I don't understand where console I/O goes by default; I would have 
assumed to the gdb console but it seems not? My hello world app has a 
printf in it; by default, where does this output go? Can someone please 
verify to me that this is the right process:

* compile
* arm-elf-gdb -nw a.out
* (gdb) set remotebaud 38400
* (gdb) target remote com1
* (gdb) load
* (gdb) continue

I also tried enabling serial port 2 and fprintfing a message to /dev/ttys2 
or whatever it is, and I get my output message on the second port so the 
program is definitely running (yay!).

Q2: (Relatively minor) I can only run command-line gdb, not insight. I even 
tried recompiling insight but when I run it I get an MB_ICONSTOP messagebox 
that says:

Can't find a usable main.tcl in the following directories:
C:/CYGWIN/TOOLS/share/gdbctl C:/CYGWIN/TOOLS/gdbtcl 
C:/CYGWIN/TOOLS/gdb/gdbtk/library C:/CYGWIN/TOOLS/gdb1.0/gdbtk/library

C:/CYGWIN/TOOLS/share/gdbtcl/main.tcl: can't read "errMsg": no such variable
can't read "errMsg": no such variable
while executing "tk_messageBox -title Error -message "Could not find the 
lwidgets libraries. Got nameofexec: [info nameofexecutable]
Error(s) were :\n$errMsg" -icon e..."
invoked from within
"if {![find_iwidgets_library]} {
tk_messageBox....................

(lots more stuff).

I can run native insight with no problems.
=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

Re: [ECOS] gdb/insight questions

[Jesper Skov]

>>>>> "Lewin" == Lewin A R W Edwards <larwe@larwe.com> writes:

Lewin> Well, practically everything works - I can compile apps, I can
Lewin> connect to the target board and I can load programs. I have a
Lewin> couple of gdb questions though.

Lewin> Q1: I don't understand where console I/O goes by default; I
Lewin> would have assumed to the gdb console but it seems not? My
Lewin> hello world app has a printf in it; by default, where does this
Lewin> output go? Can someone please verify to me that this is the
Lewin> right process:

It is. Problem is that GDB hides any output that is not in O-packet
format. HAL diag will normally wrap ASCII output in O-packets, but raw
serial output does not (for obvious reasons).

If you need raw ASCII output via serial I suggest you just use that
extra serial line.

Jesper

Re: [ECOS] gdb/insight questions

[Lewin A.R.W. Edwards]

Hi Jesper,

>Lewin> Q1: I don't understand where console I/O goes by default; I
>Lewin> would have assumed to the gdb console but it seems not? My
>
>If you need raw ASCII output via serial I suggest you just use that
>extra serial line.

OK, this is no problem. I was just puzzled when I got no "hello world" with 
printf.  Thanks for the explanation.

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

Re: [ECOS] gdb/insight questions

[Jonathan Larmour]

"Lewin A.R.W. Edwards" wrote:
> 
> Q1: I don't understand where console I/O goes by default; I would have
> assumed to the gdb console but it seems not? My hello world app has a
> printf in it; by default, where does this output go? Can someone please
> verify to me that this is the right process:
> 
> * compile
> * arm-elf-gdb -nw a.out
> * (gdb) set remotebaud 38400
> * (gdb) target remote com1
> * (gdb) load
> * (gdb) continue

Jesper then said "Problem is that GDB hides any output that is not in
O-packet
format. HAL diag will normally wrap ASCII output in O-packets, but raw
serial output does not (for obvious reasons)."

but isn't the problem above that printf() isn't working by default? Or has
Lewin changed the configuration from the default to use haldiag, to serial
drivers; or changed haldiag to output packets that aren't O-packetized.

My point is that *by default* printf() should work and display output on
GDB.
 
> I also tried enabling serial port 2 and fprintfing a message to /dev/ttys2
> or whatever it is, and I get my output message on the second port so the
> program is definitely running (yay!).
> 
> Q2: (Relatively minor) I can only run command-line gdb, not insight. I even
> tried recompiling insight but when I run it I get an MB_ICONSTOP messagebox
> that says:
> 
> Can't find a usable main.tcl in the following directories:
> C:/CYGWIN/TOOLS/share/gdbctl C:/CYGWIN/TOOLS/gdbtcl
> C:/CYGWIN/TOOLS/gdb/gdbtk/library C:/CYGWIN/TOOLS/gdb1.0/gdbtk/library
> 
> C:/CYGWIN/TOOLS/share/gdbtcl/main.tcl: can't read "errMsg": no such variable
> can't read "errMsg": no such variable
> while executing "tk_messageBox -title Error -message "Could not find the
> lwidgets libraries. Got nameofexec: [info nameofexecutable]
> Error(s) were :\n$errMsg" -icon e..."
> invoked from within
> "if {![find_iwidgets_library]} {
> tk_messageBox....................
> 
> (lots more stuff).

I seem to recall this coming up before. Are you using Win98? See my earlier
reply at http://sources.redhat.com/ml/ecos-discuss/2000-10/msg00137.html
which recommends to upgrade both your cygwin and insight versions.

[ I decided not to update the FAQ in the end because this isn't
sufficiently frequent, and will be less so as time goes on. ]

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] gdb/insight questions

[Lewin A.R.W. Edwards]

Hi Jonathan,

> > Q1: I don't understand where console I/O goes by default; I would have
> > assumed to the gdb console but it seems not? My hello world app has a
>
>Jesper then said "Problem is that GDB hides any output that is not in
>
>but isn't the problem above that printf() isn't working by default? Or has
>Lewin changed the configuration from the default to use haldiag, to serial

Well, I did not change anything related to this THAT I KNOW OF, but I have 
since generated a new "from scratch" .ecc and now printf works like I 
expected. I guess my configuration was wrong or corrupt.

BTW, the config tool seems to be quite unstable when saving .ecc files. It 
seems to be slightly more stable if one collapses all the controls in the 
left-hand pane before attempting to save the .ecc.

> > Can't find a usable main.tcl in the following directories:
> > C:/CYGWIN/TOOLS/share/gdbctl C:/CYGWIN/TOOLS/gdbtcl
> > C:/CYGWIN/TOOLS/gdb/gdbtk/library C:/CYGWIN/TOOLS/gdb1.0/gdbtk/library
>
>I seem to recall this coming up before. Are you using Win98? See my earlier
>reply at http://sources.redhat.com/ml/ecos-discuss/2000-10/msg00137.html
>which recommends to upgrade both your cygwin and insight versions.

Guilty as charged. If this is a known problem and not just my own personal 
ill karma then I will leave things as they are, I think, rather than trying 
to wrestle with the whole toolchain issue again. I might downgrade to 
regular non-insight gdb so I don't have to remember -nw all the time.

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

RE: [ECOS] gdb/insight questions

[Natarajan, Mekala (CTS)]

hi,
i am using i386pc target. For me printf() is working fine and it is
displaying output in GDB console..
-----Original Message-----
From: Jonathan Larmour [ mailto:jlarmour@cygnus.co.uk ]
Sent: Wednesday, December 06, 2000 9:45 AM
To: Lewin A.R.W. Edwards
Cc: ecos-discuss@sourceware.cygnus.com; Jesper Skov
Subject: Re: [ECOS] gdb/insight questions


"Lewin A.R.W. Edwards" wrote:
> 
> Q1: I don't understand where console I/O goes by default; I would have
> assumed to the gdb console but it seems not? My hello world app has a
> printf in it; by default, where does this output go? Can someone please
> verify to me that this is the right process:
> 
> * compile
> * arm-elf-gdb -nw a.out
> * (gdb) set remotebaud 38400
> * (gdb) target remote com1
> * (gdb) load
> * (gdb) continue

Jesper then said "Problem is that GDB hides any output that is not in
O-packet
format. HAL diag will normally wrap ASCII output in O-packets, but raw
serial output does not (for obvious reasons)."

but isn't the problem above that printf() isn't working by default? Or has
Lewin changed the configuration from the default to use haldiag, to serial
drivers; or changed haldiag to output packets that aren't O-packetized.

My point is that *by default* printf() should work and display output on
GDB.
 
> I also tried enabling serial port 2 and fprintfing a message to /dev/ttys2
> or whatever it is, and I get my output message on the second port so the
> program is definitely running (yay!).
> 
> Q2: (Relatively minor) I can only run command-line gdb, not insight. I
even
> tried recompiling insight but when I run it I get an MB_ICONSTOP
messagebox
> that says:
> 
> Can't find a usable main.tcl in the following directories:
> C:/CYGWIN/TOOLS/share/gdbctl C:/CYGWIN/TOOLS/gdbtcl
> C:/CYGWIN/TOOLS/gdb/gdbtk/library C:/CYGWIN/TOOLS/gdb1.0/gdbtk/library
> 
> C:/CYGWIN/TOOLS/share/gdbtcl/main.tcl: can't read "errMsg": no such
variable
> can't read "errMsg": no such variable
> while executing "tk_messageBox -title Error -message "Could not find the
> lwidgets libraries. Got nameofexec: [info nameofexecutable]
> Error(s) were :\n$errMsg" -icon e..."
> invoked from within
> "if {![find_iwidgets_library]} {
> tk_messageBox....................
> 
> (lots more stuff).

I seem to recall this coming up before. Are you using Win98? See my earlier
reply at http://sources.redhat.com/ml/ecos-discuss/2000-10/msg00137.html
which recommends to upgrade both your cygwin and insight versions.

[ I decided not to update the FAQ in the end because this isn't
sufficiently frequent, and will be less so as time goes on. ]

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
This e-mail and any files transmitted with it are for the sole use 
of the intended recipient(s) and may contain confidential and privileged information. 
If you are not the intended recipient, please contact the sender by reply e-mail and 
destroy all copies of the original message. Any unauthorised review, use, disclosure, 
dissemination, forwarding, printing or copying of this email or any action taken in 
reliance on this e-mail is strictly prohibited and may be unlawful.

		Visit us at http://www.cognizant.com

Re: [ECOS] gdb/insight questions

[Jesper Skov]

>>>>> "Natarajan," == Natarajan, Mekala (CTS) <NMekala@CHN.CTS-CORP.COM> writes:

Natarajan,> hi, i am using i386pc target. For me printf() is working
Natarajan,> fine and it is displaying output in GDB console..

Curiously, the behavior is different on different platforms/versions
of GDB.

jifl> Jesper then said "Problem is that GDB hides any output
jifl> that is not in O-packet format. HAL diag will normally
jifl> wrap ASCII output in O-packets, but raw serial output does
jifl> not (for obvious reasons)."

jifl> but isn't the problem above that printf() isn't working by
jifl> default? Or has Lewin changed the configuration from the
jifl> default to use haldiag, to serial drivers; or changed
jifl> haldiag to output packets that aren't O-packetized.

jifl> My point is that *by default* printf() should work and
jifl> display output on GDB.
 
Hm, you are right. Lewin, you can make sure by enabling remotedebug in
GDB - that will show you if the incoming data is in raw or O-packet
format.

I'm not sure why it shouldn't be in O-packet format, unless you are
writing to a raw device (fprintf? - do we actually have that?)

Jesper

Re: [ECOS] gdb/insight questions

[Lewin A.R.W. Edwards]

>I'm not sure why it shouldn't be in O-packet format, unless you are
>writing to a raw device (fprintf? - do we actually have that?)

Yes, you have fprintf.  Sssh, it is working fine for me, don't jinx it by 
saying it shouldn't work ;)

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

[ECOS] Really dumb newbie question

[Tim Noell]

Hi eCos Users:

I'm new to eCos and new to this list.  Please don't skewer me for my dumb newbie 
questions - I'll come up to speed fast enough ...

I've searched the archives and not found anything on this, so here goes:

I've just installed eCos v1.3.1 on my Windoze NT 4.0 machine.  When I invoke the 
Configuration Tool I get the following error:
"The ordinal 6880 could not be located in the dynamic link library MFC42.DLL"

I get a similar error when I invoke the Package Administration Tool.

Looks like I need a later version of MFC42.DLL - ?  Which one?  Where do I get 
it?

BTW, do very many of you use the Windoze host?  Most are on a Linux host, I'm 
guessing ...

Sorry for the newbie-ness of my questions, and THANKS in advance!
Tim

// Tim Noell  
// Specialist, Business Printer Division
// Lexmark International, Inc.  
// "Only dead fish go with the flow."

Re: [ECOS] Really dumb newbie question

[Lewin A.R.W. Edwards]

Hi Tim,

>I've just installed eCos v1.3.1 on my Windoze NT 4.0 machine.  When I 
>invoke the  Configuration Tool I get the following error:
>"The ordinal 6880 could not be located in the dynamic link library MFC42.DLL"

I had this problem when I used a buggy installer - I think it was either 
OrCAD 9.1 or Eudora 4.3 - that overwrote my MFC42.DLL with an old one. 
Checking my hard drive I find several versions:

OrCAD - 940,304 bytes, 06/30/98 07:33a
WINDOWS\SYSTEM - 995,383 bytes 04/26/99 11:00p
Sony HotBurn - 954,640 bytes 11/04/97 01:12a
HP Network Printer - 995,383 bytes 08/19/99 06:26p

I can email you the WINDOWS\SYSTEM copy if you want.

>BTW, do very many of you use the Windoze host?  Most are on a Linux host, I'm
>guessing ...

It is much, much, much more convenient to me to use Windows as my host, so 
I'll only move to Linux if it becomes absolutely necessary. Having said 
that, I will admit that if you can either do all your non-eCos work in it, 
or dedicate a PC to it, Linux is definitely the platform of choice. For me 
it boils down to which set of hoops I'd rather jump through, and the 
Windows-colored hoops blaze with a slightly cooler flame. I work much 
better when I can just close my laptop and take everything home with me.

There are some gotchas in Windows and in particular you might find, as I 
have, that the GUI configuration tool is REALLY unstable on Windows, but 
since I spend much more than 99% of my time in a text  editor and gdb, that 
isn't such a big issue. Just remember to make backup copies of your .ecc 
files before attempting any editing, since the config tool crashes very 
often (for me at least) when saving edits to an existing file.

>Sorry for the newbie-ness of my questions, and THANKS in advance!

My questions in this list are of the same caliber, so don't be ashamed ;)

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."

Re: [ECOS] Really dumb newbie question

[Jesper Skov]

>>>>> "Lewin" == Lewin A R W Edwards <larwe@larwe.com> writes:
Lewin> OrCAD - 940,304 bytes, 06/30/98 07:33a WINDOWS\SYSTEM - 995,383
Lewin> bytes 04/26/99 11:00p Sony HotBurn - 954,640 bytes 11/04/97
Lewin> 01:12a HP Network Printer - 995,383 bytes 08/19/99 06:26p

Lewin> I can email you the WINDOWS\SYSTEM copy if you want.

Probably wouldn't work as Tim's using NT4.

Tim, have you installed the latest service pack? If not, do so, as it
should (I imagine) update the DLL as well.

Lewin> There are some gotchas in Windows and in particular you might
Lewin> find, as I have, that the GUI configuration tool is REALLY
Lewin> unstable on Windows, but since I spend much more than 99% of my
Lewin> time in a text editor and gdb, that isn't such a big
Lewin> issue. Just remember to make backup copies of your .ecc files
Lewin> before attempting any editing, since the config tool crashes
Lewin> very often (for me at least) when saving edits to an existing
Lewin> file.

The config tool is more stable on NT than on
Windows9x/ME/suffix-of-the-day but even on NT it tends to bomb (for me
anyway) after saving the same config 5-10 times.

Jesper

Re: [ECOS] Really dumb newbie question

[Lewin A.R.W. Edwards]

>Lewin> OrCAD - 940,304 bytes, 06/30/98 07:33a WINDOWS\SYSTEM - 995,383
>
>Lewin> I can email you the WINDOWS\SYSTEM copy if you want.
>
>Probably wouldn't work as Tim's using NT4.

Well, a colleague has eCos's Windows host-end installed on an NT4 machine 
also, so I could give him the MFC42 from there. However I assumed that this 
file, or at least recent versions of it, cover both platforms, because I 
have programs that claim compatibility with both, and their install media 
have only one version of the file.

>Lewin> before attempting any editing, since the config tool crashes
>Lewin> very often (for me at least) when saving edits to an existing
>
>The config tool is more stable on NT than on
>Windows9x/ME/suffix-of-the-day but even on NT it tends to bomb (for me
>anyway) after saving the same config 5-10 times.

I haven't noticed a great deal of difference between NT4, 98SE and Win2k. 
If I had time (how many times do I say that every day) I would investigate 
further. I have a gut feeling that the problem is related to the way the 
tree control is coded.

How about recoding the config tool in Java? :)

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."

Re: [ECOS] Really dumb newbie question

[Gary Thomas]

On 11-Jan-2001 Lewin A.R.W. Edwards wrote:
> How about recoding the config tool in Java? :)
> 

The ConfigTool _is_ being rewritten, due out probably by Summer '01.

Sorry, no Java, just WxWindows (the most portable and flexible toolkit
we could find),

Re: [ECOS] Really dumb newbie question

[Grant Edwards]

On Thu, Jan 11, 2001 at 08:24:28AM -0700, Gary Thomas wrote:

> On 11-Jan-2001 Lewin A.R.W. Edwards wrote:
> > How about recoding the config tool in Java? :)
> 
> The ConfigTool _is_ being rewritten, due out probably by Summer '01.
> 
> Sorry, no Java, just WxWindows (the most portable and flexible toolkit
> we could find),

Just curious: what language is being used?  I've heard a lot of
good things about the Python/WxWindows combo..

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] Really dumb newbie question

[Julian Smart]

At 09:44 AM 1/11/01 -0600, you wrote:
>Just curious: what language is being used?  I've heard a lot of
>good things about the Python/WxWindows combo..

I'm using C++; the main reasons behind this are that (a) Python would 
introduce another layer of complexity and possible configtool support 
issues; (b) I know C++ so I'll be more productive, and (c) since the 
original configtool was written in C++, quite a bit of code can be lifted 
with minimal translation. But yes, a lot of people rave about wxPython.

The Linux (wxGTK) version is going well and it's starting to allow 
configuration viewing and editing.

Although I'm a bit biassed towards wxWindows being its original author, I'm 
still pleasantly surprised at how good a job it does ;-) in large part due 
to Robert Roebling's excellent GTK+ port, together with his dialog editor.

Regards,

Julian
--
Red Hat UK Ltd, Unit 200 Rustat House, 62 Clifton Road, Cambridge, UK. CB1 
7EG Tel: +44 (1223) 271063

Re: [ECOS] Really dumb newbie question

[Grant Edwards]

On Thu, Jan 11, 2001 at 03:57:32PM +0000, Julian Smart wrote:

> >Just curious: what language is being used?  I've heard a lot of
> >good things about the Python/WxWindows combo..
> 
> I'm using C++; the main reasons behind this are that (a) Python
> would introduce another layer of complexity and possible
> configtool support issues; (b) I know C++ so I'll be more
> productive, and (c) since the original configtool was written
> in C++, quite a bit of code can be lifted with minimal
> translation. But yes, a lot of people rave about wxPython.

The other part of RedHat has always been pretty big into
Python*, and I though maybe that had rubbed off on you guys.
Even though most of the Linux boxes probably have Python, many
don't don't have wxPython, so it would introduce another layer
of installation/support hassles.

* IIRC, the RH Linux installers were originally written in
  Python, rpm was originally in Python, some of the system
  configuration tools were in Python.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] Really dumb newbie question

[Gary Thomas]

On 11-Jan-2001 Grant Edwards wrote:
> On Thu, Jan 11, 2001 at 08:24:28AM -0700, Gary Thomas wrote:
> 
>> On 11-Jan-2001 Lewin A.R.W. Edwards wrote:
>> > How about recoding the config tool in Java? :)
>> 
>> The ConfigTool _is_ being rewritten, due out probably by Summer '01.
>> 
>> Sorry, no Java, just WxWindows (the most portable and flexible toolkit
>> we could find),
> 
> Just curious: what language is being used?  I've heard a lot of
> good things about the Python/WxWindows combo..

C/C++ AFAIK (since the libCDL is in C++).

I agree about Python, being a member of the now extinct PSA, but that's 
yet another political battle ...

Re: [ECOS] Really dumb newbie question

[Sergei Organov]

As CDL itself is Tcl, it seems to be more natural to code ConfigTool in Tcl/Tk
than in Java/Python/whatever. Why to add third language to the picture?

Gary Thomas <gthomas@redhat.com> writes:
> On 11-Jan-2001 Lewin A.R.W. Edwards wrote:
> > How about recoding the config tool in Java? :)
> > 
> 
> The ConfigTool _is_ being rewritten, due out probably by Summer '01.
> 
> Sorry, no Java, just WxWindows (the most portable and flexible toolkit
> we could find),