IMHO devices like BBC:Micro Bit and Raspberry Pi Zero are far to be simple, and this is the reason that they are good for schooling, are complex but made easy to use to create project based on them. Remain the fact that operates at two different levels and a different minimal knowledge base it is needed; also the same project (maybe the classic LED blinking) follows two different path when running on the Zero Linux machine instead of the BBC micro controller.
UNO I think not. At least not at the same level of the BBC as it is based not only on an old hardware generation but also because the programming approach si more oriented to the language. I think should be considered the third element (with the BBC and Zero) to complete che choice.
About the Codebug I think that the best thing is to consider it a flop, at least respect this depicted scenario; they never relased the promised information, as far as I know never evolved and mimcs the BBC with an incredibly limited set of options and interfacing. Not more than just a toy.
I think something along the line of schooling (especially home) would be a low price project that could allow for simple devices like the BBC:Micro Bit or Raspberry Pi Zero (seems like the Zero has been easier to obtain over in the US. Maybe the UNO or Codebug as well?
I also agree with robotics being a great way to see what it is like to do some programming that directly speaks to and interacts with hardware in a way that you can visualize. I do think that it is also a great tool for beginners as it is something "cool" and has many stages to jump in at, from beginner to advanced, making it a great place to learn and grow in.
I am big on robotics, especially for younger people. I am constantly amazed by the solutions that show up to the F.I.R.S.T. competitions. Robotics might be another area for monthly project, but what I wanted to propose was mostly developing software puzzles, and how to go about tapping into group smarts.
" From my time writing games, I discovered nothing exercises the capabilities of a computer as much as a game, and nothing requires more general knowledge of a system's operation that writing games. To this day, whether I am writing code for a controller, a diagnostic monitor, a simulator, what I see is a video game. The difference is just the consequence when something goes wrong."
I had bought the Parallax Hydra Game Dev Kit for this very purpose. It is/was a great platform for retro game dev. Robotics is another area to get the full picture of where software meets hardware; there certainly is a lot of moving parts.
The "whys" of an investigation can be endless. The weighing of cost and benefit sometimes seems to have no solution. The other factors for determining why is dealing with opinion over fact and what sometimes rise to the level of religious wars. Used to be fights over Intel v AMD, or worse x86 v 68000. Zealots were everywhere.
As you point out, often the platform is "the one that is available" which is why, when I write code, I always try to maintain platform independence whenever possible.
A couple of wise thoughts I have picked up:
Arguing with an engineer is like wrestling with a pig in the mud. You both get covered from head to toe, and the pig loves it.
If there is a room full of N engineers you will always get at least N+1 "best" solutions
Jack, IMHO the question of Why is strictly depending on the project. Here in most of the cases the approach is: I have this platform and want to do this. I try to give suggestions as I can but I am aware that a better approach is just I want to reach this goal, what platform should I use? Better Better
DAB is spot on! I started off in real time systems (what it was called before embedded) working on brake dynomometer control, then got into writing video games for Atari and Commodore. From my time writing games, I discovered nothing exercises the capabilities of a computer as much as a game, and nothing requires more general knowledge of a system's operation that writing games. To this day, whether I am writing code for a controller, a diagnostic monitor, a simulator, what I see is a video game. The difference is just the consequence when something goes wrong.
balearicdynamics hit on my thinking for what to use for platforms. There are several platforms out there, depending on the application Raspberry Pi, Arduino, and Beagle are a few more. The projects that are available for these platforms focus on the how. I think where I am aiming with this is working on the why question. Why should I use one platform over another? Why do I need a database? Why did I want to solve this?
Jack
I have started a discussion at If I Had a Hammer covering the same topic.
When aiming for themes for students and hobbyists, it may be beneficial to do something that either necessitates working on mostly software and less hardware or vice versa so that it does not burden the maker. An example is the use of any existing experimentation kit at home or school to make a desired project. I had a student group that added motors, wheels and batteries to a benchtop kit at the university. It was a Bluetooth robot with a wooden enclosure sitting on top but it worked. Alternatively, today the EVMs and kits are quite small. The theme could focus on using an EVM, dev board or the like without a lot of hack and slash. Focus on the programming to make say an "ugly wearable" or "Not-so-portable portable" etc.
Another theme that could work is "no software" where the project must use only mixed circuits. Making a line following robot is quite simple and can be done with an op-amp, transistors and relays. "No microcontrollers necessary"
While on the subject of themes, may I suggest something like "Assistive technologies" again? Consequently, the flip side is also interesting where the focus is on creating projects that are "larger than life". I recently read an article about a 12foot guitar that was playable and was used at the entrance of a music festival. It could attract a few ideas.
Top Comments