This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: function pointer in a thread
- From: Andrew Lunn <andrew at lunn dot ch>
- To: Michele Paselli <triguelon at gmail dot com>
- Cc: ecos-discuss at ecos dot sourceware dot org
- Date: Tue, 24 Jul 2007 13:24:55 +0200
- Subject: Re: [ECOS] function pointer in a thread
- References: <68185b500707230626l680b776fm4bb1cfdf0713dceb@mail.gmail.com>
On Mon, Jul 23, 2007 at 03:26:41PM +0200, Michele Paselli wrote:
> Hi all,
>
> I'm trying to build a small and simple network stack for raw
> networking. After investigating a bit the existing stacks (in
> particular lwip, which is more simple than the bsd implementation) I
> found that in the init phase a new thread is started ("Network
> Delivery Thread"). In particular the thread always waits for a
> semaphore, which is posted by the dsr every time a packet is received,
> and then calls the deliver function. The thread is the same as the
> lwip implementatiom, I just added few printf:
>
> //Input thread signalled by DSR calls deliver() on low level drivers
> static void raweth_thread(void *arg)
> {
> cyg_netdevtab_entry_t *t;
>
> for (;;) {
> cyg_semaphore_wait(&delivery);
> for (t = &__RAWDEVTAB__[0]; t != &__RAWDEVTAB_END__; t++) {
> struct eth_drv_sc *sc = (struct eth_drv_sc *)t->device_instance;
> if (sc->state & ETH_DRV_NEEDS_DELIVERY) {
> #if defined(CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT)
> cyg_bool was_ctrlc_int;
> #endif
> sc->state &= ~ETH_DRV_NEEDS_DELIVERY;
> #if defined(CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT)
> diag_printf("int_vector function @ 0x%x, sc @
> 0x%x\n",sc->funs->int_vector,sc);
> was_ctrlc_int = HAL_CTRLC_CHECK((*sc->funs->int_vector)(sc), (int)sc);
> diag_printf("deliver fucntion @ 0x%x\n",sc->funs->deliver);
> if (!was_ctrlc_int) // Fall through and run normal code
> #endif
> (sc->funs->deliver) (sc);
> }
> }
> }
> }
>
> When I start the application for the first ethernet packet received I got
> this:
>
> int_vector function @ 0x43210, sc @ 0x5a2dc
> deliver fucntion @ 0x431cc
>
> but when a second packet is received this is what I get:
>
> int_vector function @ 0x1fff20e5, sc @ 0x5a2dc
Check to see if HAL_CTRLC_CHECK() changes SC. Is 0x1fff20e5 somewhere
in ROM? Is it inside Redboot?
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