|
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 , 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 |
LPC23xx ethernet
Started by ●March 11, 2005
Reply by ●March 14, 20052005-03-14
Reply by ●March 15, 20052005-03-15
|
Gus, the applications that I saw can work reasonably well with 256k/32 which would confirm your findings. Bob --- In , "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 |
Reply by ●March 16, 20052005-03-16
|
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). Bals --- In , "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 , "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 |
Reply by ●March 16, 20052005-03-16
|
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 |
Reply by ●March 16, 20052005-03-16
|
> 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 |
Reply by ●March 16, 20052005-03-16
|
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 > <http://www.netflix.com/Default?mqso`190075" target="_blank" rel="nofollow">http://us.ard.yahoo.com/SIG9912o2g/M)8184.6018725.7038619.3001176/D=groups/S06554205:HM/EXP11068487/A%93423/R=0/SIGel9gslf/*http://www.netflix.com/Default?mqso`190075 > > > >. > > |
Reply by ●March 16, 20052005-03-16
|
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 |
Reply by ●March 16, 20052005-03-16
|
--- In , 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. |
Reply by ●March 17, 20052005-03-17
|
> > 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. Bals |
Reply by ●March 17, 20052005-03-17
|
--- In , "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 |
