headers
Jason Thomas | 1 Mar 2007 03:03
Picon
Favicon

Redboot works, eCos doesn't.

  I've created a hardware profile for a SH4 custom
platform I'm using. When I load a redboot image,
created from the same platform file (Copied the .ecc,
and added the Redboot and CRC packages)--- over SCIF,
I get a redboot prompt. When I run a really simple
eCos ap, however:

 
#include <stdio.h>
#include <cyg/infra/diag.h>
#include <cyg/hal/hal_if.h>

void cyg_user_start(void)
{   
    hal_if_init();

    diag_printf("Hello, eCos world!\n");
    printf("Hello, eCos world!\r\n");
}

int main(void)
{
    hal_if_init();

    diag_printf("Hello, eCos world!\n");
    printf("Hello, eCos world!\r\n");

    return 1;
}
(Continue reading)

Permalink | Reply | 0 comments |
headers
Samer Darras | 1 Mar 2007 04:45

RE: Startup Procedure

I have tried a default configuration and compiled in the "serial.c"
example program and burned it to flash but it did not run. Nothing was
output on the serial port??? Is there anything specific in the default
configuration that I need to set or unset?

Thanks.

-----Original Message-----
From: Andrew Lunn [mailto:andrew <at> lunn.ch] 
Sent: Wednesday, February 28, 2007 2:44 PM
To: Samer Darras
Cc: ecos-discuss <at> sources.redhat.com
Subject: Re: [ECOS] Startup Procedure

On Wed, Feb 28, 2007 at 02:02:05PM -0800, Samer Darras wrote:
> I was able to build and run a Redboot image on AT91SAM7S256
successfully
> and downloaded it to Flash using SAM-BA, but when I build any of the
> sample programs using a default eCos configuration, it does not run. I
> have tried creating a RAM linker script and use Redboot to run it;
> however, that did not work either.

I wound not suggest using redboot on the AT91SAM7S256. It does not
really have enough ram for it to be useful.

The AT91SAM7S devices are designed to run there applications from
Flash, not RAM. That is why there is no support for RAM startup in the
HAL. The test programs should just work. Burn them into flash and run
them.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Chuck McManis | 1 Mar 2007 07:09

Re: Proper Thread Environment (was Re: [ECOS] SPI usage)

Hmm, I'm getting closer, kind of.

At 04:06 AM 2/27/2007, Gary Thomas wrote:
 > 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.

So after much trial and tribulation (why would ANYONE layout a 10 pin IDC 
connector for a 9 pin serial port with pin 1 - 1, 2-2, 3-3, etc. It makes 
using off the shelf IDC connectors impossible!) I've got a second serial 
port on my box that I can talk to.

So how do I make *that* stdin/stdout (or their equivalent) for my 
application? I'd like to maintain the flexibility of having the Redboot 
serial port which I can connect to and run GDB on.

The documentation for the serial driver is not much help, I'm looking in 
the C-library documentation at the moment but if someone knows off the top 
of their head, please let me know...

--Chuck

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chuck McManis | 1 Mar 2007 08:31

serial is working

Ok, I've got serial I/O basically working.

Question if I want to replace stdin/stdout must I open /dev/tty1 twice? as in

         stdin = fopen("/dev/tty1", "r");
	stdout = fopen("/dev/tty1", "w");

Seems like if I open it "rw" I can read from it but when I try writing to 
it nothing comes out...

--Chuck

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Permalink | Reply | 1 comment |
headers
Julien Stéphane | 1 Mar 2007 11:15
Picon
Favicon

RE : RE: RE: RE: [ECOS] Does AT91 SPI driver support external SPI devices?

Mornin',

I have tested the code you gave me to test the GPIO functiuns and it works well! So the problem doesn't become
from the GPIO functions. They works under AT91M55800A.

To understand what the multiplexor does, I have studied its datasheet. If I would like to activate the
NSPICS5, I have to put the next values:NSPCS0=1, NSPCS1=0, NSPCS2=1, NSPCS0=3. I did it with the next
code. By this way, I think that the dev_num value is ignored. Am I right? :

static void
spi_at91_set_npcs(cyg_spi_at91_bus_t *spi_bus,int val)
{
   HAL_ARM_AT91_GPIO_PUT(AT91_SPI_NPCS0, 1);
   HAL_ARM_AT91_GPIO_PUT(AT91_SPI_NPCS1, 0);
   HAL_ARM_AT91_GPIO_PUT(AT91_SPI_NPCS2, 1);
   HAL_ARM_AT91_GPIO_PUT(AT91_SPI_NPCS3, 0);
}

As I was not sure of the NPCS3 value, I tried to change it and no changes appeared. I made many measures
before/after the multioplexor and on the final board's pins. I checked the connections between pins of
board and multiplexor, they are OK. No changes appears on the final board's pins.

Are you sure that the switches inside the processor are closed (see attached schema)? I have never seen this
operation... If I want to close it anyway, have I got to use the HAL_WRITE_UINT32 function with the address
and the value of the corresponding register?

Thank you very much for help! Regards,

Stéphane
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andrew Lunn | 1 Mar 2007 13:52
Picon

Re: serial is working

On Wed, Feb 28, 2007 at 11:31:40PM -0800, Chuck McManis wrote:
> Ok, I've got serial I/O basically working.
> 
> Question if I want to replace stdin/stdout must I open /dev/tty1 twice? as 
> in
> 
>         stdin = fopen("/dev/tty1", "r");
> 	stdout = fopen("/dev/tty1", "w");

I think you need to set
CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE. stdio/stdout will then be set at
compile time to what every device you point it to.

  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
Permalink | Reply | 0 comments |
headers
Andrew Lunn | 1 Mar 2007 14:03
Picon

Re: RE?: RE: RE: RE: [ECOS] Does AT91 SPI driver support external SPI devices?

On Thu, Mar 01, 2007 at 11:15:17AM +0100, Julien St?phane wrote:
> Mornin',
> 

> I have tested the code you gave me to test the GPIO functiuns and it
> works well! So the problem doesn't become from the GPIO
> functions. They works under AT91M55800A.

O.K. That is good. It is one thing less to worry about.

> To understand what the multiplexor does, I have studied its datasheet. If I would like to activate the
NSPICS5, I have to put the next values:NSPCS0=1, NSPCS1=0, NSPCS2=1, NSPCS0=3. I did it with the next
code. By this way, I think that the dev_num value is ignored. Am I right? :
> 
> static void
> spi_at91_set_npcs(cyg_spi_at91_bus_t *spi_bus,int val)
> {
>    HAL_ARM_AT91_GPIO_PUT(AT91_SPI_NPCS0, 1);
>    HAL_ARM_AT91_GPIO_PUT(AT91_SPI_NPCS1, 0);
>    HAL_ARM_AT91_GPIO_PUT(AT91_SPI_NPCS2, 1);
>    HAL_ARM_AT91_GPIO_PUT(AT91_SPI_NPCS3, 0);
> }
> 

> As I was not sure of the NPCS3 value, I tried to change it and no
> changes appeared. I made many measures before/after the multioplexor
> and on the final board's pins. I checked the connections between
> pins of board and multiplexor, they are OK. No changes appears on
> the final board's pins.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Lunn | 1 Mar 2007 14:23
Picon

Re: Startup Procedure

On Wed, Feb 28, 2007 at 07:45:42PM -0800, Samer Darras wrote:
> I have tried a default configuration and compiled in the "serial.c"
> example program and burned it to flash but it did not run. Nothing was
> output on the serial port??? Is there anything specific in the default
> configuration that I need to set or unset?

Why serial.c example program?

The default configuration will not have the interrupt serial device
drivers compile in.

A better tests programs to start with are
install/tests/hal/common/current/tests/*

They should always work.

     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
Permalink | Reply | 4 comments |
headers
Øyvind Harboe | 1 Mar 2007 14:23

eCos on Windows without Cygwin

If you don't agree that the dependence on Cygwin is hampering eCos,
then don't read further.

Thus warned.....

Problems w/Cygwin:

- Whether or not Cygwin will work at all for eCos is a matter of
chance depending on the mix of Cygwin packages on any given day. E.g.
today they seem to be battling with breakages in heap allocation on
XP due to trying to accommodate Vista somehow. Who knows what they'll
be working on tomorrow. Cygwin ecosconfig binary available for
download on ecos.sourceware.org was broken for years(?) w/latest
Cygwin.   http://www.cygwin.com/ml/cygwin/2006-01/msg00799.html
- There is no way to create a single package no questions installer
w/Cygwin. Lots of companies ignore Cygwin license conditions and
bundle cygwin1.dll which creates lots of impossible to debug problems
w/side-by-side installs. A pox on them!
- Installing or upgrading Cygwin is *painful*. Download times,
unpacking times, lots of questions, how to figure out which packages
to install, etc., etc.
- Cygwin has no "release" concept a la Linux distributions. I don't
think there is a single change (except bugfixes) that has interested
me in Cygwin the last 5 years w.r.t. eCos development. eCos really has
very modest needs. I believe the reason this is so, is because there
is no interest w/the Cygwin package maintainers. The only option I
know of is the Cygwin Time Machine. For the record: I don't believe
the Cygwin guys are doing anything wrong. Doing releases would be the
solution, but to do that the resources would have to come from
somewhere. Given their resource limitations, I believe they are
(Continue reading)

Permalink | Reply | 17 comments |
headers
Julien Stéphane | 1 Mar 2007 15:42
Picon
Favicon

RE: Does AT91 SPI driver support external SPI devices?

I thought too that the multiplexor had a problem. Following your concil, I read the evaluation user guide
with more attention. There is no jumper but a line to cut (see attached). I cutted it and now, RedBoot doen't
boot anymore on my board. Is RedBoot installed in the DataFlash memory? Here is my RedBoot version return : 

RedBoot> version
RedBoot(tm) bootstrap and debug environment [ROM]
Non-certified release, version UNKNOWN - built 20:04:38, Jul 15 2003
Platform: Atmel AT91/EB55 (ARM7TDMI) 
Copyright (C) 2000, 2001, 2002, Red Hat, Inc.
RAM: 0x02000000-0x02040000, 0x02006948-0x0203f000 available
FLASH: 0x01000000 - 0x01200000, 32 blocks of 0x00010000 bytes each.
RedBoot> 

PS:I installed a jumper to reclose this connection.

--
Stéphane JULIEN

Ing. dipl. HES en informatique
Rue Baptiste-Savoye 26
CH - 2610 Saint-Imier
Bureau : +41 32 930 22 08
Privé : +41 78 889 14 47
stephane.julien <at> he-arc.ch

________________________________

On Thu, Mar 01, 2007 at 11:15:17AM +0100, Julien St?phane wrote:
> Mornin',
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane