headers
Alexander Aganichev | 18 Jun 2007 15:11
Picon

Question to 16x5x driver users

I found that driver not transmit anything in interrupt driving mode
unless I made the following patch:

Index: packages/devs/serial/generic/16x5x/current/src/ser_16x5x.c
===================================================================
RCS file: /cvs/ecos/ecos/packages/devs/serial/generic/16x5x/current/src/ser_16x5x.c,v
retrieving revision 1.14
diff -u -r1.14 ser_16x5x.c
--- packages/devs/serial/generic/16x5x/current/src/ser_16x5x.c	27 Nov
2006 13:59:50 -0000	1.14
+++ packages/devs/serial/generic/16x5x/current/src/ser_16x5x.c	18 Jun
2007 12:21:30 -0000
 <at>  <at>  -516,6 +516,7  <at>  <at> 
     HAL_READ_UINT8(base+REG_ier, _ier);
     _ier |= IER_XMT;                    // Enable xmit interrupt
     HAL_WRITE_UINT8(base+REG_ier, _ier);
+    (chan->callbacks->xmt_char)(chan); // <<<<<<
 }

 // Disable the transmitter on the device

Am I right to make this change or I just missed another process that
should call xmt_char? I'm using LPC2294 based board and use this
driver for the UART1.

--

-- 
WBR, Alexander
Permalink | Reply | 5 comments |
headers
Guennadi Liakhovetski | 19 Jun 2007 09:01
Picon
Favicon

Re: Question to 16x5x driver users

On Mon, 18 Jun 2007, Alexander Aganichev wrote:

> I found that driver not transmit anything in interrupt driving mode
> unless I made the following patch:
> 
> Index: packages/devs/serial/generic/16x5x/current/src/ser_16x5x.c
> ===================================================================
> RCS file:
> /cvs/ecos/ecos/packages/devs/serial/generic/16x5x/current/src/ser_16x5x.c,v
> retrieving revision 1.14
> diff -u -r1.14 ser_16x5x.c
> --- packages/devs/serial/generic/16x5x/current/src/ser_16x5x.c	27 Nov
> 2006 13:59:50 -0000	1.14
> +++ packages/devs/serial/generic/16x5x/current/src/ser_16x5x.c	18 Jun
> 2007 12:21:30 -0000
>  <at>  <at>  -516,6 +516,7  <at>  <at> 
>     HAL_READ_UINT8(base+REG_ier, _ier);
>     _ier |= IER_XMT;                    // Enable xmit interrupt
>     HAL_WRITE_UINT8(base+REG_ier, _ier);
> +    (chan->callbacks->xmt_char)(chan); // <<<<<<
> }
> 
> // Disable the transmitter on the device
> 
> Am I right to make this change or I just missed another process that
> should call xmt_char? I'm using LPC2294 based board and use this
> driver for the UART1.

It looks like eCos uses the usual UART sending procedure - enable tx-empty 
(IER_XMT) interrupt and return, then the interrupt should trigger as soon
(Continue reading)

Permalink | Reply | 2 comments |
headers
Gary Thomas | 19 Jun 2007 13:25
Favicon

Re: Question to 16x5x driver users


Guennadi Liakhovetski wrote:
> On Mon, 18 Jun 2007, Alexander Aganichev wrote:
> 
>> I found that driver not transmit anything in interrupt driving mode
>> unless I made the following patch:
>>
>> Index: packages/devs/serial/generic/16x5x/current/src/ser_16x5x.c
>> ===================================================================
>> RCS file:
>> /cvs/ecos/ecos/packages/devs/serial/generic/16x5x/current/src/ser_16x5x.c,v
>> retrieving revision 1.14
>> diff -u -r1.14 ser_16x5x.c
>> --- packages/devs/serial/generic/16x5x/current/src/ser_16x5x.c	27 Nov
>> 2006 13:59:50 -0000	1.14
>> +++ packages/devs/serial/generic/16x5x/current/src/ser_16x5x.c	18 Jun
>> 2007 12:21:30 -0000
>>  <at>  <at>  -516,6 +516,7  <at>  <at> 
>>     HAL_READ_UINT8(base+REG_ier, _ier);
>>     _ier |= IER_XMT;                    // Enable xmit interrupt
>>     HAL_WRITE_UINT8(base+REG_ier, _ier);
>> +    (chan->callbacks->xmt_char)(chan); // <<<<<<
>> }
>>
>> // Disable the transmitter on the device
>>
>> Am I right to make this change or I just missed another process that
>> should call xmt_char? I'm using LPC2294 based board and use this
>> driver for the UART1.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mik Prog | 21 Jun 2007 16:32
Picon

exception rises calling cyg_thread_delete()

Hello everyone,

apologies if the argument has been discussed already (could not find
anything about it!).
I'm new in eCos world and now I am facing an annoying problem: I get a
crash calling cyg_thread_delete().

The exception I get is on Cyg_Alarm::~Cyg_Alarm(), which is called by
cyg_thread_delete().

The most annoying thing is that this crash happens randomly: I have an
environment running 7 threads, out of which 6 should be deleted.
Deleting the first one is usually Ok and crash happens when deleting
2nd or 3rd or 4th and so on... randomly.

I first call the release function, just to unlock pending calls:

    cyg_thread_release( *(cyg_handle_t*)(pHandle) );

then the deletion one, which crashes:

    if ( ! cyg_thread_delete (*(cyg_handle_t*)(pHandle)) )
    {
        diag_printf("\nERROR: Thread deletion failed!\n");   // I
don't get this: an exception arise.
    }

I've tried to suspend the thread before delete it, but doesn't help.

Does anyone has any clue about what is going on?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Gary Thomas | 21 Jun 2007 16:36
Favicon

Re: exception rises calling cyg_thread_delete()


Mik Prog wrote:
> Hello everyone,
> 
> apologies if the argument has been discussed already (could not find
> anything about it!).
> I'm new in eCos world and now I am facing an annoying problem: I get a
> crash calling cyg_thread_delete().
> 
> The exception I get is on Cyg_Alarm::~Cyg_Alarm(), which is called by
> cyg_thread_delete().
> 
> The most annoying thing is that this crash happens randomly: I have an
> environment running 7 threads, out of which 6 should be deleted.
> Deleting the first one is usually Ok and crash happens when deleting
> 2nd or 3rd or 4th and so on... randomly.
> 
> I first call the release function, just to unlock pending calls:
> 
>    cyg_thread_release( *(cyg_handle_t*)(pHandle) );
> 
> then the deletion one, which crashes:
> 
>    if ( ! cyg_thread_delete (*(cyg_handle_t*)(pHandle)) )
>    {
>        diag_printf("\nERROR: Thread deletion failed!\n");   // I
> don't get this: an exception arise.
>    }
> 
> I've tried to suspend the thread before delete it, but doesn't help.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin Maurer | 23 Jun 2007 12:03
Picon
Favicon

unsubscribe capiman <at> t-online.de

unsubscribe capiman <at> t-online.de
Permalink | Reply | 0 comments |
headers
Mik Prog | 23 Jun 2007 12:21
Picon

Re: exception rises calling cyg_thread_delete()

On 6/21/07, Gary Thomas <gary <at> mlbassoc.com> wrote:
[..]
> Are you sure your handle is correct?  I think you may be
> dereferencing it improperly.

Thank you Gary.
I've been through the pointers over and over again.
At the end I've decided to use a static array of cyg_handle_t for
thread creation/deletion... where my starting pointer points to (I
can't get rid of it).
So:

#define MAX_NUM_THREADS         10

static cyg_thread ThreadsHolder[MAX_NUM_THREADS];
static cyg_handle_t HandlesHolder[MAX_NUM_THREADS];

static I2 threadCounter = 0;            //number of allocated threads

// Threads creation
{
[..]
  HandlesHolder[threadCounter] = 0;

  cyg_thread_create ((cyg_addrword_t)prio,
                      (cyg_thread_entry_t*)pd,
                      (cyg_addrword_t)pData,
                      (char*)pName,
                      (void*)pbos,
                      (cyg_ucount32)stksize,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kai Niu | 23 Jun 2007 13:28
Picon

.bss and RedBoot problem

Hi all:
    I recently start working on eCos. here is some problem I have
after 2 week's study of eCos. I am working on platform TS7200
(www.embeddedarm.com), this platform prebuild eCos redboot.
I have already compiled the libtarget.a with "rom start-up" option.
when I am trying compile a very simple C program with this static
library. ld complains about .bss is not in the region of ram.
here is my mlt_arm_arm9_ts7200_ram.ldi dump:

#include <pkgconf/hal_arm_arm9_ts7200.h>
#include <cyg/infra/cyg_type.inc>

MEMORY
{
    ram : ORIGIN = 0x00044F88, LENGTH = 0x01F98078
}
SECTIONS
{
    SECTIONS_BEGIN
    SECTION_fixed_vectors (ram, 0x44F88, LMA_EQ_VMA)
    SECTION_rom_vectors (ram, 0x50000, LMA_EQ_VMA)
    SECTION_text (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fini (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata1 (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fixup (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_gcc_except_table (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_data (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_bss (ram, ALIGN (0x4), LMA_EQ_VMA)
    CYG_LABEL_DEFN(_heap1) = ALIGN (0x8);
(Continue reading)

Permalink | Reply | 2 comments |

Gmane