Hacker News Reader

Comment by pjmlp | Hacker News Reader

> With 264KB of RAM, you can concentrate on implementing features, not optimising your application for size.

I love this comment.

Anyone old enough to have coded for 8 and 16 bit home computers, or older mainframes knows how this is true, but it feels quite funny on the day and age of multi-GB heap sizes.

View on HN

Indeed, 264KB is super luxurious for a M0 class device. For measure, I recently fit an IPv4 stack (UDP, IP, DHCP, AutoIP), USB MIDI device stack and audio processing threads with 35ms audio buffer in ~90KiB RAM (M4 class device).

RAM for microcontrollers is another name for cache on our modern processors, and even today we only measure that in megabytes since it takes up a ton of silicon area.

This device doesn’t do video but for a computer like device you’d want it to drive a 1920x1080 display, which is about 6 mb of framebuffer already. And then you need content to put on it.

Nah, for C64 or SAM coupé class hardware would be quite alright.

the chip can do some video, but low res:

- https://excamera.com/sphinx/store.html#gameduino-3x-dazzler-... - https://www.adafruit.com/product/4984

While your point in general stands, I do want to point out that 1080p video from a RP2040 has actually been done, and is mind-blowing.

https://youtu.be/mjFwR3feyV0

This definitely isn't the sort of programming where you can just wastefully allocate ram for a full uncompressed frame buffer, but that also opens the door to sub-frame latencies.

I don't have the need for a FHD display driven by a MCU, but 'racing-the-beam' seems feasible with a RP2040.

(which would allow using the screen at high resolution for, say, game graphics -- actual video is a different story)

Reply on news.ycombinator.com