Yahoo Groups archive
Thread
2005-03-11 by Gus
I found this online http://i.cmpnet.com/embedded/europe/esefeb05/esefeb05p34.pdf Maybe philips guys can answer these please Will LPC23xx have PHY built in? How much RAM will it have? Is the USB host or device? Is it going to be 64 pin package? For real TCP/IP application, you need over 128K of FLASH. Why they chose to have only 128K FLASH? The chip should be 256K flash and 32K RAM. Gus
2005-03-11 by Bryce Schober
On Fri, 11 Mar 2005 19:13:59 -0000, Gus <gus_is_working@...> wrote: > For real TCP/IP application, you need over 128K of FLASH. Wrong, see: http://www.sics.se/~adam/uip/ Even if each 8-bit Atmel AVR instruction translated to a 32-bit ARM instruction, the sample stack configuration here: http://www.sics.se/~adam/uip/size.html would occupy less than 32k. -- Bryce Schober
2005-03-11 by Mark Butcher
Hi Guys I have an application running on the LPC210x with a 100M LAN over SPI. The code size is about 14k with ARP/IP/ICMP/TCP/UDP/DHCP incl. small application with op-sys and necessary drivers. RAM about 3k.Compiled with IAR compiler...the same program occupies about 30k on an HC12 compiled with GNU. The uIP TCP stack seems to be rather more efficient but it depends a lot on just what it really can do - it is possible to support more or less features in the protocol layers so a comparison is not so black and white. A stack with full support could indeed get rather big. Regards Mark Butcher www.mjbc.ch --- In lpc2000@yahoogroups.com, Bryce Schober <bryce.schober@g...> wrote:
> On Fri, 11 Mar 2005 19:13:59 -0000, Gus <gus_is_working@y...> wrote: > > For real TCP/IP application, you need over 128K of FLASH. > > Wrong, see: http://www.sics.se/~adam/uip/ > > Even if each 8-bit Atmel AVR instruction translated to a 32-bit ARM > instruction, the sample stack configuration here: > http://www.sics.se/~adam/uip/size.html would occupy less than 32k. > > -- > Bryce Schober
2005-03-11 by Dan Beadle
Are you using SPI -> Ethernet? What chip? _____
From: Mark Butcher [mailto:M_J_Butcher@...] Sent: Friday, March 11, 2005 12:53 PM To: lpc2000@yahoogroups.com Subject: [lpc2000] Re: LPC23xx ethernet Hi Guys I have an application running on the LPC210x with a 100M LAN over SPI. The code size is about 14k with ARP/IP/ICMP/TCP/UDP/DHCP incl. small application with op-sys and necessary drivers. RAM about 3k.Compiled with IAR compiler...the same program occupies about 30k on an HC12 compiled with GNU. The uIP TCP stack seems to be rather more efficient but it depends a lot on just what it really can do - it is possible to support more or less features in the protocol layers so a comparison is not so black and white. A stack with full support could indeed get rather big. Regards Mark Butcher www.mjbc.ch --- In lpc2000@yahoogroups.com, Bryce Schober <bryce.schober@g...> wrote: > On Fri, 11 Mar 2005 19:13:59 -0000, Gus <gus_is_working@y...> wrote: > > For real TCP/IP application, you need over 128K of FLASH. > > Wrong, see: http://www.sics.se/~adam/uip/ > > Even if each 8-bit Atmel AVR instruction translated to a 32-bit ARM > instruction, the sample stack configuration here: > http://www.sics.se/~adam/uip/size.html would occupy less than 32k. > > -- > Bryce Schober Yahoo! Groups Sponsor ADVERTISEMENT <http://us.ard.yahoo.com/SIG=129jdk0gg/M=298184.6018725.7038619.3001176/D=gr oups/S=1706554205:HM/EXP=1110660803/A=2593423/R=0/SIG=11el9gslf/*http:/www.n etflix.com/Default?mqso=60190075> click here <http://us.adserver.yahoo.com/l?M=298184.6018725.7038619.3001176/D=groups/S= :HM/A=2593423/rand=468241571> _____ Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/lpc2000/ * To unsubscribe from this group, send an email to: lpc2000-unsubscribe@yahoogroups.com <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe> * Your use of Yahoo! Groups is subject to the Yahoo! <http://docs.yahoo.com/info/terms/> Terms of Service. [Non-text portions of this message have been removed]
2005-03-11 by Bill Knight
Mark For free stacks there is lwip (also originally by Adam Dunkels). I have it running on an LPC w/ a cs8900. Without the web pages it takes up about 50K of flash. I have 256K of flash and a bunch of exteranl RAM so have not tried to optimize it for size. Two smaller commercial alternatives are available from CMX and InterNiche. BTW - what SPI based 100M LAN chip are you using?? I have heard of the one from MicroChip but I thought it was only 10BaseT and wasn't yet available. There is also the W3100A from WizNET that is 10/100 but it's interface is the slower (400kbps) I2C. Regards -Bill Knight R O SoftWare & http://www.theARMPatch.com On Fri, 11 Mar 2005 20:52:32 -0000, Mark Butcher wrote: Hi Guys I have an application running on the LPC210x with a 100M LAN over SPI. The code size is about 14k with ARP/IP/ICMP/TCP/UDP/DHCP incl. small application with op-sys and necessary drivers. RAM about 3k.Compiled with IAR compiler...the same program occupies about 30k on an HC12 compiled with GNU. The uIP TCP stack seems to be rather more efficient but it depends a lot on just what it really can do - it is possible to support more or less features in the protocol layers so a comparison is not so black and white. A stack with full support could indeed get rather big. Regards Mark Butcher www.mjbc.ch --- In lpc2000@yahoogroups.com, Bryce Schober <bryce.schober@g...> wrote:
> On Fri, 11 Mar 2005 19:13:59 -0000, Gus <gus_is_working@y...> wrote: > > For real TCP/IP application, you need over 128K of FLASH. > > Wrong, see: http://www.sics.se/~adam/uip/ > > Even if each 8-bit Atmel AVR instruction translated to a 32-bit ARM > instruction, the sample stack configuration here: > http://www.sics.se/~adam/uip/size.html would occupy less than 32k. > > -- > Bryce Schober
2005-03-12 by philips_apps
Hi Gus, please understand that we are not releasing too much information yet, the device is still a while out. A couple hints. It is going to be the most powerful ARM7 we made yet. You would like all answers to your questions below except for the package. It might be more on everything than you expect (including the package size ;-) ) More later in the year, please do not push yet, Robert --- In lpc2000@yahoogroups.com, "Gus" <gus_is_working@y...> wrote: > > I found this online > > http://i.cmpnet.com/embedded/europe/esefeb05/esefeb05p34.pdf > > Maybe philips guys can answer these please > Will LPC23xx have PHY built in? How much RAM will it have? > Is the USB host or device? > Is it going to be 64 pin package? > > For real TCP/IP application, you need over 128K of FLASH. Why they > chose to have only 128K FLASH? The chip should be 256K flash and 32K
> RAM. > > Gus
2005-03-12 by Stephen Pelc
> From: "Gus" <gus_is_working@...> > Subject: LPC23xx ethernet > For real TCP/IP application, you need over 128K of FLASH. Why > they chose to have only 128K FLASH? The chip should be 256K flash > and 32K RAM. This has been discussed recently on comp.arch.embedded. It triggered us to look at how much RAM we need for our PowerNet system, which has multi-threaded Telnet and web servers (with CGI and ASP). Our low-end implementation runs fine on an LPC2106 with an Asix AX88796 glued onto the GPIO ports. Test show that we can run with 32k RAM, and we believe that if we go to a single-threaded server architecture, we can run in 16k RAM. The code, including the open interpreter, full TCP/IP stack, BSD style API, and all device drivers and diagnostics, occupies 109296 bytes. We could easily reduce this by 20-30% at the loss of easy debugging and testing. For applications that do not require a multi-threaded server architecture, 128k code and 16/32k RAM is enough. 64k RAM makes life comfortable. Stephen -- Stephen Pelc, stephen@... MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 23 80 631441, fax: +44 23 80 339691 web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads
2005-03-14 by Mark Butcher
Hi Bill I decided against the cs8900 since it is very big and needs 'simulated' bus lines with the LPC210x. It is also nice to be able connect to a 100MHz hub (not all can do 100 and 10), even if 100M is not necessary for throughput. I am using the MC9S12NE64 from Freescale - HC12 processor with onboard 10/100M LAN. 8k RAM and 64k FLASH - also cheaper than the cs8900 when I last compared. I have the stack optionally running on this chip with the LPC210x simply requesting services (eg. UDP or TCP port) etc. via SPI. Otherwise I let the MC9S12NE64 run as simple LAN<->SPI converter for the stack in the LPC210x. SPI between 2 processors is a bit sensitive since there is no DMA and this is a bottleneck restricting throughput to a couple of M bits/s. I prefer to let the MC9S12NE64 do the stack since the throughput is much higher and the LPC210x doesn't need to bother with the details. The MC9S12NE64 can also take over other jobs since it has quite a few free ports, A/D converters, serial interfaces, I2C etc. As an extension to an LPC210x design it is very practical since it needs only SPI and an IRQ line. A couple of questions: when you say you have external RAM and FLASH you can't be using an LPC210x - or are you reading and writing over 'simulated' bus lines? I do this for some simple peripherals but it is not very fast. Regards Mark Butcher www.mjbc.ch PS. I have written the stack myself to match with my Op-sys. Also it helps get really familiar with TCP/IP and all the internal workings. If something doesn't work properly you can't blame others for it...I decided to make it "IPV6 prepared" after looking at some open source versions which will need a thorough re-work to do this! PPS The MC9S12NE64 has another advantage. By programming it to do LAN<->RS232 convertion it is possible to connect a PC via RS232 (admittedly slow but not teh issue here) to a LAN/the INTERNET and debug the stack with real data in a comfortable environment (eg. Visual Studio) which allows a new service (eg. HDCP, DNS etc.) to be programmed and debugged in a very short time - say a day or so. PPPS I am preparing a board for LPC210x and the new Microchip device (samples should be delivered shortly) so that I can see whether it has some advantages.... --- In lpc2000@yahoogroups.com, "Bill Knight" <BillK@t...> wrote:
> Mark > For free stacks there is lwip (also originally by Adam Dunkels). > I have it running on an LPC w/ a cs8900. Without the web pages > it takes up about 50K of flash. I have 256K of flash and a bunch > of exteranl RAM so have not tried to optimize it for size. Two > smaller commercial alternatives are available from CMX and > InterNiche. > > BTW - what SPI based 100M LAN chip are you using?? I have heard > of the one from MicroChip but I thought it was only 10BaseT and > wasn't yet available. There is also the W3100A from WizNET that > is 10/100 but it's interface is the slower (400kbps) I2C. > > Regards > -Bill Knight > R O SoftWare & > http://www.theARMPatch.com >
2005-03-14 by Bill Knight
Mark Interesting idea - using the MC9S12NE64 as a ethernet coprocessor. I'll need to look into it some more. My LPC board uses a LPC2214/ LPC2292 which have external address and data busses. There is a picture of it at http://www.thearmpatch.com/lpc-sbc2.html. The cs8900 did take a little fussing to get connected properly. As far as I can tell however, it is about half the price of the MC9S12NE64. Still, using the MC9S12NE64 with processors that do not have exeternal busses definitely has its benefits. I'm presently working on a design using an LPC2138 and the WizNET chip. It is targeted for a 3"x4" pcb with a voltage regulator, processor & JTAG, a DB-9 on UART0, battery for the RTC, eeprom, W3100A, PHY, and ethernet connector. Most all of the processor I/O and PHY status lines will be pinned out. I'm hoping to keep the costs low so I can offer it at an attractive price. I've been watching the MicroChip chip and have asked them about availablity. Haven't had a lot of success, just have to keep watching their web site to see when it is available for samples. Have you had any better success? Regards -Bill Knight R O SoftWare &http://www.theARMPatch.com On Mon, 14 Mar 2005 11:45:00 -0000, Mark Butcher wrote: Hi Bill I decided against the cs8900 since it is very big and needs 'simulated' bus lines with the LPC210x. It is also nice to be able connect to a 100MHz hub (not all can do 100 and 10), even if 100M is not necessary for throughput. I am using the MC9S12NE64 from Freescale - HC12 processor with onboard 10/100M LAN. 8k RAM and 64k FLASH - also cheaper than the cs8900 when I last compared. I have the stack optionally running on this chip with the LPC210x simply requesting services (eg. UDP or TCP port) etc. via SPI. Otherwise I let the MC9S12NE64 run as simple LAN<->SPI converter for the stack in the LPC210x. SPI between 2 processors is a bit sensitive since there is no DMA and this is a bottleneck restricting throughput to a couple of M bits/s. I prefer to let the MC9S12NE64 do the stack since the throughput is much higher and the LPC210x doesn't need to bother with the details. The MC9S12NE64 can also take over other jobs since it has quite a few free ports, A/D converters, serial interfaces, I2C etc. As an extension to an LPC210x design it is very practical since it needs only SPI and an IRQ line. A couple of questions: when you say you have external RAM and FLASH you can't be using an LPC210x - or are you reading and writing over 'simulated' bus lines? I do this for some simple peripherals but it is not very fast. Regards Mark Butcher www.mjbc.ch PS. I have written the stack myself to match with my Op-sys. Also it helps get really familiar with TCP/IP and all the internal workings. If something doesn't work properly you can't blame others for it...I decided to make it "IPV6 prepared" after looking at some open source versions which will need a thorough re-work to do this! PPS The MC9S12NE64 has another advantage. By programming it to do LAN<->RS232 convertion it is possible to connect a PC via RS232 (admittedly slow but not teh issue here) to a LAN/the INTERNET and debug the stack with real data in a comfortable environment (eg. Visual Studio) which allows a new service (eg. HDCP, DNS etc.) to be programmed and debugged in a very short time - say a day or so. PPPS I am preparing a board for LPC210x and the new Microchip device (samples should be delivered shortly) so that I can see whether it has some advantages.... --- In lpc2000@yahoogroups.com, "Bill Knight" <BillK@t...> wrote: > Mark > For free stacks there is lwip (also originally by Adam Dunkels). > I have it running on an LPC w/ a cs8900. Without the web pages > it takes up about 50K of flash. I have 256K of flash and a bunch > of exteranl RAM so have not tried to optimize it for size. Two > smaller commercial alternatives are available from CMX and > InterNiche. > > BTW - what SPI based 100M LAN chip are you using?? I have heard > of the one from MicroChip but I thought it was only 10BaseT and > wasn't yet available. There is also the W3100A from WizNET that > is 10/100 but it's interface is the slower (400kbps) I2C. > > Regards > -Bill Knight > R O SoftWare & > http://www.theARMPatch.com > Yahoo! Groups Links
2005-03-14 by jamesasteres
Mark, All I can say is "wow". Is this a board level product? I don't have the luxury of time to support two microcontrollers and also write my own TCP/IP stack. How much time did it take to write the stack? Did you do it from the ground up or did you adapt someone else's code? James --- In lpc2000@yahoogroups.com, "Mark Butcher" <M_J_Butcher@I...> wrote: > > Hi Bill > > I decided against the cs8900 since it is very big and > needs 'simulated' bus lines with the LPC210x. It is also nice to be > able connect to a 100MHz hub (not all can do 100 and 10), even if > 100M is not necessary for throughput. > > I am using the MC9S12NE64 from Freescale - HC12 processor with > onboard 10/100M LAN. 8k RAM and 64k FLASH - also cheaper than the > cs8900 when I last compared. > > I have the stack optionally running on this chip with the LPC210x > simply requesting services (eg. UDP or TCP port) etc. via SPI. > Otherwise I let the MC9S12NE64 run as simple LAN<->SPI converter for > the stack in the LPC210x. > > SPI between 2 processors is a bit sensitive since there is no DMA > and this is a bottleneck restricting throughput to a couple of M > bits/s. > > I prefer to let the MC9S12NE64 do the stack since the throughput is > much higher and the LPC210x doesn't need to bother with the details. > The MC9S12NE64 can also take over other jobs since it has quite a > few free ports, A/D converters, serial interfaces, I2C etc. As an > extension to an LPC210x design it is very practical since it needs > only SPI and an IRQ line. > > A couple of questions: when you say you have external RAM and FLASH > you can't be using an LPC210x - or are you reading and writing > over 'simulated' bus lines? I do this for some simple peripherals > but it is not very fast. > > Regards > > Mark Butcher > > www.mjbc.ch > > PS. I have written the stack myself to match with my Op-sys. Also it > helps get really familiar with TCP/IP and all the internal workings. > If something doesn't work properly you can't blame others for it...I > decided to make it "IPV6 prepared" after looking at some open source > versions which will need a thorough re-work to do this! > > PPS The MC9S12NE64 has another advantage. By programming it to do > LAN<->RS232 convertion it is possible to connect a PC via RS232 > (admittedly slow but not teh issue here) to a LAN/the INTERNET and > debug the stack with real data in a comfortable environment (eg. > Visual Studio) which allows a new service (eg. HDCP, DNS etc.) to be > programmed and debugged in a very short time - say a day or so. > > PPPS I am preparing a board for LPC210x and the new Microchip device > (samples should be delivered shortly) so that I can see whether it > has some advantages.... > > > > > --- In lpc2000@yahoogroups.com, "Bill Knight" <BillK@t...> wrote: > > Mark > > For free stacks there is lwip (also originally by Adam Dunkels).
> > I have it running on an LPC w/ a cs8900. Without the web pages > > it takes up about 50K of flash. I have 256K of flash and a bunch > > of exteranl RAM so have not tried to optimize it for size. Two > > smaller commercial alternatives are available from CMX and > > InterNiche. > > > > BTW - what SPI based 100M LAN chip are you using?? I have heard > > of the one from MicroChip but I thought it was only 10BaseT and > > wasn't yet available. There is also the W3100A from WizNET that > > is 10/100 but it's interface is the slower (400kbps) I2C. > > > > Regards > > -Bill Knight > > R O SoftWare & > > http://www.theARMPatch.com > >
2005-03-14 by Gus
it seems like every one is upset I said we need more than 128K!!! Yes you can fit TCP/IP in 32K and a full blown stack can be 50K but that is the TCP/IP stack "ONLY"!! for our application we need at least 150K. Same thing for ram, we need at least 25K. Again this is our own application and you may need less or more for yours Gus --- In lpc2000@yahoogroups.com, Bryce Schober <bryce.schober@g...> wrote: > On Fri, 11 Mar 2005 19:13:59 -0000, Gus <gus_is_working@y...> wrote:
> > For real TCP/IP application, you need over 128K of FLASH. > > Wrong, see: http://www.sics.se/~adam/uip/ > > Even if each 8-bit Atmel AVR instruction translated to a 32-bit ARM > instruction, the sample stack configuration here: > http://www.sics.se/~adam/uip/size.html would occupy less than 32k. > > -- > Bryce Schober
2005-03-15 by lpc2100_fan
Gus, the applications that I saw can work reasonably well with 256k/32 which would confirm your findings. Bob --- In lpc2000@yahoogroups.com, "Gus" <gus_is_working@y...> wrote:
> > it seems like every one is upset I said we need more than 128K!!! > Yes you can fit TCP/IP in 32K and a full blown stack can be 50K but > that is the TCP/IP stack "ONLY"!! for our application we need at > least 150K. Same thing for ram, we need at least 25K. > > Again this is our own application and you may need less or more for > yours > > Gus
2005-03-16 by balazs_scherer
Hello, OK, I have used TCP/IP and applications on PIC using not more than 32k. But it is a hacking, and a garage development. For a real TCP/IP application you need multiple threads, and RAM to buffer packets. So I suggest eCos and LwIP. It a present sollution however the LwIP port and configuration options are not too well implemented (I think) and needs redevelopment. This stack uses abot 100k with eCos, but without applications (The physical layer is also a great problem, the GPIO system of LPCs are not designed for bus connections, I suggess some modifications here, beacause many applications needs an 8 bit bus, and the independed SET, CLEAR, READ mechanism of LPC is good for individual pins, but very bad for buses). The real problems in the current LPC chips is a small RAM size. I'm thing when somebody using a 32bit uc also want to use RTOS not just hacking a code. And RTOS needs RAM. I'm still using LPC2106, however I would like having ADC, DAC, but the RAM is so small in the LPC21xx versions. The LPC2138 is in the border, 32k RAM could be enought with restictions, but If there is 512k Flash, I would like about 128k RAM (256k Flash and 64k RAM is much more useable, than 512k Flash and 32k RAM). Balázs --- In lpc2000@yahoogroups.com, "lpc2100_fan" <lpc2100_fan@y...> wrote: > > Gus, > > the applications that I saw can work reasonably well with 256k/32 > which would confirm your findings. > > Bob > > --- In lpc2000@yahoogroups.com, "Gus" <gus_is_working@y...> wrote: > > > > it seems like every one is upset I said we need more than 128K!!! > > Yes you can fit TCP/IP in 32K and a full blown stack can be 50K but > > that is the TCP/IP stack "ONLY"!! for our application we need at > > least 150K. Same thing for ram, we need at least 25K. > > > > Again this is our own application and you may need less or more for
> > yours > > > > Gus
2005-03-16 by Onestone
balazs_scherer wrote: > > Hello, > > OK, I have used TCP/IP and applications on PIC using not more than > 32k. But it is a hacking, and a garage development. Hacking started this industry, and many of the most influential designs in the world began their lives in a garage. hell I don't even have a garage top work from now, but it hasn't stopped me producing significant designs. >thing when somebody using a 32bit uc also want to use RTOS not just >hacking a code. And RTOS needs RAM. I'm still using LPC2106, however >I would like having ADC, DAC, but the RAM is so small in the LPC21xx >versions. The LPC2138 is in the border, 32k RAM could be enought with >restictions, but If there is 512k Flash, I would like about 128k RAM >(256k Flash and 64k RAM is much more useable, than 512k Flash and 32k >RAM). And I complained to Philips that they'd wasted too much silicon on RAM, and Flash. Mind you I don't use RTOS, or HLL, or TCP/IP. I'd be happy with 16K flash and 4k RAM. I only want 32 bits for sheer processing speed. I can't do what I want an 8 bit device or a 16 bit device at the current consumption I need. Everybody wants different things. The ADuC702x series from Analog devices looks like a much better balanced family of parts to me, although I am still trialling the LPC. Al
2005-03-16 by Rod Moffitt
> And I complained to Philips that they'd wasted too much silicon on RAM, > and Flash. Mind you I don't use RTOS, or HLL, or TCP/IP. I'd be happy > with 16K flash and 4k RAM. I only want 32 bits for sheer processing > speed. I can't do what I want an 8 bit device or a 16 bit device at the > current consumption I need. Everybody wants different things. The > ADuC702x series from Analog devices looks like a much better balanced > family of parts to me, although I am still trialling the LPC. And might I say 'thanks!' to Philips for not listening to you! ;) I for one am rather excited about the new LPC23XX chips, not only because of the (apparent) on-board 10/100 PHY (not just the MAC, parts which lack a PHY make it a PITA since you now need another chip and more sharp-edge traces), yet also the (hopefully) larger RAM (most powerful LPC yet huh?)! We have a design that has been working for months now using a bit-banged CS8900A off of a LPC2106, using LWIP and an in-house RTOS. 60KB/20KB Flash/RAM is all that we need for the basics (multi-threading, telnet, httpd, cli, newlib, etc.), however the more RAM, the better the buffering and therefore higher the performance AND more importantly, the more applications we can handle. So, Philips, please keep on doing what you do best and add more peripherals and please more on-board RAM! - Rod
2005-03-16 by Onestone
Ah but I don't begrudge you your behemoths. I just think my end of the bar should be catered for too. When I attended the Philips seminar they actually stressed that they felt the market between 8 bitters and 32 bitters was closing, both in price and functionality. I was therefore expecting a similar range of products that you might find in a high end 8 or 16 bit device, with some blurring towards the middle range of 16 bitters perhaps. There are many applications, like mine, that simply require a little raw processing speed, at the lowest power possible. But to even approach the peripheral mix available on a medium to high end 8 or 16 bit device you have to lurch into the higher end of the LPC range. To me this seems like a gaping hole in the product line. Al Rod Moffitt wrote:
> > And I complained to Philips that they'd wasted too much silicon on RAM, > > and Flash. Mind you I don't use RTOS, or HLL, or TCP/IP. I'd be happy > > with 16K flash and 4k RAM. I only want 32 bits for sheer processing > > speed. I can't do what I want an 8 bit device or a 16 bit device at the > > current consumption I need. Everybody wants different things. The > > ADuC702x series from Analog devices looks like a much better balanced > > family of parts to me, although I am still trialling the LPC. > > And might I say 'thanks!' to Philips for not listening to you! ;) > > I for one am rather excited about the new LPC23XX chips, not only because > of the (apparent) on-board 10/100 PHY (not just the MAC, parts which lack > a PHY make it a PITA since you now need another chip and more sharp-edge > traces), yet also the (hopefully) larger RAM (most powerful LPC yet huh?)! > > We have a design that has been working for months now using a bit-banged > CS8900A off of a LPC2106, using LWIP and an in-house RTOS. 60KB/20KB > Flash/RAM is all that we need for the basics (multi-threading, telnet, > httpd, cli, newlib, etc.), however the more RAM, the better the buffering > and therefore higher the performance AND more importantly, the more > applications we can handle. So, Philips, please keep on doing what you do > best and add more peripherals and please more on-board RAM! > > - Rod > > Yahoo! Groups Sponsor > ADVERTISEMENT > <http://us.ard.yahoo.com/SIG=129912o2g/M=298184.6018725.7038619.3001176/D=groups/S=1706554205:HM/EXP=1111068487/A=2593423/R=0/SIG=11el9gslf/*http://www.netflix.com/Default?mqso=60190075> > > > > ------------------------------------------------------------------------ > Yahoo! Groups Links > > * To visit your group on the web, go to: > http://groups.yahoo.com/group/lpc2000/ > > * To unsubscribe from this group, send an email to: > lpc2000-unsubscribe@yahoogroups.com > <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe> > > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service <http://docs.yahoo.com/info/terms/>. > > >------------------------------------------------------------------------ > >No virus found in this incoming message. >Checked by AVG Anti-Virus. >Version: 7.0.308 / Virus Database: 266.7.3 - Release Date: 15/03/2005 > >
2005-03-16 by Anton Erasmus
On 16 Mar 2005 at 8:28, balazs_scherer wrote: > > > Hello, > > OK, I have used TCP/IP and applications on PIC using not more than > 32k. But it is a hacking, and a garage development. > > For a real TCP/IP application you need multiple threads, and RAM to > buffer packets. So I suggest eCos and LwIP. It a present sollution > however the LwIP port and configuration options are not too well > implemented (I think) and needs redevelopment. This stack uses abot > 100k with eCos, but without applications (The physical layer is also a > great problem, the GPIO system of LPCs are not designed for bus > connections, I suggess some modifications here, beacause many > applications needs an 8 bit bus, and the independed SET, CLEAR, READ > mechanism of LPC is good for individual pins, but very bad for buses). The PIN registers are actually RD/WR registers, and not RD only as specified in the documentation. If you write to the PIN register, it sets the pins, as specified in the bits. i.e. if you write 0xFFFF0000 to a PIN register it will set the top 16 GPIO pins high, and the bottom 16 low. Regards Anton Erasmus [Rest Snipped] -- A J Erasmus
2005-03-16 by Richard
--- In lpc2000@yahoogroups.com, Bryce Schober <bryce.schober@g...> wrote: > On Fri, 11 Mar 2005 19:13:59 -0000, Gus <gus_is_working@y...> wrote: > > For real TCP/IP application, you need over 128K of FLASH. > > Wrong, see: http://www.sics.se/~adam/uip/ > > Even if each 8-bit Atmel AVR instruction translated to a 32-bit ARM > instruction, the sample stack configuration here: > http://www.sics.se/~adam/uip/size.html would occupy less than 32k. > > -- > Bryce Schober There was a very long but also interesting thread on comp.arch.embedded on this very subject (RAM more than ROM). Search for the thread "How much RAM needed for low end Ethernet application". Shamefull plug - the http://www.FreeRTOS.org WEB site has links to two live WEB server demo's running on LPC devices. One using uIP, and one using the WizNET. Regards, Richard.
2005-03-17 by balazs_scherer
> > The PIN registers are actually RD/WR registers, and not RD only as specified > in the documentation. If you write to the PIN register, it sets the pins, as > specified in the bits. i.e. if you write 0xFFFF0000 to a PIN register it will > set the top 16 GPIO pins high, and the bottom 16 low. > > Regards > Anton Erasmus > > [Rest Snipped] > -- > A J Erasmus Thanks for the informations, I have read this functions but the data sheet said is not a legal way of using: GPIO Pin Value Register (IOPIN - 0xE0028000) This register provides the value of the GPIO pins. This value reflects any outside world influence on the pins. Note: for test purposes, writing to this register stores the value in the output register, bypassing the need to use both the IOSET and IOCLR registers. This feature is of little or no use in an application because it is not possible to write to individual bytes in this register. Maybe I have an old version of LPC2106 data sheet. But as you write it would be a usefull thing to write this register not just read. Again back to the problem of RAM and Flash size: I think most of the developpers using LPC21xx devices also would like to use RTOS. Beacuse in most of the problems which requires an 32 bit uc there are paralel things to do, and therefore we need threads (In most of the cases, where there is no need of threads a simple 8bit controller with price under $4 could do the job). And if I need threads I would like to use a complex operating system like eCos not just a kernel. The main advantage of the comlex operating system that, I can add additional packages (with a mouse click) like standard C IO, or Math functions, TCP/IP stack, File system, ... , to my application, and do not need to write it. This way makes the development shorter and easyer ( even in the garage :-) ). And the source code also become much more hardware independent. For a good RTOS applications (probably with remote boot support) I would need a minimum of 128k Flash, and 64k of RAM, of course I would be very happy if I had 256/512k Flash and 64/128k RAM. I thing more memory is not required, because in that cases the developper should use external RAM/Flash and Linux, and WinCE. Balázs
2005-03-17 by Mark Butcher
--- In lpc2000@yahoogroups.com, "jamesasteres" <jamesasteres@y...> wrote: > > Mark, > All I can say is "wow". Is this a board level product? I don't > have the luxury of time to support two microcontrollers and also > write my own TCP/IP stack. How much time did it take to write the > stack? Did you do it from the ground up or did you adapt someone > else's code? > James Hi James Sorry for the delay - but for completeness a short(ish) answer: My product is board level and is a typical embedded internet application. I have been working on it mainly in my free time since the end of 2004 (I think I started on 24.12.2004). Step 1. Bought MC9S12NE64 DEMO board Step 2. Installed GNU compiler for HC11/12 Step 3. Wrote a disassembler and dedugger for the HC12 (they have boot code allowing debugging and download over serial with break points, stepping etc.) - experimental project in parallel. Step 4. Ported my Operating system to MC9S12NE64 and integrated new Ethernet driver. Step 5. Wrote (parts of) TCP/IP stack in steps using OpenTCP as reference (result is a different solution but reference code helps a great deal - also comments about what is allowed to be left out by RFCs etc.). Debugging on hardware with own debugger but mainly using Visual studio for development [MC9S12NE64 does LAN<->RS232 conversion and the project sends and receives via COM port, although the routines use direct LAN driver when compiled for target]. Using Ethereal I record reference sequences and 'play' these back through the stack in a 'simulated' environment. You learn very quickly the details doing this and detailed study of the flags and sequence numbers and so on is rarely necessary. Step 6. SPI driver between MC9S12NE64 and LPC210x. The main goal was to prove that the operating system and stack are really hardware independent. It is possible to compile the project to configure the MC9S12NE64 as LAN<->SPI converter and put the stack and application in the LPC210x. The LPC210x opens an SPI driver instead of the LAN driver and can access the Internet without the code needing to know the details. Alternatively it is possible to configure the system to leave the stack in the MC9S12NE64 and the application runs on the the LPC210x - in this case it communicates via SPI based sockets. [I must admit that this needs some more work due to the necessary protocol at the SPI communication level..] Step 7. Application and more TCP/IP frills. EG: When I turn on the device it gets its IP config from the DHCP server and then the IP address of my POP3 Email provider via DNS - it checks whether I have mail and can give me some details about what is waiting on an LCD Display. Saves booting the PC to see whether there is post... NOTE: I am using a non-preemptive operating system. This restricts the support possibilites with TCP (mainly) but for small embedded devices which need Internet connectivity these can be tolerated on the whole.. (at least until now). What I haven't integrated yet is HTTP but this will probably be step 8. Was it worth while? I began with zero knowledge of GNU/HC12 and TCP/IP (quite good knowlegde of LPC210x and IAR) and have now learned enough to get them working together. I almost have a product ready which can do quite a lot on a remote basis, is quite cheap and flexible. There will certainly be some backlashes where I have to find out why things doesn't always run so smoothly in certain circumstances (traffic overload, error handling which has not been properly tested and so on) but I am prepared. So I think that it has been a worthwhile, if time consuming investment [BTW - the most time consuming development step was getting the SPI interface in the LPC210x to work correctly!! I actually gave up in slave mode with the conclusion that it essentially doesn't work correctly..]. Cheers Mark
2005-03-18 by Bruce Paterson
balazs_scherer wrote:
>
>>The PIN registers are actually RD/WR registers, and not RD only as specified
>>in the documentation. If you write to the PIN register, it sets the
I've read this quite a few times on this list, but when I actually tried
it on my lpc2124 it didn't work. Had to resort to using CLR and SET.
Maybe this differs based on the type number ?
--
Cheers,
Bruce
-------------------------------------------------------------------
/\\\/\\\/\\\ / / Bruce Paterson
/ \\\ \\\ \\\ / / Senior Design Engineer
/ /\\\/\\\/\\\/ / 8 Anzed Court, Mulgrave, Vic, 3170
/ / \\\ \\\ \\\ / PO Box 4112, Mulgrave, Vic, 3170, Australia
/ / \\\/\\\ \\\/ Ph: +61 3 8561 4232 Fax: +61 3 9560 9055
Tele-IP Ltd. Email: bruce@... Icq: #32015991
WWW: http://www.tele-ip.com VK3TJN
-------------------------------------------------------------------2005-03-19 by Anton Erasmus
On 18 Mar 2005 at 18:44, Bruce Paterson wrote: > > balazs_scherer wrote: > > > >>The PIN registers are actually RD/WR registers, and not RD only as > >>specified in the documentation. If you write to the PIN register, it > >>sets the > > I've read this quite a few times on this list, but when I actually > tried it on my lpc2124 it didn't work. Had to resort to using CLR and > SET. > > Maybe this differs based on the type number ? > I have only used this on a LPC2292, where it works. Perhaps Philips can clarify the situation regarding this issue. Regards Anton Erasmus-- A J Erasmus
2005-05-18 by d34db33fc4f3
Where is your information on the LPC23XX parts coming from? Any idea on availablity dates? David --- In lpc2000@yahoogroups.com, Rod Moffitt <rodlist@r...> wrote: > I for one am rather excited about the new LPC23XX chips, not only because > of the (apparent) on-board 10/100 PHY (not just the MAC, parts which lack > a PHY make it a PITA since you now need another chip and more sharp-edge > traces), yet also the (hopefully) larger RAM (most powerful LPC yet huh?)! >
2005-05-18 by Rod Moffitt
Check the original thread for links to more information on the ethernet
LPC213X line.
Since there hasn't been any recent discussion on this topic, and it is now
only weeks away from being '2Q 2005'. Perhaps 'Philips Apps' might want to
field some questions?
I for one would like to get as much information on these new devices as
soon as possible (I can't wait to dump my current NIC). I personally would
like to specifically find out about the following:
- 10/100 support or just 10?
- auto-negotiation support?
- full-duplex (plus pause frames?)
- PHY on chip?
- Rod
--
___ ____ ___ _ ___
Rod Moffitt / _ \/ __ \/ _ \ (_)__ / _/__
http://rod.info / , _/ /_/ / // / / / _ \/ _/ _ \
rodANTISPAM@... /_/|_|\____/____(*)_/_//_/_/ \___/
=======================================================
~ Where loved ones are remembered http://memoriam.org ~On Wed, 18 May 2005, d34db33fc4f3 wrote: > Where is your information on the LPC23XX parts coming from? Any idea > on availablity dates? > > David > > > --- In lpc2000@yahoogroups.com, Rod Moffitt <rodlist@r...> wrote: >> I for one am rather excited about the new LPC23XX chips, not only > because >> of the (apparent) on-board 10/100 PHY (not just the MAC, parts which > lack >> a PHY make it a PITA since you now need another chip and more > sharp-edge >> traces), yet also the (hopefully) larger RAM (most powerful LPC yet > huh?)! >> > > > > > > Yahoo! Groups Links > > > > > > >
2005-06-13 by Gus
it has been few months since we heard about the LPC chips with ethernet. Any new news about those chips? Any ideas on what can we sample those? Thanks, Gus
2005-06-13 by Rod Moffitt
I second this request! Is there any new information on these chips
Philips?
- Rod
--
___ ____ ___ _ ___
Rod Moffitt / _ \/ __ \/ _ \ (_)__ / _/__
http://rod.info / , _/ /_/ / // / / / _ \/ _/ _ \
rodANTISPAM@... /_/|_|\____/____(*)_/_//_/_/ \___/
=======================================================
~ Where loved ones are remembered http://memoriam.org ~On Mon, 13 Jun 2005, Gus wrote: > it has been few months since we heard about the LPC chips with > ethernet. > > > Any new news about those chips? Any ideas on what can we sample those? > > Thanks, > > Gus > > > > > > > Yahoo! Groups Links > > > > > > > >