www.coridium.us/forum

I have a project in mind that may fit on this controller but I have a
few questions. I'd very much like to use a C or C++ compiler instead of
Basic. Basic works OK for toggling a bit or two but I like C better for
more complex operations.

So what's the status of a C compiler for this board? Where? How much?

Is there a I2C library?
Is there a one wire interface library?
What level can the ethernet port be programmed at?
Are there example ethernet server/client software available in the C
language?

As you can probably tell I want to be able to talk with devices hanging
from either a I2C bus and/or a one wire bus. And of course the ethernet
port.

Thanks for any info.

Jim.

> So what's the status of a C compiler for this board? Where? How much?

We use gcc so that's ready (but...)

> Is there a I2C library?
> Is there a one wire interface library?

these are the same libraries used in the normal C release

> What level can the ethernet port be programmed at?
> Are there example ethernet server/client software available in the C
> language?

this is really the issue, we have not documented how to do this, and that
documentation is a big task and very low priority.

We have done custom designs with C and the web interface for other customers.

One thing that will probably never happen is a builtin C compiler that
interprets embedded C code in the HTML (this is why the BASIC compiler is
embedded in the ARMweb).

basicnode wrote:
>
>
> > So what's the status of a C compiler for this board? Where? How much?
>
> We use gcc so that's ready (but...)
>
> > Is there a I2C library?
> > Is there a one wire interface library?
>
> these are the same libraries used in the normal C release
>
> > What level can the ethernet port be programmed at?
> > Are there example ethernet server/client software available in the C
> > language?
>
> this is really the issue, we have not documented how to do this, and
> that documentation is a big task and very low priority.
>
> We have done custom designs with C and the web interface for other
> customers.
>
> One thing that will probably never happen is a builtin C compiler that
> interprets embedded C code in the HTML (this is why the BASIC compiler
> is embedded in the ARMweb).
>
Your last point isn't of much concern to me. As long as there is a way
of burning (is that term still appropriate for flash memory?) a compiled
binary into the board I wouldn't need an interpreter.

I've been bit banging at the hardware level ever since the 6502 series
of chips came out back in the late 70's and feel quite comfortable with
driver level software in assembly languages of many chips and
computers. If there is a way to get to the hardware level from a gcc
compiled program and I could find out how the hardware is assembled
(memory mapped device address or port number, etc.) and what the
ethernet hardware was, I feel I could make it work. Especially if I was
able to ask an occasional question.

This board would be part of a larger system for data control, detection
and logging. A variety of devices would be connected to either a I2C or
one wire bus, or both. The board would run a simple http daemon to
provide web access to control or interrogate the connected devices. It
also would be able to optionally report changes in the states of inputs
to a remote computer.

If the project is successful, we'd be assembling and selling these
system as a part of a larger system of computers and software.

Thanks,
Jim.

Theres probably no need for such low level reverse engineering.
If Coridium is kind enough to tell us the eth chip (or its maybe in the
schematic) uip would likely work fine.

uip is a micro tcp/ip stack (in C).
http://www.sics.se/~adam/uip/index.php/Main_Page

Its ported and included in lots of packages like FreeRTOS.
Oh, in fact I forgot to check FreeRTOS is likely already ported to the LPC2138.

To code in C I suggest winARM or Yagarto. Or one of the commercial Arm products
will also work.

jmrobert5 wrote:
>
>
> Theres probably no need for such low level reverse engineering.
> If Coridium is kind enough to tell us the eth chip (or its maybe in
> the schematic) uip would likely work fine.
>
> uip is a micro tcp/ip stack (in C).
> http://www.sics.se/~adam/uip/index.php/Main_Page
> http://www.sics.se/%7Eadam/uip/index.php/Main_Page>
>
> Its ported and included in lots of packages like FreeRTOS.
> Oh, in fact I forgot to check FreeRTOS is likely already ported to the
> LPC2138.
>
> To code in C I suggest winARM or Yagarto. Or one of the commercial Arm
> products will also work.
>

I suspect you are right, it would be simpler to start with a working
tcp/ip stack, if there wasn't already a port. Thanks for the
suggestion, however I don't do Windows except via wine. I suspect one
or the other works OK with wine.

Jim.

> > Theres probably no need for such low level reverse engineering.
> > If Coridium is kind enough to tell us the eth chip (or its maybe in
> > the schematic) uip would likely work fine.
> >
> > uip is a micro tcp/ip stack (in C).
> > http://www.sics.se/~adam/uip/index.php/Main_Page
> > http://www.sics.se/%7Eadam/uip/index.php/Main_Page>
> >

The ARMweb uses the LPC2138 and PIC enc28j60. There is a port of FreeRTOS for
an LPC2148 (pretty much the same part).

I'd be interested in how much space it takes up on an ARMweb.

The ARMweb code started out 5-6 years ago on a completely different platform,
and then moved to the LPC2138. While its not a general purpose TCPIP, its been
tailored to do dhcp, web serving, ftp, email and udp as well as the BASIC
compiler to do inline BASIC inside served HTML. And all that fits into 128K,
allowing 300K+ of ftp space and 64K of BASIC program area.