Chuck McManis wrote:
At 06:56 AM 2/26/2007, Gary Thomas wrote:
> Try putting these functions into 'main()', which is called
> with a proper thread environment and the kernel+interrupts
> running.
I read this and it reminded me of a question I had, if you have a
pointer I'd be grateful for it.
Basically when I got the HTTP server to run I did so by loading and
running the httpd1 test program and noting that it worked fine. Then I
tried to run a "main" program and the web server simultaneously.
Basically I added:
So I had this simple bit of code:
----------------------- bit of lame included code ------------------------
#include <stdio.h>
#include <network.h>
/*
* Note this is for backward compatibility we don't really
* think that ECOS will call main, it calls cyg_start and
* that function will call main.
*/
int
main(int argc, char *argv[]) {
char buf[2048];
printf("Welcome to the ECOS world!\n");
while (1) {
printf("Enter some text: ");
gets(buf);
printf("'%s'\n", buf);
}
exit (0);
}
/*
* This was mostly stolen from the HTTPD test
*/
#define STACK_SIZE (8192 + 0x1000)
static char stack[STACK_SIZE];
static cyg_thread thread_data;
static cyg_handle_t thread_handle;
void
user_thread(cyg_addrword_t p) {
diag_printf("Startup code for ECOS is running...\n");
init_all_network_interfaces();
/*
main(1, aa);
*/
}
void
cyg_user_start(void) {
cyg_thread_create(10, // Priority - just a number
user_thread, // entry
0, // entry parameter
"simple httpd", // Name
&stack[0], // Stack
STACK_SIZE, // Size
&thread_handle, // Handle
&thread_data // Thread data structure
);
cyg_thread_resume(thread_handle); // Start it
cyg_scheduler_start();
}
----------------------- end of lame included code
---------------------------
And it has a really weird way of working. Basically what happens is that
somehow, main() gets called anyway and runs. And frankly I can't figure
out how it gets called, but even stranger, its interaction with the
console blocks the networking stack's attempt to print the result of
running DHCP which keeps the web server from running. (it nicely
demonstrates the Rhine "feature" of resetting CR0 however if you don't
service received packets ;-)
So what I was looking for, and could not find, was sort of a crt0 type
file which would provide "the proper thread environment + kernel and
interrupts running" which would include starting a thread by calling
'main()'. That way I could keep eCos code fairly segregated from my
"application" which normally would run as a process on a UNIX or Linux
machine.
Thoughts? Should I just create two threads? Will they still interfere
with each other's use of the console?
Your problem is not with the form of your code; it's fine.
The problem has to do with the console device. The default console
device is the debug device, normally provided by RedBoot via the
virtual vector interface. This interface is not interrupt driven,
thus when you ask to read from it, everything comes to a grinding
halt. To avoid this, you need to set up your console stream to
an interrupt driven device, which will require enabling the appropriate
serial driver.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
