* RE: [ECOS] Strange Problem in cyg_thread_delay( )?
@ 2001-04-23 5:24 Nielsen Linus
0 siblings, 0 replies; 7+ messages in thread
From: Nielsen Linus @ 2001-04-23 5:24 UTC (permalink / raw)
To: eCos
Hi!
I don't know much about your target, but I have a few questions:
- Is the LED port really an integer, and if so, are all the other bits
supposed to be cleared every time?
- Do you have a watchdog?
- What do you mean by "halted forever" and "die"?
/Linus
> -----Original Message-----
> From: Huang Qiang [ mailto:jameshq@liverpool.ac.uk ]
> Sent: den 23 april 2001 13:47
> To: eCos
> Subject: RE: [ECOS] Strange Problem in cyg_thread_delay( )?
>
>
>
> My code listed as bellow:
> ...
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: [ECOS] Strange Problem in cyg_thread_delay( )?
@ 2001-04-23 4:46 Huang Qiang
2001-04-24 20:18 ` Andrew Lunn
0 siblings, 1 reply; 7+ messages in thread
From: Huang Qiang @ 2001-04-23 4:46 UTC (permalink / raw)
To: eCos
My code listed as bellow:
****************************************************************************
**************************
****************************************************************************
**************************
#define IOPDATA ((volatile unsigned *)(0x03FF5008)) // define the LED
PORT address
#include <cyg/kernel/kapi.h>
void delay(int cnt); // delay routine
cyg_thread thread_s;
char stack[4096];
cyg_handle_t LED_thread;
cyg_thread_entry_t LED_program;
int dispcnt; // display counter
void cyg_user_start(void)
{
cyg_thread_create(4,LED_program, (cyg_addrword_t) 0, "LED Thread",
(void *) stack,4096, &LED_thread, &thread_s);
dispcnt = 0;
*IOPDATA = 0x00; // clear display of the LED
(note: bit4~bit7 represent the LED1~LED4 on the ARM Evaluator7T board)
delay(20); // manual delay
cyg_thread_resume(LED_thread); // resume the led thread
}
void LED_program(cyg_addrword_t data)
{
for(;;)
{
if(dispcnt>=16) // ensure the display counter not exceed 4-bit. (value 15)(we got 4 led on the evaluator7T board so 4 bits)
dispcnt = 0;
switch(dispcnt)
{
case 0:
*IOPDATA = 0x00; // bit4~bit7 as the LED1~LED4 on the Evaluator7T board
break;
case 1:
*IOPDATA = 0x10; //bit4~bit7 as the LED1~LED4 on the Evaluator7T board
break;
case 2:
*IOPDATA = 0x20; //bit4~bit7 as the LED1~LED4 on the Evaluator7T board
break;
case 3:
*IOPDATA = 0x30; //bit4~bit7 as the LED1~LED4 on the Evaluator7T board
break;
case 4:
*IOPDATA = 0x40;
break;
case 5:
*IOPDATA = 0x50;
break;
case 6:
*IOPDATA = 0x60;
break;
case 7:
*IOPDATA = 0x70;
break;
case 8:
*IOPDATA = 0x80;
break;
case 9:
*IOPDATA = 0x90;
break;
case 10:
*IOPDATA = 0xa0;
break;
case 11:
*IOPDATA = 0xb0;
break;
case 12:
*IOPDATA = 0xc0;
break;
case 13:
*IOPDATA = 0xd0;
break;
case 14:
*IOPDATA = 0xe0;
break;
case 15:
*IOPDATA = 0xf0;
break;
}
cyg_thread_delay(200);
dispcnt++;
}
}
// manual delay routine
void delay(int cnt)
{
int cnt1, cnt2, cnt3;
for(cnt1=0;cnt1<40000;cnt1++)
{
for(cnt2=0;cnt2<cnt;cnt2++)
cnt3 = 0;
}
}
*************************************************************************************************
*************************************************************************************************
The LED comes to a 2 the halted forever. ( means it pass two cyg_thread_delay(200) then die)
===================================================================================================
===================================================================================================
-----Original Messa
ge-----
From: Andrew Lunn [ mailto:andrew.lunn@ascom.ch ]
Sent: 23 April 2001 12:08
To: Huang Qiang
Cc: eCos
Subject: Re: [ECOS] Strange Problem in cyg_thread_delay( )?
On Mon, Apr 23, 2001 at 12:03:05PM +0100, Huang Qiang wrote:
> Dear all:
> I am using ARM Evaluator7T . My test program has a sigle thread
> runnning, while I call cyg_thread_delay(200) each time in the thread
(loop).
> It pass the first and second call to the cyg_thread_delay(200), but halted
> at the third call to the cyg_thread_delay. What's wrong with it? Can
anyone
> help me?
> Thanks a lot!
> james
Given the little information you have provided there could be lots of
possibilites....
Have you started the schedular?
Is your stack big enough?
Have you memset(0,0,10000);
Have you built eCos with assertions enables in package infra? That may
help.
Supply more details and then we may be able to help.
Andrew
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [ECOS] Strange Problem in cyg_thread_delay( )?
2001-04-23 4:46 Huang Qiang
@ 2001-04-24 20:18 ` Andrew Lunn
0 siblings, 0 replies; 7+ messages in thread
From: Andrew Lunn @ 2001-04-24 20:18 UTC (permalink / raw)
To: Huang Qiang; +Cc: eCos
Hum, your code looks OK. As has already been mentioned on this list,
what do the other bits in the register do?
Have you tried other values of delay? Does it run for longer?
Are you a CS student at Liverpool Uni? I've edited your code a bit to
improve the style. I've moved some variables around, and replaced your
big case statemenet with a one liner. Lookup bitwise shift operations
in your C book. I've not checked this still compiles.
Andrew
/* define the LED PORT address */
#include <cyg/kernel/kapi.h>
#define IOPDATA ((volatile unsigned *)(0x03FF5008))
#define STACKSIZE 4096
void delay(int cnt); /* delay routine */
cyg_thread thread_s;
char stack[STACKSIZE];
cyg_handle_t LED_thread;
cyg_thread_entry_t LED_program;
void cyg_user_start(void)
{
cyg_thread_create(4,LED_program, (cyg_addrword_t) 0, "LED Thread",
(void *) stack,STACKSIZE, &LED_thread, &thread_s);
cyg_thread_resume(LED_thread); /* resume the led thread */
}
void LED_program(cyg_addrword_t data)
{
unsigned dispcnt = 0; /* display counter */
*IOPDATA = 0x00; /* clear display of the LED */
delay(20);
for(;;)
{
/* ensure the display counter not exceed 4-bit. (value 15)
(we got 4 led on the evaluator7T board so 4 bits) */
if (dispcnt>=16)
dispcnt = 0;
*IOPDATA = ( dispcnt << 4);
cyg_thread_delay(200);
dispcnt++;
}
}
/* manual delay routine */
void delay(int cnt)
{
int cnt1, cnt2, cnt3;
for(cnt1=0;cnt1<40000;cnt1++)
{
for(cnt2=0;cnt2<cnt;cnt2++)
cnt3 = 0;
}
}
^ permalink raw reply [flat|nested] 7+ messages in thread
* [ECOS] Strange Problem in cyg_thread_delay( )?
@ 2001-04-23 4:02 Huang Qiang
2001-04-24 20:27 ` Andrew Lunn
0 siblings, 1 reply; 7+ messages in thread
From: Huang Qiang @ 2001-04-23 4:02 UTC (permalink / raw)
To: eCos
Dear all:
I am using ARM Evaluator7T . My test program has a sigle thread
runnning, while I call cyg_thread_delay(200) each time in the thread (loop).
It pass the first and second call to the cyg_thread_delay(200), but halted
at the third call to the cyg_thread_delay. What's wrong with it? Can anyone
help me?
Thanks a lot!
james
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [ECOS] Strange Problem in cyg_thread_delay( )?
2001-04-23 4:02 Huang Qiang
@ 2001-04-24 20:27 ` Andrew Lunn
2001-04-23 4:45 ` Huang Qiang
2001-04-26 2:43 ` Robert Cragie
0 siblings, 2 replies; 7+ messages in thread
From: Andrew Lunn @ 2001-04-24 20:27 UTC (permalink / raw)
To: Huang Qiang; +Cc: eCos
On Mon, Apr 23, 2001 at 12:03:05PM +0100, Huang Qiang wrote:
> Dear all:
> I am using ARM Evaluator7T . My test program has a sigle thread
> runnning, while I call cyg_thread_delay(200) each time in the thread (loop).
> It pass the first and second call to the cyg_thread_delay(200), but halted
> at the third call to the cyg_thread_delay. What's wrong with it? Can anyone
> help me?
> Thanks a lot!
> james
Given the little information you have provided there could be lots of
possibilites....
Have you started the schedular?
Is your stack big enough?
Have you memset(0,0,10000);
Have you built eCos with assertions enables in package infra? That may
help.
Supply more details and then we may be able to help.
Andrew
^ permalink raw reply [flat|nested] 7+ messages in thread* RE: [ECOS] Strange Problem in cyg_thread_delay( )?
2001-04-24 20:27 ` Andrew Lunn
@ 2001-04-23 4:45 ` Huang Qiang
2001-04-26 2:43 ` Robert Cragie
1 sibling, 0 replies; 7+ messages in thread
From: Huang Qiang @ 2001-04-23 4:45 UTC (permalink / raw)
To: eCos, Andrew Lunn
My code listed as bellow:
****************************************************************************
**************************
****************************************************************************
**************************
#define IOPDATA ((volatile unsigned *)(0x03FF5008)) // define the LED
PORT address
#include <cyg/kernel/kapi.h>
void delay(int cnt); // delay routine
cyg_thread thread_s;
char stack[4096];
cyg_handle_t LED_thread;
cyg_thread_entry_t LED_program;
int dispcnt; // display counter
void cyg_user_start(void)
{
cyg_thread_create(4,LED_program, (cyg_addrword_t) 0, "LED Thread",
(void *) stack,4096, &LED_thread, &thread_s);
dispcnt = 0;
*IOPDATA = 0x00; // clear display of the LED
(note: bit4~bit7 represent the LED1~LED4 on the ARM Evaluator7T board)
delay(20); // manual delay
cyg_thread_resume(LED_thread); // resume the led thread
}
void LED_program(cyg_addrword_t data)
{
for(;;)
{
if(dispcnt>=16) // ensure the display counter not exceed 4-bit. (value 15)(we got 4 led on the evaluator7T board so 4 bits)
dispcnt = 0;
switch(dispcnt)
{
case 0:
*IOPDATA = 0x00; // bit4~bit7 as the LED1~LED4 on the Evaluator7T board
break;
case 1:
*IOPDATA = 0x10; //bit4~bit7 as the LED1~LED4 on the Evaluator7T board
break;
case 2:
*IOPDATA = 0x20; //bit4~bit7 as the LED1~LED4 on the Evaluator7T board
break;
case 3:
*IOPDATA = 0x30; //bit4~bit7 as the LED1~LED4 on the Evaluator7T board
break;
case 4:
*IOPDATA = 0x40;
break;
case 5:
*IOPDATA = 0x50;
break;
case 6:
*IOPDATA = 0x60;
break;
case 7:
*IOPDATA = 0x70;
break;
case 8:
*IOPDATA = 0x80;
break;
case 9:
*IOPDATA = 0x90;
break;
case 10:
*IOPDATA = 0xa0;
break;
case 11:
*IOPDATA = 0xb0;
break;
case 12:
*IOPDATA = 0xc0;
break;
case 13:
*IOPDATA = 0xd0;
break;
case 14:
*IOPDATA = 0xe0;
break;
case 15:
*IOPDATA = 0xf0;
break;
}
cyg_thread_delay(200);
dispcnt++;
}
}
// manual delay routine
void delay(int cnt)
{
int cnt1, cnt2, cnt3;
for(cnt1=0;cnt1<40000;cnt1++)
{
for(cnt2=0;cnt2<cnt;cnt2++)
cnt3 = 0;
}
}
*************************************************************************************************
*************************************************************************************************
The LED comes to a 2 the halted forever. ( means it pass two cyg_thread_delay(200) then die)
===================================================================================================
===================================================================================================
-----Original Messa
ge-----
From: Andrew Lunn [ mailto:andrew.lunn@ascom.ch ]
Sent: 23 April 2001 12:08
To: Huang Qiang
Cc: eCos
Subject: Re: [ECOS] Strange Problem in cyg_thread_delay( )?
On Mon, Apr 23, 2001 at 12:03:05PM +0100, Huang Qiang wrote:
> Dear all:
> I am using ARM Evaluator7T . My test program has a sigle thread
> runnning, while I call cyg_thread_delay(200) each time in the thread
(loop).
> It pass the first and second call to the cyg_thread_delay(200), but halted
> at the third call to the cyg_thread_delay. What's wrong with it? Can
anyone
> help me?
> Thanks a lot!
> james
Given the little information you have provided there could be lots of
possibilites....
Have you started the schedular?
Is your stack big enough?
Have you memset(0,0,10000);
Have you built eCos with assertions enables in package infra? That may
help.
Supply more details and then we may be able to help.
Andrew
^ permalink raw reply [flat|nested] 7+ messages in thread* RE: [ECOS] Strange Problem in cyg_thread_delay( )?
2001-04-24 20:27 ` Andrew Lunn
2001-04-23 4:45 ` Huang Qiang
@ 2001-04-26 2:43 ` Robert Cragie
1 sibling, 0 replies; 7+ messages in thread
From: Robert Cragie @ 2001-04-26 2:43 UTC (permalink / raw)
To: Huang Qiang; +Cc: eCos
I have had a look at the Samsung chip user manual and the Evaluator manual,
and would suggest the following:
1) Check IOPCON is set correctly, especially with regard to interrupts; it
may be possible that you are getting a spurious interrupt by writing to P8.
2) Check IOPMODE is correctly set for P4:7 (I presume it is or else you
wouldn't have seen any LEDs lit).
3) It should be OK to use 'unsigned' as the type, as this is what ARM use.
4) As other people have suggested, and as it states in the ARM Evaluator
manual, use a read modify write operation on IOPDATA:
*IOPDATA = (*IOPDATA & ~0xF0) | (dispcnt << 4);
HTH
Robert Cragie
Design Engineer
Jennic Ltd.
Furnival Street
Sheffield
S1 4QT
United Kingdom
Tel: +44 (0) 114 281 4512
Fax: +44 (0) 114 281 2951
mailto:rcc@jennic.com
http://www.jennic.com
> -----Original Message-----
> From: ecos-discuss-owner@sources.redhat.com
> [ mailto:ecos-discuss-owner@sources.redhat.com]On Behalf Of Andrew Lunn
> Sent: 23 April 2001 12:08
> To: Huang Qiang
> Cc: eCos
> Subject: Re: [ECOS] Strange Problem in cyg_thread_delay( )?
>
>
> On Mon, Apr 23, 2001 at 12:03:05PM +0100, Huang Qiang wrote:
> > Dear all:
> > I am using ARM Evaluator7T . My test program has a sigle thread
> > runnning, while I call cyg_thread_delay(200) each time in the
> thread (loop).
> > It pass the first and second call to the cyg_thread_delay(200),
> but halted
> > at the third call to the cyg_thread_delay. What's wrong with
> it? Can anyone
> > help me?
> > Thanks a lot!
> > james
>
> Given the little information you have provided there could be lots of
> possibilites....
>
> Have you started the schedular?
> Is your stack big enough?
> Have you memset(0,0,10000);
>
> Have you built eCos with assertions enables in package infra? That may
> help.
>
> Supply more details and then we may be able to help.
>
> Andrew
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2001-04-26 2:43 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-04-23 5:24 [ECOS] Strange Problem in cyg_thread_delay( )? Nielsen Linus
-- strict thread matches above, loose matches on Subject: below --
2001-04-23 4:46 Huang Qiang
2001-04-24 20:18 ` Andrew Lunn
2001-04-23 4:02 Huang Qiang
2001-04-24 20:27 ` Andrew Lunn
2001-04-23 4:45 ` Huang Qiang
2001-04-26 2:43 ` Robert Cragie
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).