leonp at plris.com
Tue Oct 21 21:16:51 UTC 2008
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.
> 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.
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.
PLR Information Systems Ltd.
Tel.:+972-98657670 | POB 8130, H'Aomanut 9,
Fax.:+972-98657621 | Poleg Industrial Zone,
Mob.:+972-544739246 | Netanya, 42160, Israel.
More information about the users