SH Question

[Fernando RUIZ]

Hi Ralf,

First. Happy new year.

Second.
All of this that you says has been supossed by myself.

I don't want to disturb you if my sugesstions can do it.

The real life with the embedded programing is a litlte bit more
complicated that the EVB.

The first step with new boards is set the leds onboard. After
makes a "console" device to give the life at the board.

Can anybody think in a BSP without "console" to start a board?

I have usually one serial port like "liason" with the world.

I need implement a network serial protocol because I need transfer memory,
spy the "kernel" and open remote consoles into the new board.
All in the same link at the same time.

After of this I can run the new devices.

At the end I can stop the /dev/console device.
But always I let a DEBUG flag directed to console in all the modules.


The RTEMS BSP generic are for general purpose but a real purpose.

I have an developement with 8 interrupts every 250 usecs each one.
Can I think to use sh_set_irq_priority() to lock each interruput every time?

I think better about

/*
 * ****************************************
 * INTC Programming
 * ****************************************
 */

typedef struct {
 unsigned char _IRQ0:4;
 unsigned char _IRQ1:4;
 unsigned char _IRQ2:4;
 unsigned char _IRQ3:4;
 unsigned short ___:16;
} TIPRA;

#define INTC_IPRA_IRQ0	 (((volatile TIPRA *)(INTC_IPRA))->_IRQ0)
#define INTC_IPRA_IRQ1	 (((volatile TIPRA *)(INTC_IPRA))->_IRQ1)
#define INTC_IPRA_IRQ2	 (((volatile TIPRA *)(INTC_IPRA))->_IRQ2)
#define INTC_IPRA_IRQ3	 (((volatile TIPRA *)(INTC_IPRA))->_IRQ3)

/*
 *
 * Priority Level IRQ's for an easy use.
 *
 */

#define PL_IRQ0        INTC_IPRA_IRQ0
#define PL_IRQ1        INTC_IPRA_IRQ1
#define PL_IRQ2        INTC_IPRA_IRQ2
#define PL_IRQ3        INTC_IPRA_IRQ3

#define LV_IRQ0        8



PL_IRQ0=0;        /* LOCK THE IRQ */
countirq++;
PL_IRQ0=LV_IRQ0;  /* UNLOCK THE IRQ */

Can you imaginate

sh_set_irq_priority(IRQ0_ISP_V,0);
countirq0++;
sh_set_irq_priority(IRQ0_ISP_V,LV_IRQ0);

runnig in a too busy system?

If I want a real software is necesary build a real software not academic.

Which is the final objectif for RTEMS? Build a real robust and stable
software?

/dev/console is a "necesary" device in the real developements.

Multics was a wonderful OS but UNIX was the final implementation.


/*
 * /dev/console for Hitachi SH 703X
 *
 * The SH doesn't have a designated console device. Therefore we "alias"
 * another device as /dev/console and revector all calls to /dev/console
 * to this device.
 *
 * This approach is similar to installing a sym-link from one device to
 * another device. If rtems once will support sym-links for devices files,
 * this implementation could be dropped.
 *
 *  Author: Ralf Corsepius (corsepiu at faw.uni-ulm.de)

Now, The moment to drop this implementation and update the software.

Why don't have a termios console with the sci ports?

We can run all the termios software already developped in RTEMS sh
implementation.

If we have a null driver and we make a link to device console all your
problem is resolved.

All the debug output is redirected to dummy.

The best solution for evolution is build a new version in beta phase.
Put it to discuss and make a alfa version.
I think that it is your opinion based in your comments.


Best regards.

Fernando RUIZ CASAS.
correo at fernando-ruiz.com
fernando.ruiz at ctv.es




> -----Mensaje original-----
> De: corsepiu [mailto:corsepiu]En nombre de Ralf Corsepius
> Enviado el: sabado, 30 de diciembre de 2000 22:24
> Para: joel.sherrill at OARcorp.com
> CC: correo at fernando-ruiz.com; Rtems-Users (E-mail)
> Asunto: Re: SH Question
>
>
> Joel Sherrill wrote:
> >
> > Fernando RUIZ CASAS wrote:
> > >
> > > Joel Sherrill wrote:
> > > > I would also think that the /dev/null driver could be moved to a
> > > > non-SH directory.
>
> > > /dev/null is for a simulated link to console because the
> hard links are not
> > > present
> > > when Ralf(?) writed it. (I suppose)
> Yep, it was me who introduced it (It is a moderately modified copy
> of the test suite's stub driver). And you are right, RTEMS did not
> have any filesystem when this was introduced.
>
> > > /dev/null is better to place it with /dev/stub in (?).
> No. /dev/null is supposed to be what its name says: /dev/null
>
> What we did when porting the RTEMS to the SH1 was to redirect RTEMS
> /dev/console to /dev/null, similarily to using a symlink/hardlink
> from /dev/console to /dev/null under unix, but without having nor
> _needing_ a filesystem (SH1 are low memory systems :).
>
> We did so, because we wanted to be able to
> * run RTEMS without having a physical console attached.
> * run RTEMS without having to assign _any_ physical device to a
> /dev/console.
> * run RTEMS without having _any_ console driver.
> * and wanted to be able to assign different physical devices to
> /dev/console but serial devices.
>
> Furthermore, in general, many embedded systems do not have any
> console device, however RTEMS currently (IMO: incorrectly) assumes a
> console always to be present.
>
> >
> > /dev/stub is a test fixture and is in the test source tree.
> > I think /dev/null could go in libmisc without too much
> > worry.
> I wholeheartily agree.
>
> Ralf
>
> --
> Ralf Corsepius
> Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
> (FAW)
> Helmholtzstr. 16, 89081 Ulm, Germany     Tel: +49/731/501-8690
> mailto:corsepiu at faw.uni-ulm.de           FAX: +49/731/501-999
> http://www.faw.uni-ulm.de
>