public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Keith Ross (E-Lands)" <kross@elands.co.nz>
To: ecos-discuss@sources.redhat.com
Subject: [ECOS] ecos additions
Date: Wed, 25 May 2005 11:52:00 -0000	[thread overview]
Message-ID: <4293E4C6.5000904@elands.co.nz> (raw)

Hi,

I've been working with ecos for about 2 years now and produced some 
stuff that may be useful to put into ecos.
I am using the ATMEL AT91FR4062 (256K RAM/2MB FLASH, no spi 2 serial 
ports) at the moment. As this is an in-house development I am happy to 
release the code.

These are:
conexant modem driver - basically the i386 serial driver reworked.
AT command driver - looks after the speaking to the modem for you. Uses 
cyg_io_read/write
bit bashed spi driver - done before and about the same time as the ecos 
driver and uses a similar format.
ring buffer - as opposed to a FIFO. Can search buffer with strstr like 
command without consuming contents.
M41ST91 RTC/super driver.
ARM's debug communications channel (JTAG DCC) driver for diag_printf -- 
could do without this one.

We have also done some work with a uart in vhdl and the driver to 
connect ecos to CPLD.
Have a SDI-12 sensor protocol driver (Never heard of it... not surprised).

While doing the serial modem stuff we found a few oddities.
1. The IRQ is held off until DSR fires (which could be 10mS later). I 
think this may cause problems at high serial speed as some post have 
suggested. This is in the ARM serial driver for EB40A. Not sure of the 
others. It would be better if the IRQ hands off the RX data to a ring 
buffer, then signal for a DSR. Further IRQ's also put data in the ring 
buffer. When the DSR fires it will signal the app that new data is 
present, etc. Rather than at present where the IRQ fires and ignores new 
rx data until DSR has finished. A ring buffer makes better use of memory 
resource than a fifo.

2. var_io.h in at91/var is wrong and shows:
#define AT91_US_CSR_TIMEOUT 0x80 // Timeout
which should be
#define AT91_US_CSR_TIMEOUT 0x100 // Timeout
 and has several missing defines
#define AT91_US_CSR_PARE  0x80 // Parity error
//This one is useful - so that you know when to change RTS
#define AT91_US_CSR_TXEMPTY  0x200 // TX empty

and these start and stop a break (which I need to do)
#define AT91_US_CR_STTBK   (1<<9)
#define AT91_US_CR_STPBK   (1<<10)

Regards,
Keith
E-Lands Communications Ltd, NZ

P.S. My aim is to help those currently using small 8 bit CPU to move to 
32 bit ARM. So I will always be dealing with small footprint stuff. My 
app and ecos currently have a footprint of 200K. (using ARM thumb). Mind 
you an early 8 bit ('c') version without os still took 128K.


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

                 reply	other threads:[~2005-05-25  2:37 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4293E4C6.5000904@elands.co.nz \
    --to=kross@elands.co.nz \
    --cc=ecos-discuss@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).