Closing Ethernet

[Leon Pollak]

On Tuesday October 21 2008, Ed Sutter wrote:
> > Hmmm... AFAIK, as uMon does only polling, there should be no problems
> > with Ethernet still "active", no? Well, only if you use the uMon RAM for
> > the application...
> > What I do is: I leave 0-64KB RAM for uMon purposes and load the
> > application to the 0x10000 address. Thus DMA may continue to write its
> > data.
> >
> > But I have the problem returning to uMon from the application - the RTEMS
> > driver does use interrupts.
> >
> > As for just now, I simply zero some FEC registers before exiting in the
> > application, but this is not good, as this work must be done by the
> > driver.
>
> Fellers,
> Prior to running your application, issued the command "ether off" at the
> uMon prompt.  That will turn down the ethernet interface (assuming the
> driver is written properly) and then, if you're using the uMon API within
> RTEMS, it will not interfere with the RTEMS driver.
> Or, if you are using the uMon api in RTEMS, you can do this:
> mon_docommand("ether off",0);
> from within your application at startup.
> Ed

Hello, Ed.

1.Just curious: taking into account my memory distribution, do you think that 
there still may be a problem?

2. Using this opportunity: I think about adding to uMon the ability to manage 
the non-cached RAM. I mean, that when the RAM is divided into cached and 
non-cached, and uMon already uses non-cached for its drivers purposes, it 
seems to be natural for uMon to continue to manage all the non-cached RAM for 
application too (via mon_portcmd, for example).

Can you recommend something in uMon to manage the non-cached region?


Thanks ahead and best regards.

-- 
            Dr.Leon M.Pollak
                Director
       PLR Information Systems Ltd.
Tel.:+972-98657670  |  POB 8130, H'Aomanut 9,
Fax.:+972-98657621  |  Poleg Industrial Zone,
Mob.:+972-544739246 |  Netanya, 42160, Israel.