Ahah I was just thinking about that tiny web server the other day and even submitted it here, but it didn't get any traction. Back then (and even now) I thought it was very impressive!
I love how I can see the HTML being streamed onto the page in real time, like the good old days of dialup when images gradually rendered from top-to-bottom.
Brings memories. How my school trashy dial-up was so unbearably slow compared to my father's work 128 ISDN.
On latter, I was able to even download several songs per visit from ftp, and later from Napster.
The PIC32 CM has most of the features of AVR DD, including event system, MVIO, 5V operation... while offering a larger and standard ARM 32 bit M0+ core.
I fear the AVR DD is somewhat obsolete with this. AVR EA and AVR EB and their 12-bit ADC with x16 programmable gain (sensitive to 50 microvolts or so, albeit with a fair bit of noise), remains safe as that's an absurdly good ADC / current sensor.
Or alternatively, maybe this will make AVR and friends more popular? Does the knowledge of a pin compatible (??!?!?!) ARM32 Cortex M0+ make you more, or less, likely to build a top the AVR platform?
IMO, it's the peripherals that matter most. AVR DD likely offers lower power consumption (especially the 1.8V operation), but is that enough?
---------
Otherwise, very intriguing project. AVR DD is an excellent chip in any case, great to see people using it in practice.
> The obvious choice is Ethernet, but even the slowest version (10BASE-T) still runs at 10 megabits/second. Worse, it uses Manchester encoding: a zero is sent as "10" and a one as "01", so 10 megabits of data is actually 20 megabits at the wire.
Note that the AVR EB has a x2 PLL timer that probably can output manchester encoding if you spent a long time playing with it?
Maybe?
Hmmmm.
Between the LUTs, UART peripheral and PLL boosted timer circuits, it's probably possible to push out high speed manchester encoding.
Maybe not 20Mbit though. I'll have to think of it.
Microchip is known for supporting their chips for longer than most. They basically keep making them as long as there's demand. And the Dx series is pretty recent.
That they're flirting with a Cortex-M0 pathway probably suggests they don't want to keep developing another generation of 8-bit platforms after the Dx series. If they bring the same features to another CPU core, I guess that's fine.
If Silicon Labs BusyBee (8051 core. You heard me right: freaking 8051) actually ends up as the final 8-bitter so help me I'll need to punch the chip gods in their face.
That being said: AVR Ex series still has features that the PIC32 CM cannot do. I wouldn't say that the AVR is dead yet. But Microchip is beginning to hedge their bets. So we should keep an eye on future developments.
And 1.8V operation across the board still solidifies the AVR as the low power king (or at least, tied with the PIC series). Even if it's now sharing its 5V crown with another chip. I guess 5V always made more sense for the bigger and (slightly) less efficient 32-bitters.
We humans will be cleansed from the Earth in nuclear fire, and in ten thousand years the cockroaches that survive and evolve and repopulate will be running their desktops on 4GHz die-shrinks of 8051.
AVR is vastly better to program than 8 bit PIC — either by hand or by compiler from C — but some people still insist on using those PICs for simple things.
The "PIC32" name was originally used for MIPS CPUs but more recently ARM ones and PIC32A is an extended dsPIC (16 bit).
There is also now PIC64 which is currently a couple of different RISC-V implementations, one based on quad core SiFive U54 from 2018 (same as PolarFire SoC FPGAS), and higher performance (and rad-tolerant in some versions) octa-core SiFive X280 with vector processing. Microchip have I think also indicated there will be future Arm-based 64 bit PICs.
Firstly: There's a 2025 (sic!) erratum to RFC 1055 that isn't in the www.c here. The erratum (q.v.) makes a good case for how it changes the decoding algorithm, and it actually is Linux on the other end of the link in this case.
https://web.archive.org/web/20000815063022/http://www-ccs.cs...
Someone with an ACE1101 microcontroller "won". I can't find the original articles, but there is also this:
https://conceptlab.com/fly/
Webserver on a fly...
https://web.archive.org/web/20020605032321/http://d116.com/a...
It was great fun bumming the code down; eliminating ping made room for bit-banged I2C and UDP uploading to an eeprom, still <1024 bytes.
I guess nowadays one could use some of the 32bit WLCSCP microcontrollers to easily beat this.
https://www.microchip.com/en-us/products/microcontrollers/32...
The PIC32 CM has most of the features of AVR DD, including event system, MVIO, 5V operation... while offering a larger and standard ARM 32 bit M0+ core.
I fear the AVR DD is somewhat obsolete with this. AVR EA and AVR EB and their 12-bit ADC with x16 programmable gain (sensitive to 50 microvolts or so, albeit with a fair bit of noise), remains safe as that's an absurdly good ADC / current sensor.
Or alternatively, maybe this will make AVR and friends more popular? Does the knowledge of a pin compatible (??!?!?!) ARM32 Cortex M0+ make you more, or less, likely to build a top the AVR platform?
IMO, it's the peripherals that matter most. AVR DD likely offers lower power consumption (especially the 1.8V operation), but is that enough?
---------
Otherwise, very intriguing project. AVR DD is an excellent chip in any case, great to see people using it in practice.
> The obvious choice is Ethernet, but even the slowest version (10BASE-T) still runs at 10 megabits/second. Worse, it uses Manchester encoding: a zero is sent as "10" and a one as "01", so 10 megabits of data is actually 20 megabits at the wire.
Note that the AVR EB has a x2 PLL timer that probably can output manchester encoding if you spent a long time playing with it?
Maybe?
Hmmmm.
Between the LUTs, UART peripheral and PLL boosted timer circuits, it's probably possible to push out high speed manchester encoding.
Maybe not 20Mbit though. I'll have to think of it.
That they're flirting with a Cortex-M0 pathway probably suggests they don't want to keep developing another generation of 8-bit platforms after the Dx series. If they bring the same features to another CPU core, I guess that's fine.
That being said: AVR Ex series still has features that the PIC32 CM cannot do. I wouldn't say that the AVR is dead yet. But Microchip is beginning to hedge their bets. So we should keep an eye on future developments.
And 1.8V operation across the board still solidifies the AVR as the low power king (or at least, tied with the PIC series). Even if it's now sharing its 5V crown with another chip. I guess 5V always made more sense for the bigger and (slightly) less efficient 32-bitters.
The "PIC32" name was originally used for MIPS CPUs but more recently ARM ones and PIC32A is an extended dsPIC (16 bit).
There is also now PIC64 which is currently a couple of different RISC-V implementations, one based on quad core SiFive U54 from 2018 (same as PolarFire SoC FPGAS), and higher performance (and rad-tolerant in some versions) octa-core SiFive X280 with vector processing. Microchip have I think also indicated there will be future Arm-based 64 bit PICs.
Here's an 8051 with embedded 10/100 Ethernet: https://www.asix.com.tw/public/index.php/en/product/Microcon...
Firstly: There's a 2025 (sic!) erratum to RFC 1055 that isn't in the www.c here. The erratum (q.v.) makes a good case for how it changes the decoding algorithm, and it actually is Linux on the other end of the link in this case.
Secondly: Next stop RFC 1144, presumably.