some newbie questions

[sebastian ssmoller]

On Fri, 13 Feb 2004 15:46:42 -0500 (EST)
gregory.menke at gsfc.nasa.gov wrote:

> 
> sebastian ssmoller writes:
>  > 
>  > sure :)
>  > i am looking at c/src/lib/libbsp/m68k/gen68360/console/console.c
>  > and its
>  > dependencies (esp. m68360.h). i find that code easy to read in and
>  > that 
>  > helps a lot. the problem is that there are a lot of references to
>  > other
>  > parts of the os. 
>  > e.g.: m68360.h defines a struct m360_t and a variable m360 in this
>  > way: extern volatile m360_t m360;
>  > cause m360 is defined extern there must by some definition of that
>  > variable, right ? so i grep'ed the whole source tree but havnt
>  > found
>  > that definition yet.
> 
> Be sure to check at the top level, down in c/src or below misses a
> whole bunch of OS content (most of it in fact).  I don't believe an
> extern requires the variable actually be used- be sure to check ALL
> files, not just .c- its quite amazing where some things end up.
> 

i guess i did. what i do is the following:
$ cd /path/to/rtems (rtems-ss-20030703)
$ ls 
COPYING           README.cdn-X      c                 install-sh
ChangeLog         README.configure  config-ml.in      make
INSTALL           SUPPORT           config.guess      mdate-sh
LICENSE           VERSION           config.sub        missing
LICENSE.NET       acinclude.m4      configure         mkinstalldirs
LICENSE.RPCXDR    aclocal           configure.ac      scripts
LICENSE.WEBSERVER aclocal.m4        contrib           texinfo.tex
Makefile.am       autom4te.cache    cpukit            tools
Makefile.in       automake          depcomp
README            bootstrap         doc
$ grep -r m360_t *
cpukit/score/cpu/m68k/m68360.h:} m360_t;
cpukit/score/cpu/m68k/m68360.h:extern volatile m360_t m360;


this variable (m360) is havily used in console.c. so it must be defined
somewhere, or not ?



> 
>  > another question: how often is the interrupt-handler called ? each
>  > time
>  > a new byte is received via serial port ? 
> 
> As always, it depends.  If the console port is interrupt driven, then
> yes- once per char.  Not all consoles are, the MongooseV bsp uses a
> polled uart because of interrupt servicing overhead.
> 

ok. thx

>  
>  > 
>  > ok i will think about that. i am not sure if this is an option for
>  > me. i
>  > will have a deeper look at this stuff. thx
>  
> Please give an example of various events you would use to schedule
> tasks.  
> 
> If you're trying to schedule tasks as a consequence of receiving
> particular CAN messages, that is very much a userspace issue.  Perhaps
> a driver could be written allowing the user to provide tasks that are
> associated with CAN messages, but that has nothing directly to do with
> the OS scheduler.  Each task would sleep until awoken by the interrupt
> service routine the message the task is waiting for is received- the
> rtems event signalling primitives would be suitable for that.
> 

sounds interesting. thats exactly what i wonna do. i try to schedule the
system (the tasks) via CAN messages.


>   
>  > (...)
>  > > 
>  > > "sending messages" is too vague as far as integrating with the
>  > > kernel.
>  > > There's nothing stopping you from implementing a CAN driver via a
>  > > /proc file and interacting with it via file handles- just like
>  > > Linux,
>  > > etc does.  Its a bit easier to put that stuff in your application
>  > > until you have something general purpose enough to make a device
>  > > driver.  OTOH, if you do implement some kind of CAN hardware
>  > > support,
>  > > then the RTEMS community would very much welcome its inclusion in
>  > > the
>  > > source tree.
>  > > 
>  > 
>  > what i need is a driver which supports sending and reveiving CAN
>  > frames.
>  > therefore i need an interrupt handler, too. in general a CAN driver
>  > depends on the vendor specific "implementation" of the CAN spec. 
>  > i use TIP816 from "Tews datentechnik".
>  > because of this hardware dependencies in unix like OSes i would put
>  > such
>  > a driver into kernel space.
>  > 
> 
> bsp's offer various forms of interrupt vector management- you supply
> some form of interrupt descriptor (usually a #define representing a
> particular interrupt vector), and a C routine to call when the
> interrupt occurs- RTEMS handles the context save/restores, your code
> just manipulates the device hardware.  Some bsp's use the simple
> vectoring concept that RTEMS supplies by default, others get fancier.
> If you track down how your bsp sets up the clock tick interrupt,
> you'll get a hint as to how that bsp handles vectors.  There is no
> alternative to knowing how the device in question is wired to the
> interrupt control unit on the processor.  If you can't answer that
> question, you can't choose the right interrupt vector for your driver.
> RTEMS bsp's that support PCI subsystems make that task easier for the
> user.
> 
> Remember, RTEMS is very efficient at context switching, so its
> entirely reasonable to poll hardware in a high priority task thats
> woken up by the user whenever something should happen.  The network
> drivers take this approach- along with various forms of interrupt
> service routines.
> 
> I'd suggest implementing your driver in user code, calling it directly
> to do things until it has a coherent interface thats suited for
> inclusion as an OS driver.  RTEMS does not distinguish between kernel
> and user space- there is no trap interface or "kernel mode".  The
> terms are used loosely to represent RTEMS OS code vs user code- but it
> all runs in one flat address space.
> 

ok. again thx for all these helpful info.

regards,
seb

> Gregm
> 


-- 
Microsoft: Where do you want to go today?
Linux: Where do you want to go tomorrow?
FreeBSD: Are you guys coming or what?
OpenBSD: Hey guys you left some holes out there!