headers
Uwe Kindler | 23 May 2013 09:23
Picon

eCos Driver for open source CANopen stack CanFestival

Hi,

we are currently in the process of creating an eCos driver for the open 
source CANopen stack CanFestival.

http://www.canfestival.org/
http://dev.automforge.net/CanFestival-3/

This driver is based on the eCos CAN framework of the public eCos 
repositories.
We thought about integrating CanFestival as an eCos package like lwIP or 
uSTL but we are not shure if the license of the CanFestival stack 
(LGPLv2) is suitable for this plan. What is your opinion? Or should we 
contact the CanFestival maintainers and ask if they would accept an 
additional license (the eCos license).

Kind regards, Uwe
Permalink | Reply | 2 comments |
headers
Will Wagner | 1 May 2013 20:37
Favicon

Updating lwip

We are interested in updating to lwip 1.4.1. Has anyone already done any 
work on this?

Have started looking at the difference between upstream 1.3.2 and what 
is check in to ecos. There are quite a lot of differences, although most 
of them are trivial renaming.

Does anyone know what changes were made to the lwip source and why. In 
particular lost of the ppp code has had functions and variables renamed.

Any pointers for the porting process much appreciated.

Thanks
Will

--

-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner <at> carallon.com
Development Manager                      Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------
Permalink | Reply | 4 comments |
headers
Les G. Miklosy | 3 Apr 2013 04:41
Picon

Saving Global Pointer for SPARC

Greetings,

In my repository (1.0.7) it appears only mips includes code for saving 
and restoring the global pointer in hal_arch.h while other platforms do 
not. Is it necessary to save this pointer for SPARC? Does anybody have 
the SPARC code to do this? The macros are CYGARC_HAL_SAVE_GP() AND 
CYGARC_HAL_RESTORE_GP().

Thanks for directions.
Les
Permalink | Reply | 0 comments |
headers
Max Seidenstuecker | 28 Mar 2013 17:03
Picon

FreeBSD TCP/IP stacks update to newer version possible?

Hello everyone,

for a research project our company is aiming to use eCos on the target
hardware. The major requirement is a working IPv6 implementation and
TLS/SSL. In eCos there is a FreeBSD-based TCP/IP stack and an OpenSSL
implementation available.

I see so many changes in the KAME project (FreeBSD IPv6 base) that I
am wondering if the version in eCos is stable enough. Has anyone got a
summary of the changes between 2001 and 2006 where the project
concluded? So we can see if an update is needed or worth doing.

What would the tasks be to update an already ported stack? I would
rate myself as a rookie in the area of network and OS related
programming. But from what I saw in the code it seems like there is an
compatibilty layer (eCos wrapper) provided for easy updates to the
code. Would a copy/paste job and some minor adjustments to the code do
the trick then?

Sincerely,
Max
Permalink | Reply | 1 comment |
headers
andrea_91 | 18 Mar 2013 23:25
Picon

at91sam9x35

hi i'm doing eCos porting on board Atmel: at91sam9x35.
Well, now i did the memory mapping on plf_io.h file and then i created all
other file for dbg port. If i try to debug to see if the dbg port works, on
the putty terminal i see something similar to
"G!ÙV <at> Øt÷TÖåëÅõëõ­õÑfçfçnçf£Qü", but i'd wanted to write "Hello world\n". I
know that this is a possible error of baud rate but the baud rate on putty
and on ecos are correct(115200).
Have you got some ideas about?

--
View this message in context: http://sourceware-org.1504.n7.nabble.com/at91sam9x35-tp225742.html
Sent from the Sourceware - ecos-devel mailing list archive at Nabble.com.
Permalink | Reply | 3 comments |
headers
Frank Ch. Eigler | 12 Mar 2013 16:36
Picon
Favicon
Gravatar

IMPORTANT: sourceware.org hardware migration, MARCH 18..22

Hi -

Please be aware that **next week**, we will attempt to switch over the
hardware that serves sourceware.org and its aliases (gcc.gnu.org,
ecos.sourceware.org, cygwin.com, etc.) to newer & faster hardware
donated by Red Hat.

The plan is to take down network services next Monday around 14:00Z,
and gradually bring things back up on the new machine, one service at
a time, as quickly as possible.  Since this change involves switching
to a much younger OS and is complicated by many sourceware-specific
services, the overall outage may last up to several days.  We will
prioritize getting source code version control systems up first.

This announcement is being sent to those main mailing lists that have
been recently active; please feel free to share it.  You are welcome
to listen in on irc.freenode.net #overseers during the transition
period.  We appreciate your patience and hope that the new machines
will serve us all well.

- FChE
Permalink | Reply | 0 comments |
headers
Michael Jones | 19 Feb 2013 01:12
Favicon

Problem setting up an ISR for a K60 PORT

I am struggling to setup an ISR/DSR for a PORT on the K60. My goal is to get an ISR/DSR when Pin 19 of PORTA
transitions from high to low. This is pin PTA19 of the device.

My non-working code and complete code below.

What the code tries to do is setup PORTA PIN19 as input. Then take the PCR register and set the interrupt to
work off a falling edge. 

Then create the ISR/DSR.

When I toggle the pin, nothing happens. 

FYI the hardware works with MQX, so I know the hardware is ok. I use it the same way under MQX where I get an ISR
from a negative edge. And I have put a scope on it to make sure there is an edge. So I am quite sure the problem is
the code.

This code was generated by trying to understand the Kinetis code, but things were not clear to me. Some
macros use __pin to mean different things. So this is my best guess.

Does anyone know how to do this?

PORT SETUP CODE
================

    cyghwr_hal_kinetis_port_t *port_p;

	CYGHWR_HAL_KINETIS_GPIO_PIN_DDR_IN(ALERT_PORT, ALERT_PIN);

    // Get address for PORTA
    port_p = Ports[0];
(Continue reading)

Permalink | Reply | 4 comments |
headers
René Schipp von Branitz Nielsen | 13 Feb 2013 12:35

Cyg_Mutex::check_this() fails

...Sending this from my private mail account because the eCos mailserver
blocks mail containing confidentiality disclaimers, which I can't prevent
when sending from my work mail account... :( :(

--------------------oOo--------------------

Hello folks,

I have a condition variable, c, tied to a mutex, m, and used like this with
a FIFO, f:

void producer(void)
{
    cyg_mutex_lock(&m);
    copy_to_fifo(&f, some_data);
    cyg_cond_signal(&c);
    cyg_mutex_unlock(&m);
}

void consumer_thread(cyg_addrword_t data) {
    cyg_mutex_lock(&m);
    while (1) {
        while (fifo_empty(&f)) {
            cyg_cond_wait(&c);
        }

        // m is locked here.

        // Empty FIFO.
        while (!fifo_empty(&f)) {
(Continue reading)

Permalink | Reply | 2 comments |
headers
Piotr Skrzypek | 23 Jan 2013 10:36
Picon

OpenRISC port

Dear eCos Maintainers,

Together with my colleages from Ant Micro, we have updated the
OpenRISC port. We discovered that the OpenRISC HAL was not working
anymore, probably due to ABI change. We have also added few device
drivers. All changes to the code were introduced against the code in
eCos repository. This makes me believe there is no problem with
licensing.

The code still has some identified bugs that should be fixed. Once we
get it done, we would like to contribute the code to the eCos
repostory if possible.

There is one more problem and we seek your advice. Current OpenRISC
architecture is called OpenRISC1000 (aka or1k). There is an update
foreseen. The new architecture will be called OpenRISC2000 (aka or2k)
and it will not be backwards compatible. How should we structure the
HAL directory to take into account the update in the future?

Here is the note about the update:
http://antmicro.com/OpenSource/OpenRISC-eCos

We have a small wiki page that describes the port here:
http://opencores.org/or1k/ECos

The code is hosted on OpenCores SVN, here:
http://opencores.org/ocsvn/openrisc/openrisc/trunk/rtos/ecos-3.0

Thanks in advance,
Piotr Skrzypek
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Jones | 21 Jan 2013 16:08
Favicon

Potential I2C API Enhancement

While working with the I2C interface using Kinetis to write a SMBus/PMBus layer over it, I could not
implement a probe.

PMBus developers typically probe the bus looking for slaves by sending an address and using ACK/NACK to
determine presence.

The only way one can probe with the current I2C API is to send at least one data byte, so that the return is an
indicator of success or failure. However, this is a dangerous way to probe, because it might have side effects.

Sometimes people probe with Addr+Read, but most use Addr+Write, because that avoids a potential ARA response.

I am looking for ideas how best to deal with this problem. Potential solutions:

1) Use a target specific API
2) Add to existing API, like i2c_slave_present(...
3) Add new API/Package

In my opinion, choice 2 would be the best because it is target independent, and least confusing.

The practical impact is people developing SMBus/PMBus tend to use Cortex M. There are a small number of
targets (5) in the dev tree. So perhaps it is still possible to add to the I2C API?

Thoughts?

Mike
Permalink | Reply | 3 comments |
headers
Chiou, Charles | 3 Dec 2012 13:49

eCos port/update for MIPS malta & sead3 platforms

Hello,

I would like to submit patches to update the support for MIPS platforms on the
boards Malta and SEAD3. Specifically, the patches will:

        - Update outdated drivers for proper hardware support on modern malta
        - Support the SEAD3 board
        - Retain compatibility with QEMU's malta emulator
        - Support the newest mips-sde-elf-gcc toolchain (Sourcery CodeBench Lite 2012.03-64)
        - Support running eCos in MicroMIPS
        - Verified to boot from Yamon and u-boot

Since we only focused on booting from Yamon and u-boot, we only tested
RAM configurations. However, if RedBoot support is required, we can work with
the maintainer to get a clean patch in, too.

Please let me know how I can proceed with sending the patch upstream.

Thank you!

--
Best,
Charles Chiou
Permalink | Reply | 2 comments |

Gmane