I actually have to disagree. I think it really depends on who you follow. For a long time I didn't use twitter at all, but I've recently become active.
The hardware hacker community (think Hackaday types) on Twitter is pretty awesome and a lot of fun to follow.
Stuff like the below comes through all the time, and the discussions with people making things are great.
Someone had mentioned Contextual Electronics as a way to learn KiCad, so I got a notification about that. But yes, I also hang out here from time to time :-)
Yeah! Embedded Rust on STM32* right now is pretty good! A lot of consolidation has happened in the device crates and HAL crates recently, so I'm adjusting a bit. But, it's looking good.
I'm actually working on a post about restarting my firmware using the latest and greatest (I started working on this firmware over a year ago).
I used the RFTM real-time OS (RTOS) because it's super light-weight and handy for checking at compile time that my interrupt handlers don't cause conflicts. It's really a nice framework for any event-based firmware (a big chunk).
I had it fabricated for me by a company by Front Panel Express. In a DIY audiophile forum I saw people using them, and if they're good enough for audiophile gear, probably good enough for me :P
To be honest, I really don't know a good KiCad tutorial. I kind of just banged myself against it until I learned. But, I had previous experience with Eagle, Altium, and Cadence Allegro.
On a dev-board prototype before, I had also used Buildroot (https://buildroot.org) to create the minimal root filesystem image. This time around, I decided to use Debian since it makes installing packages I want much easier. For example, I can just apt-get install the USB wifi firmware packages instead of hunting them down and including in a manually generated image. It's still using a custom compiled kernel though, since I have custom drivers for things like the graphics hardware.
I'm trying to use Rust for as much as possible (I like Rust a lot). The STM32L0 runs rust, I bodged together a framebuffer driver in Rust, and the games in userspace are also in Rust. I'll post about the Rust framebuffer driver at some point.
Yeah, Rust is great! I've used it on several production projects for work, but not for extensive embedded work before this. Embedded Rust is getting better and better!
I've seen a split. Some people are looking for CPU acceleration. Others say Zynq effectively covers the case where FPGA designs include a soft-core anyway for high-level control, so why not make it a hard block.
Yeah, I was going to mention the PS3 too. It was the most unique hardware of the generation and definitely took the longest for devs to adjust to and learn to leverage fully.
I actually didn't originally intend it to be for retro game emulation, more for experimenting with custom hardware for each game and with 3D acceleration hardware. But, the idea of putting retro emulators in the FPGA fabric is so easy.
This seems Just the sort of thing that I need to make a physical version of my fantasy console.
It's 64k ram 8-bit avr instruction set and a blitter doing a variety of data formats. It's not quite ready for prime-time yet, but you can see some of it online. The virtual hardware registers can be seen at
https://k8.fingswotidun.com/static/docs/io_registers.html It might be quite amenable to something like this.
The read area and the write area are separate spaces. It is strictly main RAM to frame buffer.
It is pixel based instead of bit-planes, so a lot of the features of the Amiga blitter aren't required. The minterms , multiple sources and the shifter were great for masking and sliding the bits to the right place, but once you go to chunky pixels they aren't so useful.
It does pixel format conversions to convert various compact data forms to colour graphics. 8 pixels per byte in 2 colours, 4 pixels per byte in 4 colours, 3 pixels per byte (where each 3 pixel block can have 4 colours from one of 4 micropalettes), 2 pixels per byte in 16 colours.
It supports Cell modes were it can decode cells of pixels from data, mode 0 has 3x3 blocks described in two bytes each. Cells may have any two of 16 colours. mode 1 is quite similar to the NES tiled graphics mode with 8x8 cells chosen by index to a table and individually coloured and flipped.
I don't have a line drawing option but I was wondering about having some registers to accumulate with each pixel written and if the accumulators overflow the X or Y pixel position increments. It would add some rudimentary skewing for little cost.
A lot of it comes down to the fact that the blitter is doing much of the job of the display hardware in other systems. The frame buffer is the output device with no smarts at all.
I don't think 5W is too far off from what this thing draws under load. I have a 10,000mAh ~4.2V battery in it, and I get about 10 hours of life. The battery is clunky, 9.6mm thick, since it was originally intended for external phone battery packs.
Thanks! I always recommend getting hands-on for learning more about FPGAs. FPGA boards are cheaper than ever, and you have all different ones now. I'd say get a Lattice ECP5 based board (like this year's Hackaday Supercon badge). The open-source symbiflow toolchain works for these (Xilinx 7-series will be soon!).
With regard to Verilog/VHDL, you'll have to learn at least verilog at some point, but I stay away as much as I can. SpinalHDL (based on Scala) is my goto. Some people like the Python based ones like migen, but I like me some strong typing.
I have a couple of blog posts about starting to put together a Gameboy CPU on craigjb.com (not finished yet).
Thank you for the response! I'm definitely going to check out your Gameboy posts! Any other projects you recommend similar to that? I really like the idea of building something I can use.
The ZipCPU tutorials section is also great! They include verilog, using verilator (for simulation), and formal verification. And, personally, I think learning formal verification early is great, since it will probably be used more and more.
It's verilog, but you're going to have to learn some anyway. All of the new-generation HDLs compile down to verilog, which then goes into the various synthesis tools.
The hardware hacker community (think Hackaday types) on Twitter is pretty awesome and a lot of fun to follow.
Stuff like the below comes through all the time, and the discussions with people making things are great.
https://twitter.com/MrRobotBadge/status/1212038632246251520 https://twitter.com/johndmcmaster/status/1211923709910376449 https://twitter.com/mifune/status/1168604582748073986