[ECOS] TUI: PDCurses for eCOS

[ECOS] TUI: PDCurses for eCOS

[Sergei Gavrikov]

[-- Attachment #1: Type: text/plain, Size: 3264 bytes --]

Hi

Last weekend I've done a port of PDCurses for ECOS. The whole curses
library built for for ARM-7 is

~/PDCurses-3.4/ecos$ arm-eabi-size -t libpdcurses.a
   text	   data	    bss	    dec	    hex	filename
   1052	      0	      0	   1052	    41c	addch.o (ex libpdcurses.a)

[snip]

  42437	    176	   6731	  49344	   c0c0	(TOTALS)

The PDCurses <http://pdcurses.sourceforge.net> sources are the very
portable. I found what it's code is very compact and very qualitative.
Compiling with -Wall produces no warnings. No need to mess up with the
PDCurses core to port it for new OS.  When I started the port, I found
and again re-read Peter's Seebach article: Porting a screen-management
utility to eCos on IBM developerWorks

http://www.ibm.com/developerworks/power/library/pa-tams3/

Read the last sentence of the Peter's article, please. If I wrote about
the PDCurses + eCos, I would resume that like Peter said, Executable
size is unbeatable; the whole application is _140_KB, including kernel,
drivers, curses, etc. And yet another important thing: I did no dance
with the PDCurses sources like Peter did with the OpenBSD curses.

I would not believe in the said the above if I could not run a `size'
for the got executables just now (built for RAM startup, stripped)

~/PDCurses-3.4/ecos$ arm-eabi-size firework newdemo ptest rain testcurs worm xmas
   text	   data	    bss	    dec	    hex	filename
  62612	   1376	  24864	  88852	  15b14	firework
  67852	   1456	  24856	  94164	  16fd4	newdemo
  66648	   1368	  23752	  91768	  16678	ptest
  62772	   1356	  24796	  88924	  15b5c	rain
  96956	   1460	  24748	 123164	  1e11c	testcurs
  67348	   1396	  25404	  94148	  16fc4	worm
  69852	   1348	  21852	  93052	  16b7c	xmas

Those are real working demos built for my target (BTW, `testcurs' is the
1K lines written in curses). They all work very smoothly, 3 colour worms
creep, aa-xmas card greets me, it fireworks, it rains, and `testcurs' and
other demos learn me :-) Many thanks to William McBrine for the PDCurses!

And what's about a fly in the ointment? malloc, calloc, free and curses
event loop.

If anyone will want to try the port, I attached it. To build the port,
download the latest PDCurses 3.4 sources from SF. Build the demos for
x11 or sdl1 to taste a honey. Unpack `pdcecos.tar.gz' under PDCurses-3.4
tree then and follow the instructions in the ecos/README* files.

Notes: 1) The port was tested on Linux Ubuntu 8.04 with Olimex LPC-E2294
board using `minicom' communication program. 2) I never wrote in curses,
but I used `whiptail' a while ago, so, I won't help you on curses. 3)
the port is two-days `weekend mechanics', so, it may be not ideal, it
was my first look on PDCurses. 4) I do not know much about this remark
from PDCurses's README

---->8
The core package is in the public domain, but small portions of PDCurses
are subject to copyright under various licenses.  Each directory
contains a README file, with a section titled "Distribution Status"
which describes the status of the files in that directory.
---->8

So, I can not answer on Q: Is it possible to enter PDCurses in eCos CVS
tree?

In any case I think that PDCurses can be the very useful library to
build the excellent TUIs under eCos.

That's it.

Regards,

Sergei

[-- Attachment #2: pdcecos.tar.gz --]
[-- Type: application/octet-stream, Size: 7524 bytes --]

[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] TUI: PDCurses for eCOS

[Steven Clugston]

> -----Original Message-----
> From: ecos-discuss-owner@ecos.sourceware.org
> [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of
> Sergei Gavrikov
> Sent: 24 March 2009 00:23
> To: eCos discuss list
> Subject: [ECOS] TUI: PDCurses for eCOS
>
>
> Hi
>
> Last weekend I've done a port of PDCurses for ECOS. The whole
> curses library built for for ARM-7 is
>
> ~/PDCurses-3.4/ecos$ arm-eabi-size -t libpdcurses.a
>    text          data     bss     dec     hex filename
>    1052             0       0    1052     41c addch.o (ex
> libpdcurses.a)
>
> [snip]
>
>   42437           176    6731   49344    c0c0 (TOTALS)
>
> The PDCurses <http://pdcurses.sourceforge.net> sources are
> the very portable. I found what it's code is very compact and
> very qualitative. Compiling with -Wall produces no warnings.
> No need to mess up with the PDCurses core to port it for new
> OS.  When I started the port, I found and again re-read
> Peter's Seebach article: Porting a screen-management utility
> to eCos on IBM developerWorks
>
> http://www.ibm.com/developerworks/power/library/pa-tams3/
>
> Read the last sentence of the Peter's article, please. If I
> wrote about the PDCurses + eCos, I would resume that like
> Peter said, Executable size is unbeatable; the whole
> application is _140_KB, including kernel, drivers, curses,
> etc. And yet another important thing: I did no dance with the
> PDCurses sources like Peter did with the OpenBSD curses.
>
> I would not believe in the said the above if I could not run
> a `size' for the got executables just now (built for RAM
> startup, stripped)
>
> ~/PDCurses-3.4/ecos$ arm-eabi-size firework newdemo ptest
> rain testcurs worm xmas
>    text          data     bss     dec     hex filename
>   62612          1376   24864   88852   15b14 firework
>   67852          1456   24856   94164   16fd4 newdemo
>   66648          1368   23752   91768   16678 ptest
>   62772          1356   24796   88924   15b5c rain
>   96956          1460   24748  123164   1e11c testcurs
>   67348          1396   25404   94148   16fc4 worm
>   69852          1348   21852   93052   16b7c xmas
>
> Those are real working demos built for my target (BTW,
> `testcurs' is the 1K lines written in curses). They all work
> very smoothly, 3 colour worms creep, aa-xmas card greets me,
> it fireworks, it rains, and `testcurs' and other demos learn
> me :-) Many thanks to William McBrine for the PDCurses!
>
> And what's about a fly in the ointment? malloc, calloc, free
> and curses event loop.
>
> If anyone will want to try the port, I attached it. To build
> the port, download the latest PDCurses 3.4 sources from SF.
> Build the demos for x11 or sdl1 to taste a honey. Unpack
> `pdcecos.tar.gz' under PDCurses-3.4 tree then and follow the
> instructions in the ecos/README* files.
>
> Notes: 1) The port was tested on Linux Ubuntu 8.04 with
> Olimex LPC-E2294 board using `minicom' communication program.
> 2) I never wrote in curses, but I used `whiptail' a while
> ago, so, I won't help you on curses. 3) the port is two-days
> `weekend mechanics', so, it may be not ideal, it was my first
> look on PDCurses. 4) I do not know much about this remark
> from PDCurses's README
>
> ---->8
> The core package is in the public domain, but small portions
> of PDCurses are subject to copyright under various licenses.
> Each directory contains a README file, with a section titled
> "Distribution Status" which describes the status of the files
> in that directory.
> ---->8
>
> So, I can not answer on Q: Is it possible to enter PDCurses
> in eCos CVS tree?
>
> In any case I think that PDCurses can be the very useful
> library to build the excellent TUIs under eCos.
>
> That's it.
>
> Regards,
>
> Sergei
>

Thanks for this Sergei.

I've been wanting to do a port of a minimal console text editor something like nano or pico to eCos to do on board editing of configuration files to be storred in flash. I've not had time to look into it yet, but as nano (as far as I remember) uses ncurses, this might be just the thing to get the ball rolling.

Regards,

Steven

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] TUI: PDCurses for eCOS

[Andrew Lunn]

> I do not know much about this remark
> from PDCurses's README
> 
> ---->8
> The core package is in the public domain, but small portions of PDCurses
> are subject to copyright under various licenses.  Each directory
> contains a README file, with a section titled "Distribution Status"
> which describes the status of the files in that directory.
> ---->8
> 
> So, I can not answer on Q: Is it possible to enter PDCurses in eCos CVS
> tree?

I had a quick look at the different READMEs. The licenses should not
be a problem as far as i see.

   Andrew


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] TUI: PDCurses for eCOS

[Sergei Gavrikov]

Steven Clugston wrote:
> I've been wanting to do a port of a minimal console text editor
> something like nano or pico to eCos to do on board editing of
> configuration files to be storred in flash. I've not had time to look
> into it yet, but as nano (as far as I remember) uses ncurses, this
> might be just the thing to get the ball rolling.

I brief check the latest nano sources at the least they have

~/repo/nano$ grep -li pdcurses *
BUGS
ChangeLog.pre-2.1
NEWS

~/repo/nano/src$ grep -i pdcurses *
winio.c:#ifdef PDCURSES

Sergei

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] TUI: PDCurses for eCOS

[Sergei Gavrikov]

Andrew Lunn wrote:
> > I do not know much about this remark
> > from PDCurses's README
> > 
> > ---->8
> > The core package is in the public domain, but small portions of PDCurses
> > are subject to copyright under various licenses.  Each directory
> > contains a README file, with a section titled "Distribution Status"
> > which describes the status of the files in that directory.
> > ---->8
> > 
> > So, I can not answer on Q: Is it possible to enter PDCurses in eCos CVS
> > tree?
> 
> I had a quick look at the different READMEs. The licenses should not
> be a problem as far as i see.

Andrew, thank you.

Today I have some doubts about my implementation. One thought take me:
Had I to wrap PDC_*() interface as I did with the CYG_PDCURSES_* MACROS?
Now, it seems for me what a packing the calls in the structs was wrong.
Curses will have the extra calls. Now, I think that I would leave those
PDC_*() entries as is (i.e. as PDCurses externals). If you will have a
time, would you look at the pdecos.h then? Are there odd things there?


Sergei

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: TUI: PDCurses for eCOS

[Sergei Gavrikov]

On Tue, Mar 24, 2009 at 02:23:19AM +0200, Sergei Gavrikov wrote:
> Last weekend I've done a port of PDCurses for ECOS. The whole curses
> library built for for ARM-7 is
 
[snip]
 
> Executable size is unbeatable; the whole application is _140_KB,
> including kernel, drivers, curses, etc.
                                                          ^^^^^^^

I did a typo. All PDCurses demos ROM/RAM (stripped executables) were
under 100K.  Most of them are about 70K.

FYI: Today I tried to run the demos are built for synthetic linux target
using Savin Zlobec serial driver and I found that curses works nice via
pseudo terminal.

Andrew, at the end I decide that pdcecos.c and pdcecos_serial.inl are
odd stuff in that my package. I have no time to write generic VT100/ANSI
line driver (who have?) and I do not want to put that naive test code in
the nice package what PDCurses is. I looked at eCos 'mw' (microwindows)
and I think what I can organize 'pdcurses' package in the same maner.
There won't be any 'driver' at first under package tree. The developers
would place next curses drivers then (under 'drivers' directory), e.g.
VT100 or ANSI serial line driver, etc. See a picture the below, please.
In a common way the PDCurses 'driver' can be implemented either in a
user code space or it can be implemented as some generic driver, e.g.
FOO

ecosconfig add CYGPKG_PDCURSES
ecosconfig add CYGPKG_PDCDRIVER_FOO

What do you think about?

Sergei


Appendix

.
`-- services
    `-- curses
        `-- pdcurses
            `-- current
                |-- cdl
                |   `-- pdcurses.cdl
                |-- doc
                |   `-- intro.txt
                |-- include
                |   |-- curses.h
                |   |-- curspriv.h
                |   |-- panel.h
                |   `-- term.h
                |-- src
                |   |-- IMPLEMNT
                |   |-- README
                |   |-- demos
                |   |   |-- README
                |   |   |-- firework.c
                |   |   |-- ...
                |   |   `-- xmas.c
                |   |-- drivers
                |   |-- ecos
                |   |   |-- pdcclip.c
                |   |   |-- pdcdisp.c
                |   |   |-- pdcecos.h
                |   |   |-- pdcgetsc.c
                |   |   |-- pdckbd.c
                |   |   |-- pdcscrn.c
                |   |   |-- pdcsetsc.c
                |   |   `-- pdcutil.c
                |   `-- pdcurses
                |       |-- README
                |       |-- addch.c
                |       |-- ...
                |       |-- util.c
                |       `-- window.c
                |-- tests
                `-- utils
                    `-- manext.c


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Nano using PDCurses for eCos

[Steven Clugston]

>> Steven Clugston wrote:
>> I've been wanting to do a port of a minimal console text editor
>> something like nano or pico to eCos to do on board editing of
>> configuration files to be storred in flash. I've not had
>> time to look
>> into it yet, but as nano (as far as I remember) uses ncurses, this
>> might be just the thing to get the ball rolling.


> I brief check the latest nano sources at the least they have
>
> ~/repo/nano$ grep -li pdcurses *
> BUGS
> ChangeLog.pre-2.1
> NEWS
>
> ~/repo/nano/src$ grep -i pdcurses *
> winio.c:#ifdef PDCURSES
>
> Sergei

Hi Sergei

I've downloaded your PDCurses for eCos and I'm now able to have coloured Xmas trees and worms in minicom running from my board - thanks.

Can this be put into CVS now? Or will you keep it as a separate project?

As I mentioned before, I thought I'd have a go at getting nano to work.

I've tried version 2.0.7 from:
http://savannah.gnu.org/projects/nano

All went well until it came up against some the Linux/unix calls:

../src/files.c: In function `safe_tempfile':
../src/files.c:1156: `P_tmpdir' undeclared (first use in this function)
../src/files.c:1156: (Each undeclared identifier is reported only once
../src/files.c:1156: for each function it appears in.)
../src/files.c:1165: warning: implicit declaration of function `umask'
../src/files.c:1168: warning: implicit declaration of function `mkstemp'
../src/files.c: In function `write_file':
../src/files.c:1376: warning: implicit declaration of function `lstat'

Ok, so I created a compat.h to delcare P_tmpdir as "/tmp" and map lstat to stat in a similar way as you did for TCL a few years ago (BTW what happened with you TCl eCos port? Is it available anywhere?).

Now I've got a problem with termios, as even thought <termios.h> is included and present in the ecos install dir I still get errors:

powerpc-eabi-gcc -DHAVE_CONFIG_H -I"${BUILD_PATH}/eCos/install/include" -I"${BUILD_PATH}/src/nano/src" -I"src" -O3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/nano.d" -MT"src/nano.d" -o"src/nano.o" "../src/nano.c"
../src/nano.c: In function `finish':
../src/nano.c:583: warning: implicit declaration of function `tcsetattr'
../src/nano.c:583: `TCSANOW' undeclared (first use in this function)
<snip>

Anyway, that's my progress so far.

Also there's still the issue of no input support in the dummy pdcurses driver yet which makes nano a bit limited in use...

Regards,
Steven

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Nano using PDCurses for eCos

[Sergei Gavrikov]

[-- Attachment #1: Type: text/plain, Size: 4430 bytes --]

Steven Clugston wrote:
> 
> >> Steven Clugston wrote:
> >> I've been wanting to do a port of a minimal console text editor
> >> something like nano or pico to eCos to do on board editing of
> >> configuration files to be storred in flash. I've not had
> >> time to look
> >> into it yet, but as nano (as far as I remember) uses ncurses, this
> >> might be just the thing to get the ball rolling.
> 
> 
> > I brief check the latest nano sources at the least they have
> >
> > ~/repo/nano$ grep -li pdcurses *
> > BUGS
> > ChangeLog.pre-2.1
> > NEWS
> >
> > ~/repo/nano/src$ grep -i pdcurses *
> > winio.c:#ifdef PDCURSES
> >
> > Sergei
> 
> Hi Sergei
> 
> I've downloaded your PDCurses for eCos and I'm now able to have coloured Xmas trees and worms in minicom running from my board - thanks.
> 
> Can this be put into CVS now? Or will you keep it as a separate project?

Hi Steven

I'm not going to maintain PDCurses package for eCos as a separate
project. I have FSF agreement and I posted the announce in the
ecos-patches list via eCos bugzilla engine
http://ecos.sourceware.org/ml/ecos-patches/2009-04/msg00009.html
So, I must be a patient. And I hope after some discussion the package in
that or another look can be committed in CVS. As Andrew said, he did not
saw the copyright issues with PDCurses itself. So, I hope, that will
happen.

> As I mentioned before, I thought I'd have a go at getting nano to work.
> 
> I've tried version 2.0.7 from:
> http://savannah.gnu.org/projects/nano
> 
> All went well until it came up against some the Linux/unix calls:
> 
> ../src/files.c: In function `safe_tempfile':
> ../src/files.c:1156: `P_tmpdir' undeclared (first use in this function)
> ../src/files.c:1156: (Each undeclared identifier is reported only once
> ../src/files.c:1156: for each function it appears in.)
> ../src/files.c:1165: warning: implicit declaration of function `umask'
> ../src/files.c:1168: warning: implicit declaration of function `mkstemp'
> ../src/files.c: In function `write_file':
> ../src/files.c:1376: warning: implicit declaration of function `lstat'
> 
> Ok, so I created a compat.h to delcare P_tmpdir as "/tmp" and map lstat to stat in a similar way as you did for TCL a few years ago (BTW what happened with you TCl eCos port? Is it available anywhere?).

That was yet another weekend mechanic. I just ran John Osterhout Tcl 6.7
on my small foot-print target. A community right decided that Jim is a
more suitable for embedded. But, I liked that Tcl 6.7 experience.

> Now I've got a problem with termios, as even thought <termios.h> is included and present in the ecos install dir I still get errors:
> 
> powerpc-eabi-gcc -DHAVE_CONFIG_H -I"${BUILD_PATH}/eCos/install/include" -I"${BUILD_PATH}/src/nano/src" -I"src" -O3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/nano.d" -MT"src/nano.d" -o"src/nano.o" "../src/nano.c"
> ../src/nano.c: In function `finish':
> ../src/nano.c:583: warning: implicit declaration of function `tcsetattr'
> ../src/nano.c:583: `TCSANOW' undeclared (first use in this function)
> <snip>

Hm,

$ find $ECOS_REPOSITORY -type f -name \*.h -print0|xargs -0 grep -l TCSANOW
/home/sg/repo/devo/ecos/packages/isoinfra/current/include/termios.h

check `-I' pathes and eCos `ifdefs'.

> Anyway, that's my progress so far.
> 
> Also there's still the issue of no input support in the dummy pdcurses driver yet which makes nano a bit limited in use...

http://bitbucket.org/tickling/pdcurses4ecos/src/
http://bitbucket.org/tickling/pdcurses4ecos/src/tip/synth-gdb.txt


My first implementation for my own tests supported and input on the test
serial port just to interact with the demos. I did not use termios, but
eCos raw serial non-blocked i/o. I rejected those 3 functions from that
job (see an attachment). It was done just to interact with PDCurses
demos, no more. I used synthetic serial driver from Savin Zlobec, and
"nullmodem" from Jürgen Rinas, and minicom on pseudo tty. It worked. The
demos ran and on one my ARM target too.

IMHO

If you just want to edit config files, it's better to implement own
editor, call it `femto' then :-) http://en.wikipedia.org/wiki/SI_prefix
It seems for me that nano is enough bloat stuff for eCos targets. But
this my opinion, only.


Regards,

Sergei

> Regards,
> Steven
> 
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[-- Attachment #2: snip.c --]
[-- Type: text/x-csrc, Size: 1997 bytes --]

static cyg_io_handle_t ser = NULL;

bool
PDC_check_key(void)
{
    cyg_uint32      len;
    cyg_serial_buf_info_t dev_buf_conf;

    len = sizeof(dev_buf_conf);
    cyg_io_get_config(ser, CYG_IO_GET_CONFIG_SERIAL_BUFFER_INFO,
                      &dev_buf_conf, &len);

    return (dev_buf_conf.rx_count > 0);
}

void
PDC_flushinp(void)
{
    cyg_io_get_config(ser, CYG_IO_GET_CONFIG_SERIAL_INPUT_FLUSH, NULL,
                      NULL);
}

// Note: 115200,n,8,1 did let me to collect the multi-bytes sequences on a
//       kbhit in such a simple form. It's ugly, but it worked.
int
PDC_get_key(void)
{
    cyg_uint32      buf;
    cyg_uint32      len = 4;

    cyg_io_read(ser, &buf, &len);

    // A very few support for PDCurses demos only
    switch (buf) {
        // ^[[ ... PC cursor movement keys
    case 0x415b1b:
        return KEY_UP;
    case 0x425b1b:
        return KEY_DOWN;
    case 0x435b1b:
        return KEY_RIGHT;
    case 0x445b1b:
        return KEY_LEFT;
        // Tuidemo wants 'Alt-X'
    case 0x581b:
    case 0x781b:
        return ALT_X;
    }
    // Nothing more
    return buf & 0xff;
}

static int      ttyline_set = false;
int
PDC_scr_open(int argc, char **argv)
{
    if (!ttyline_set) {
        cyg_uint32      wait = 0;
        cyg_uint32      len = 4;

        if (ENOERR != cyg_io_lookup(PDC_SERIAL_DEVICE, &ser))
            return ERR;
        if (ENOERR != cyg_io_set_config(ser,
                                        CYG_IO_SET_CONFIG_READ_BLOCKING,
                                        &wait, &len))
            return ERR;
        if (ENOERR != cyg_io_set_config(ser,
                                        CYG_IO_SET_CONFIG_WRITE_BLOCKING,
                                        &wait, &len))
            return ERR;

        ttyline_set = true;
    }

    SP = calloc(1, sizeof(SCREEN));

    if (!SP)
        return ERR;

    SP->cols = PDC_get_columns();
    SP->lines = PDC_get_rows();
    SP->cursrow = SP->curscol = 0;

    // ...
}


[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Nano using PDCurses for eCos

[Sergei Gavrikov]

Sergei Gavrikov wrote:
> Steven Clugston wrote:

[ snip ]

> > As I mentioned before, I thought I'd have a go at getting nano to work.
> > 
> > I've tried version 2.0.7 from:
> > http://savannah.gnu.org/projects/nano

Hello

Yesterday evening I did grab the latest stable nano sources (2.0.9) from
here http://www.nano-editor.org, and tried to build it. After configure
and some tweaks I got The GNU nano editor for the eCos i386linux target
just in 110K using those PDCurses package and dummy driver.

> If you just want to edit config files, it's better to implement own
> editor, call it `femto' then :-) http://en.wikipedia.org/wiki/SI_prefix
> It seems for me that nano is enough bloat stuff for eCos targets.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I should not have told about until a try. Steven, I have to finalize and
test the build (at the least using eCos FS_RAM), I have to add the real
terminal driver to PDCurses. I do hope this will occur the next weekend
and then I will share a full story somewere on the web (some guys are
nervious if they cannot read here only a digest about eCos kernel gears
and cpu parts :-) There are a few hints the below

I configured the nano as: --enable-tiny --disable-nls --disable-utf8; I
have a bit tweaked config.h to point on that which things are absent in
eCos, made a peace with Linux/GNU (pwd, mkstemp, signals, getopt) and I
got the executable. There is alone rule in my eCos Makefile

    ACTUAL_CFLAGS := $(subst , -DHAVE_CONFIG_H=1,$(ACTUAL_CFLAGS))


Sergei

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Nano using PDCurses for eCos

[Sergei Gavrikov]

[-- Attachment #1: Type: text/plain, Size: 3750 bytes --]

Steven Clugston wrote:
> Sergei Gavrikov wrote:
> > If you just want to edit config files, it's better to implement own
> > editor, call it `femto' then :-)
> > http://en.wikipedia.org/wiki/SI_prefix
> > It seems for me that nano is enough bloat stuff for eCos targets.
> 
> Nano does far more than I realised and I agree that most of it is
> bloat for what I need like calls to external programs for spell checking
> and wide character and NLS support etc, but it's a choice between writing
> an editor from scratch or hacking nano to work by disabling the bloat
> using its existing config mechanism. I think the latter should take less
> time/effort. It's a shame there's not a #define NANO_FEMTO mode to strip
> off even more than NANY_TINY does.

[snip]

> Sergei Gavrikov wrote:

[snip]

> > When I will get a far progress with Nano/PDCurses I wil let you know.

Hello Steven,

Let moderators excuse this post. At first, I thought to write you
personally, but, then I thought, Why not here? More that one guy did
share own eCos shell here:
http://sourceware.org/ml/ecos-discuss/2006-10/msg00141.html

And it seemed for me that our thread is a shell-related thread. You told
about your needs to edit config files and yesterday I thought, Why do
not write and send e-mails using SMTP with nano like pine does it using
pico :-) A hundred of kb is not issue for PC target, for example.  What
curses program does at all? The curses program the mostly sleeps.  IMHO,
curses is not bad thing for eCos. So, why do not benefit our experience
with other eCosers? IMHO, TCL shell or PDCurses shell is more powerful
thing than just "while(1) cyg_io_read(...);" It is a portable way to
get the shells.

I have got some results on "femto". Today I put nano-2.0.9 under local
mercurial repository and cleaned up all my tweks.

(1) My "femto" config.h version and my tweaks let me build the nano
    without eCos POSIX package. Instead I add CYGPKG_LINUX_COMPAT (just
    to get headers). AFAIK, some eCos FS packages depend on it (e.g,
    it's possible to add FS_FAT, FS_JFFS2 without bloat CYGPKG_POSIX).
    My config.h let me build nano without Unix stuff at all
    
    arm-eabi-nm src/nano | grep -E "T (wait|fork|exec)"
    (no output)

    For my config I have got only 5 stubs: getpwuid(), getpwent(),
    endpwent(), umask() and mkstemp().

(2) About POSIX signals. There were exactly two functions in nano.c:
    signal_init() and do_suspend() for my config. Both of the functions
    depend on TOGGLE_SUSPEND_KEY and NANO_SUSPEND_KEY. But what is "^Z"
    for the eCos World? We can quite ignore those handlers.

(3) My eCos config was

    Template: default
    Added:
     CYGPKG_IO_FILEIO
     CYGPKG_FS_RAM
     CYGPKG_LINUX_COMPAT
     CYGPKG_PDCURSES
    Removed:
     CYGPKG_LIBM

    and it did let me get "The GNU nano" for ARM target as

   text	   data	    bss	    dec	    hex	filename
 123384	   1408	  24256	 149048	  24638	src/nano


(4) I add getopt.[ch] under compat directory. And the nano the above
    contains it. I think you are right: it would not bad to prepare
    something like CYGPKG_SERVICES_GNU_GETOPT. It seems for me that
    today's eCos license let us do it. And, perhaps, you are right when
    said about CDL against getopt.

(5) My tweaks of nano/src seem itself the very minimal (only nano.h,
    and nano.c were tweaked), look at an attached nano.diff.  It was
    surprise for me. But, now I do not know what will happen if someone
    will turn on an external spell checkeri, for example, in my config.h 

I attach all stuff (including used getopt) to get "femto" under eCos. I
will put all on bitbucked then. If anyone is interested in any CLI under
eCos, he/she can use our experience.

Regards,

Sergei

[-- Attachment #2: nano-ecos-hack.tar.gz --]
[-- Type: application/octet-stream, Size: 14315 bytes --]

[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Nano using PDCurses for eCos

[Steven Clugston]

[-- Attachment #1: Type: text/plain, Size: 3352 bytes --]

> If you just want to edit config files, it's better to implement own
> editor, call it `femto' then :-)
> http://en.wikipedia.org/wiki/SI_prefix
> It seems for me that nano is enough bloat stuff for eCos targets.

Nano does far more than I realised and I agree that most of it is bloat for what I need like calls to external programs for spell checking and wide character and NLS support etc, but it's a choice between writing an editor from scratch or hacking nano to work by disabling the bloat using its existing config mechanism. I think the latter should take less time/effort. It's a shame there's not a #define NANO_FEMTO mode to strip off even more than NANY_TINY does.

> Yesterday evening I did grab the latest stable nano sources (2.0.9)
> from here http://www.nano-editor.org, and tried to  > build it. After
> configure and some tweaks I got The GNU nano editor for the eCos
> i386linux target just in 110K using those PDCurses package and dummy
> driver.

> I should not have told about until a try. Steven, I have to finalize
> and test the build (at the least using eCos
> FS_RAM), I have to add the real terminal driver to PDCurses. I do hope this will occur the next weekend and then I will
> share a full story somewere on the web (some guys are nervious if they cannot read here only a digest about eCos kernel
> gears and cpu parts :-) There are a few hints the below

I know this is bordering on another general programming discussion, but its because of the issues which ecos throws up that I'm discussing it and it just might interest some other ecos user out there one day.

> I configured the nano as: --enable-tiny --disable-nls --disable-utf8;
> I have a bit tweaked config.h to point on that
> which things are absent in eCos, made a peace with Linux/GNU (pwd, mkstemp, signals, getopt) and I got the executable.
> There is alone rule in my eCos Makefile

>    ACTUAL_CFLAGS := $(subst , -DHAVE_CONFIG_H=1,$(ACTUAL_CFLAGS))

I've actually got nano 2.0.7 to compile to a binary with modifying any of the actual nano source. It seems to run on my PowerPC board now. I can't tell if it works yet as it doesn't accept any input, but the main screen fires up. For some reason my raw binary is around 413Kb which seems quite big, but I probably could have disabled more stuff in CDL like unneeded hardware packages.

Here's what I did:

I just ran configure on the source in Linux to get the basic config.h file and then modified that to disable most headers and things that are not present in ecos and enabled NANO_TINY as well.

To get the termios stuff and unix signals to compile I had to use the POSIX compatibility layer package and enable POSIX signals and disable the ISO C signals infrastructure.

I made a compat.h and compat.c to replace the missing function calls with dummy ones like you did with your TCL experiment.

I also 'borrowed' the GNU/Linux versions of strnlen.c and getopt.c for now. There's a CDL option to supply comandline args to main{}, so maybe an ecos implementation of getopt() might be useful to have in a compatability package or something.

No doubt that it will come off the rails as soon as it hits one of the dummy calls, but hopefully with some more work it will be able to load a file off a jffs2 partition, edit it, and save it back.

Steven


[-- Attachment #2: compat.c --]
[-- Type: text/plain, Size: 880 bytes --]

#include <errno.h>
#include "compat.h"

int lstat(const char* f,struct stat* b){return stat(f,b);}
mode_t umask(mode_t mask){errno=ENOTSUP;return(-1);}
int execvp(){errno=ENOTSUP;return(-1);}
int execlp(const char *file, const char *arg, ...){errno=ENOTSUP;return(-1);}
pid_t fork(){errno=ENOTSUP;return(-1);}
//kill(){errno=ENOTSUP;return(-1);}
pid_t wait(int status){CYG_UNUSED_PARAM(int,status);errno=ENOTSUP;return(-1);}
int pipe(int pipefd[2]){errno=ENOTSUP;return(-1);}
char *mktemp(char *template){errno=ENOTSUP;return(0);}
int mkstemp(char *template){errno=ENOTSUP;return(0);}
struct passwd *getpwnam(){errno=ENOTSUP;return(0);}
struct passwd *getpwent(void){errno=ENOTSUP;return(0);}
struct passwd *getpwuid(uid_t uid){CYG_UNUSED_PARAM(uid_t,uid);errno=ENOTSUP; return(0);}
pid_t waitpid(pid_t pid, int *status, int options){errno=ENOTSUP;return(-1);};
void endpwent(){}

[-- Attachment #3: compat.h --]
[-- Type: text/plain, Size: 1223 bytes --]

#ifndef CYGONCE_NANO_COMPAT_H
#define CYGONCE_NANO_COMPAT_H
//#include <errno.h>
//#include <unistd.h>
#include <sys/stat.h>
struct passwd
{
};

#define P_tmpdir "/tmp"
#define   SIGCONT         18      /* Continue (POSIX).  */
#define SIGSTOP         19      /* Stop, unblockable (POSIX).  */
#define   SIGTSTP         20      /* Keyboard stop (POSIX).  */

int getopt(int argc, char * const argv[], const char *optstring);
size_t strnlen(const char *s, size_t maxlen);
extern char *optarg;
extern int optind, opterr, optopt;

//isascii(c){return((unsigned)(c)<=0200);}
int lstat(const char* f,struct stat* b);
mode_t umask(mode_t mask);

//readlink(p,b,s){int 
//n,f;if(f=open(p,1)==-1)return(-1);n=read(f,b,s);close(f);return(n);}
//char *mktemp(char *template);
int mkstemp(char *template);
//struct passwd *getpwnam(const char *name);
struct passwd *getpwent(void);
void endpwent(void);
struct passwd *getpwuid(uid_t uid);
//int execvp(const char *file, char *const argv[]);
int execlp(const char *file, const char *arg, ...);
pid_t fork(void);
//kill(){errno=ENOTSUP;return(-1);}
//pid_t wait(int *status);
pid_t waitpid(pid_t pid, int *status, int options);
//int pipe(int pipefd[2]);
#endif //CYGONCE_NANO_COMPAT_H

[-- Attachment #4: Type: text/plain, Size: 148 bytes --]

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss