As mentioned by another comment, the flash chosen a 16 Mbit according to Avnet's listing. Storage during component selection is pretty much always in bits, whereas consumers like bytes. That being said, the board should be reworkable to swap the flash.
Other notes:
1. Differential routing was mentioned, but no mention of impedance. It's a short run so it's probably fine (I've run high speed over jumper wires before) but it should be noted.
2. There's merit to it being a very simple board, but an SD card connector may have saved the usability and likely really expanded what you can do with the system.
3. The workaround to load directly into DDR was good thinking.
4. Again understood for simplicity but LDO-ing almost 4V down for a core rail is unideal. I couldn't easily find specs on how much current will be taken on this (or any) rail, but just remember that every milliamp here is 4 milliwatts burned as heat.
5. Good to use a simple SoC like this. Integrating DDR and QFN show a real reverence for the challenges one can run into with modern LP5 and BGA parts. Really don't want that so early in the education.
As for the SPI flash size: they are almost always given in Mbit, so 16Mbit is 2MB hence the confusion if I were to guess. You would be looking for a 128Mbit one to get 16MB.
Having used a ton of vendor Linux BSPs over the years, I can say that often they’re not trying to lock you in to a particular approach when they describe how to EG blink an led. Rather they’re demonstrating that it can be done somehow. Every vendor expects you to take their demo code, evaluate it, and make decisions on your own to get to a working system. I’ve seen a lot of employers get into trouble over the years by shipping the vendor’s code unmodified. Even for LED blinking I might use the vendor’s code as a jumping off point and use the LED subsystem to implement different blink rates. But if I’m using EG a TI AM3359 I might want to go the direct register route instead of the LED is used by the real time coprocessor instead in my application. Usually more hands-on distributors like Arrow have Application Support Engineers who can advise for a particular board so you’re not stuck crawling vendor message boards for advice.
The F1C200s has 64MB of RAM, but usually these class of processors move to external RAM.
If you are willing to move to external RAM the iMX6 line is a great processor. Up to 1Ghz, eMMC, some have a GPU. Really great Linux support and documentation.
Some people have an unhealthy obsession over the tiniest, most insignificant things.
In this case it's probably about using U vs V for voltage (U is eg. more commonly taught/used in Europe and is recommended by IEC norm 60050 [1], V is more commonly taught/used in North America ; there might also be different conventions in different industry branches). In the grand scheme of things it doesn't matter of course, but you know, we are on the Internet.
Electric potential is V according to that site [1]; though im not familiar with whatever minute differences U vs V is in Ohms law...growing up I learned it as E or V.
Other notes: 1. Differential routing was mentioned, but no mention of impedance. It's a short run so it's probably fine (I've run high speed over jumper wires before) but it should be noted. 2. There's merit to it being a very simple board, but an SD card connector may have saved the usability and likely really expanded what you can do with the system. 3. The workaround to load directly into DDR was good thinking. 4. Again understood for simplicity but LDO-ing almost 4V down for a core rail is unideal. I couldn't easily find specs on how much current will be taken on this (or any) rail, but just remember that every milliamp here is 4 milliwatts burned as heat. 5. Good to use a simple SoC like this. Integrating DDR and QFN show a real reverence for the challenges one can run into with modern LP5 and BGA parts. Really don't want that so early in the education.
Overall good article, and good work