You know - as much as I like the Arduino, I have always sincerely wished the Massimo hadn't done an 11th hour rush job on parts placement, leading to the 0.05 inch foul-up on the headers.
That one, oh-so-minor difference is a thorn in many a uC experimenter's side, because it means that standard 0.1" spacing of pins to make custom shields is impossible without special thru-pin headers, bending pins, third-party thru-hold blank shields, or just leaving one or the other header off entirely (which isn't a real solution if you need one or more pins on both headers).
We could have seen a ton of custom 0.1" proto and strip-board shield designs, but instead we are thwarted by this one simple mistake caused by being in a hurry due to a deadline.
Now - we are stuck with it - likely forever, because each new iteration of microcontroller hardware almost guarantees that there will be support for "Arduino Shields" because so many are out there. Yes, I know there are experimenters "blank" shields - but they are rarely as inexpensive as a standard 0.1" PTH PCB - and almost all of them are the size of a single shield, none larger.
It would have been nice, for instance, to be able to put in extra-long pin headers on an Arduino, then plug that on top of another larger PCB with standard hole spacing (whether soldered in-place or via headers too). Instead, the only option is to "build" the Arduino onto such a custom board (ie, program an ATMega328P and plop it on the board with resonator/crystal/power/etc).
While I agree that it sucks the arduono headers aren't spaced nicely for standard prototyping, I think this issue has been largely solved by the more recent versions like the Arduino Mini. I actually much prefer that form factor to the larger original one, as it fits in smaller cases, has less "fluff" (silkscreen, FTDI, etc) that costs more and isn't always used in development, and fits in a small space on a standard Porto board!
Plus there are many versions out there within the arduino ecosystem, including larger pin count ones, faster processors, and even ones that use non-Atmel chips like the Teensy.
While I agree that the ecosystem has provided solutions, I would have to respectfully disagree with your conclusions.
Had the problem been solved, we would not see new SoC and microcontroller platforms (heck, I think there's even an FPGA dev platform out there too) that continue to supply properly-spaced headers for this issue.
Doing so continues to perpetuate the problem, not solve it, in my opinion. A real solution would be to fix the issue (ideally, by the Arduino team), and there being a push to adopt the new layout/spacing. Perhaps an adaptor shield could be created, too, for legacy support.
Honestly, this should have happened immediately after it was found to be an issue (which likely would have been seen a long time ago with the early ATMega8 RS-232 boards made for the educational classes or whatever Massimo made the boards for originally); it should have been corrected there and then, with the next iteration.
But, history is history, and there's nothing we can do but lament, learn, and move onward...
And I'd expect a micro controller to have on-board flash, not some SPI nonsense that has to rely on the 16K cache for performance.
But AFAICT flash memory is an area full of patents and secret sauce. I'm not sure what's involved but it would be nice if some open flash designs become available soon.
SiFive have opened up all the digital pieces of the design (namely HDL and SW), but a lot more is needed to make an IC. Analog I/O, power supplies, clocks, PLLs to name but a few.
Currently "open source IC's" extend to the HDL piece only - embedded flash in 130nm is a highly complicated piece of IP and is either available by third party or through the foundry under license. I am assuming the SRAM physical IP (16KB) in this chip is also a propriety library as well.
Having recently been through building a not dissimilar IC I rushed to be first in line to pick up one of the founders HiFive1 boards (its a great board - really tidy) - this project is a huge step in the right direction. Consider this alternative - in trying to figure out some complicated ARM Cortex-M bug recently, the final solution was found by 'a friend sourcing some information from China'; this is for IP that we'd paid for (although not enough!). ARM are not bad at support at all, but we are very small and help doesn't often come to those who need it in this situations, but those who find it. I'd much rather have an IC with all the digital pieces available and an open community of people integrating it into various projects when trying to make my own project succeed.
It's open source logic design, not semiconductor process. The SRAM for memory and caches is almost certainly fab-supplied too, as are the specific gate layouts, PLLs, etc... All that stuff is going to be secret sauce NDA'd IP specific to the process they were using (FWIW: does anyone know what/whose process that is?). Flash isn't fundamentally any different.
Presumably they just didn't want to devote engineering time to something nonessential for the first project.
Really Flash is more worse than memory, caches, standard cells, PLLs, etc -- it requires significant process additions to fabricate the floating gate, as well as modifications to support high voltages, circuits for high voltage (charge pumps).
The well-known PIC16C84 microcontroller was introduced in 1993 and included 1K of 14bit EEPROM code memory. I don't know how difficult it would be to include EEPROM in the FE310, but any 1993 patents have already expired, and even small EEPROM is very useful in many cases because it avoids the need for external memory. If Flash can't be included in an open design then EEPROM would be better than nothing.
Flash surely could be included. But this is HiFive's minimum viable product. Their core deliverable was the CPU core. Peripherals probably got trimmed if they weren't easy.
Quad SPI XIP is pretty common these days. Plenty of modern MCUs bundle it as an option, some like this one (but also some Toshiba part, to name one) use it as the only option. It's workable, and you can put performance-critical code in RAM anyways. That is, if you have enough RAM...
With test boards, too. They cost an arm and a leg but just saying it was put into production & even available. Same, proven I.P. w/ GPL license could've been printed on 350nm or 500nm in a shuttle run to get a cheap microcontroller.
On side of riskier ones, there was Plasma MIPS and Amber ARM that might have been turned into ASIC's. Less risky, but less supported, OpenRISC was turned into one. RISC-V is best contender right now far as most openness and industry support. Great there's boards with some of them. Leon is still ahead in terms of features & performance on something you can actually buy. I still think someone should try converting the Leon3 + libraries to a RISC-V to get its I.P. as a starter pack.
> I will simply link to the Nirvana fallacy and ask them to point me to a microcontroller that is more Free and Open Source.
What? To me this reads like: "Here's a pink unicorn! If you argue it's a brown horse with a cardboard corn I dare you to show me a horse that is more unicorn!". Is it open source or not?
It is an open system that includes a closed component (FTDI FT2232HL chip).
Open Source (software) equivalent would be something like a Linux distribution that is generally fully open source but relies on a binary blob driver for the videocard... Is it still "open source"? Yes, mostly, but not 100% fully.
That's pretty cool if the only closed source part is a USB-UART IC. Not much secret sauce there; I bet if you wanted to be pure you could implement that function on a second FE310 with software bit-banging.
Followed up with the best attempt at a pickup line by a hacker in the movies. Back before the movies had them making out with random women in bathrooms over job offers involving sex, alcohol, bombs, and Houdini tributes. Hackers got really cool really fast. ;)
I think the point is that "RISC" should have been "RISC-V". "RISC" = "Reduced Instruction Set Computer", which encompasses many architectures. It's more of an approach to designing an architecture, and encompasses things like ARM ISAs, etc, whereas RISC-V is a specific architecture.
The line "RISC architecture is going to change everything" is a quote from a film (Hackers, 1995) that you're expected to know by heart if you want to be in this treehouse, or something.
They don't seem to have made it to any of the common distributors that I've checked. My guess is that they haven't gotten the quantities yet where they can do that. The HiFive1 is only a few months out on the market and the only thing using the chip they had made. It seems to have done well (~1k of them sold in the crowdfunding it looked like). So I hope we'll see them start to show up soon, even if you can't get them in massive quantities yet.
That one, oh-so-minor difference is a thorn in many a uC experimenter's side, because it means that standard 0.1" spacing of pins to make custom shields is impossible without special thru-pin headers, bending pins, third-party thru-hold blank shields, or just leaving one or the other header off entirely (which isn't a real solution if you need one or more pins on both headers).
We could have seen a ton of custom 0.1" proto and strip-board shield designs, but instead we are thwarted by this one simple mistake caused by being in a hurry due to a deadline.
Now - we are stuck with it - likely forever, because each new iteration of microcontroller hardware almost guarantees that there will be support for "Arduino Shields" because so many are out there. Yes, I know there are experimenters "blank" shields - but they are rarely as inexpensive as a standard 0.1" PTH PCB - and almost all of them are the size of a single shield, none larger.
It would have been nice, for instance, to be able to put in extra-long pin headers on an Arduino, then plug that on top of another larger PCB with standard hole spacing (whether soldered in-place or via headers too). Instead, the only option is to "build" the Arduino onto such a custom board (ie, program an ATMega328P and plop it on the board with resonator/crystal/power/etc).
/sigh/ - oh what could have been...!