Slashdot Mirror


Contiki on Ethernut

randomErr writes "Many of you may remember Contiki, the OS and GUI for the C64 and many other 8 bit platforms, which was posted on Slashdot in March. Adam Dunkels has ported Contiki to a more modern platorm: the open source Ethernut board. You can also see the working webserver and VNC server."

8 of 131 comments (clear)

  1. Re:Not for long . . . . by notb4dinner · · Score: 3, Interesting

    The web pages you are watching are served by a web server running under the Contiki operating system on an an Ethernut embedded Ethernet board, which consists of a 14 MHz AVR Atmega128 microcontroller with 32 kilobytes of RAM and 128 kilobytes of flash ROM, and a RealTek RTL8019AS Ethernet chip. :)

  2. Re:Question by randomErr · · Score: 4, Interesting

    Imagine a low cost, already documented, platform that could be used for say plastic injection machine controllers. Think about a Minitel like device for a $100.

    --
    You say things that offend me and I can deal with it. Can you?
  3. I'm impressed by KjetilK · · Score: 2, Interesting

    Wow, 15 comments, and the Ethernut webserver is still running fine. Wow, I'm impressed! Looks like servedby.advertising.com is going to be /.ed before that card! :-)

    --
    Employee of Inrupt, Project Release Manager and Community Manager for Solid
  4. Current Connections by tomzyk · · Score: 5, Interesting

    HA. I got to see the true Slashdot effect in action.

    I went to the Current Connections screen and only saw 2 ... that's right, TWO... connections. Literally, a few seconds later I refreshed the page and constantly got garbage in return. (Basically, it looked like the server would never output the entire HTML document. I'd sometimes see some gibberish, sometimes some CSS code, sometimes only the navigation table...) After about 60 seconds of refreshing the page, I finally saw the page again. Results: about 50 connections. And this Slashdot article only has 19 comments so far.

    Burn little server, burn. :D

    --
    Karma: NaN
  5. Re:Not for long . . . .but it works! by jkrise · · Score: 2, Interesting

    Faster than IIS, I should add. Reminds me of a naive qn. I used to ask: If a 486@66MHz and 20MB RAM can run Win95, and pretty fast as well, why can't we have 100 times faster response with a PentiumIV@ 2.4GHz running WinXP (which is upposed to be faster than Win2K, which in turn is supposed to be faster than Win98 which in turn is supposed to be faster than Win95)

    --
    If you keep throwing chairs, one day you'll break windows....
  6. Who's cracking whose nuts?? by jkrise · · Score: 2, Interesting

    This is the FIRST site I can still access, full 15 minutes after a Slashdot article! Maybe a lesson in it for all bloatware.

    --
    If you keep throwing chairs, one day you'll break windows....
    1. Re:Who's cracking whose nuts?? by SkArcher · · Score: 2, Interesting

      I'm getting some dropped pages, but i've seen 503's within 5 minutes of a slashdotting, so the fact that this little thing is hanging in there is quite impressive

      --

      An infinite number of monkeys will eventually come up with the complete works of /.
  7. that is fucking sweet by autopr0n · · Score: 5, Interesting

    And, it seems like the web server is withstanding the Slashdot effect! I remember there was actualy a C64 based web server that was actualy able to hold up based on some pretty impressive TCP hacks that made the connections 'stateless' (by embedding state in the TCP sequence number, IIRC)

    That said, I doubt a 14 mhz chip would really have that much of a problem dealing with hits. I think most of the systems that 'go down' when hit by a hit torrent do so because A) They run out of bandwidth, get capped, etc. or B) They are using super-bloated web app code when they really don't need to. You often see things like "MySQL errors" and the like from too many user connections. I think a lot of web developers don't really bother to code for efficiency at all. I mean seriously, the work you need to do to serve a mostly static page is really tiny. An intelligent caching routine should solve most of the problems, but most web-apps it seems get all data out of the DB every run, possibly doing multiple queries. Keep in mind a 386 running Apache can saturate a t1 line. That would have a clock speed of about the same thing, I think the fastest 386 was about 25 mhz. Of course, this is a 32 bit chip, not 8 :)

    The way autopr0n works, I have a class system that holds all the data, and gets updated independently of the database whenever new data is entered. I hardly ever need to do a query to get new data out of the system. Unfortunately, this means that it's using code I wrote myself, which is just buggy as hell : P. Oh well. It runs 'well enough' :P

    --
    autopr0n is like, down and stuff.