This page attempts to present a history of my experiments with embedded systems, starting with my first Arduino projects. I intend for this page to be more-or-less a living document, kind of like a log summary across my projects. It will be updated at points in time. It is not intended to be stream-of-consciousness, blog-like writing
MY PROJECT HISTORY
First Arduino Circuits
Foot Pedal test
HIDUINO USB device early experiments
USB Host Shield Library
First Teensy Circuits
Broken Softstep II
Teensy Logic Analyzer
extract firmware from midi sysex file
reflash Softstep II
Teensy USB devices
Denormalized Teensy USB Library
Teensy Audio Shield 1
First SD Card Looper
Initial LoopControl breadboard
First rPi boot - Raspian (rPi 3b+)
rPi Bare Metal Beginnings (rPi zero)
Initial rPi reboot circuit
Initial Komodo integration
Initial Circle work
Ethernet TFTP bootloader
FATFS read and write kernel
my Binary Serial Protocol
Build System and recoveryN.img
Teensy Audio Shield 2
rPi zero to teensy i2sQuadDevice
devolved to a test program for I2S
Sound Injector (my wm8731)
Audio Injector Octo
rpi breadboard gadgets
my (aborted) rpi breadboard gadget
- rpi breakout breadboard 2
- teensyPi 2
- port Teensy Audio Library to Circle
- figger out and implement driver for AudioInjector Octo
- UGUI user interface - initial "Recorder" demo
- implement ili9486/xpt2046 touch screen Circle Device
- begin writing my own wsWindows, a cross between UGUI and wxWidgets
- adxl345/esp8266 & arduino accelerometer experiments
- basic wsWindows working, start adding system events (Midi, Audio notification) ...
- Quck and Dirty Zynthian in preparation for porting? fluidSynth to Circle)
Ultimately, everything I am doing is related to my goal of creating a rPi Bare Metal vGuitar Rig. On hackaday, that project will contain my commitments to the architecture and design of the rig, and will likely reference a number of specific sub-projects that add levels of detail about the pieces and parts that make up the full rig. The full project, I believe, will be too complicated to present in it's entirety in a single hackaday project. So for the rPi Bare Metal vGuitar Rig, I envision a number of pages and projects that will, when taken as a whole, explain the final thing that I (hope to) create.
"There is a road ... it's not a simple highway ..." (Robert Hunter)
Along the way there have been many other "projects", and there will likely be many more, that, although related to the rig, are not, technically speaking, a part of it. There are twists and turns on the path to the finished product. There are experiments, or series of experiments, that I have, or will perform, in order to learn about a specific technology and to generally learn about and test things that *might* be used in the rig. Sometimes I have to learn, the hard way, that something that I thought was possible is just not feasible. Sometimes the answer is to repeat the same experiment with a different, perhaps faster or more powerful processor, or to take a different approach. And sometimes I just like to try things to see what happens.
"So you who chose to lead must follow ..." (Robert Hunter)
I think there is a certain value in not only writing about the end product, the vGuitar Rig I am creating, but also to reflect on the steps taken, and the lessons learned, with the many circuits I have gotten working, or failed to get working, along the way. Almost always an experiment starts by following in someone else's footsteps. I'll read a half dozen pages about a topic, a piece of hardware, a chip, or maybe a library. I'll daydream about it for a while, and then at some point I'll start actually messing around with it. Sometimes it works out, and I get a working circuit and software out of the deal. When that happens just the fact that I have figured out how to combine library X with chip Y and processor Z, may be worth documenting, as it may have taken me weeks of reading data sheets and manuals, doing hundreds of google searches, and trying a bunch of things, just to get a small piece of code written, and to obtain the understanding of the hardware, that goes with it.
Other times I may come to the conclusion that what I set out to do is just not do-able, or not worth the effort. That's probably worth writing down too.
I'd like to write this kind of stuff down in case somebody else is looking for some of the same answers. By doing it on hackaday pages, eventually google will pick it up, and maybe the next guy will only have to do half as much work to get to the same conclusion as I did. Or perhaps someone will find a way to do something that I was trying to do, and let me know. In either case, it's worth writing about.
I will add links and subprojects as I have time.
Note on GitHub links:
It is almost impossible to keep track of all the source code I write and modify as I meander towards, and occasionally away from, my goal. Often there are multiple revisions of the same code for each experiment in a series of experiments, perhaps even on a single day. Although I keep everything in github (and you'll be able to see it someday), I don't like to keep my entire history alive in the source tree on my development machine. There are just too many files and folders and it clutters up my devenv making it hard to work with.
I keep a certain set of projects "alive" in my devenv, and utltimately these will "become" the vGuitar rig project, and most of the other vestigal project source code will be deleted from the github head of my repositories. Ultimately my goal is to end up with a neat and tidy source tree for the vGuitar rig project and a very limited number of other projects that I deem to be of relatively long term value, on github, and not a lot of other junk.
Yet, I want to be able to look back on certain project states, steps in the process, here on hackaday, if I want to, even if they turned out to be dead-ends. I'm not sure I want to use links to github SHA commits for that purpose.
So, I think, instead, I will be taking advantage of hackaday's "Files" feature to keep a static snapshot in time of certain source code files, like I would take a photograph of a breadboard for presentation in a hackaday project. Later I might re-purpose the breadboard, and likewise modify the source code for other uses, but for one moment, for the given "project", they were together and matched. By redundantly placing them here as "Files" on hackaday, it will give me an additional backup of that moment in time, without having to dig through a huge github source tree and revision history to find the (usually small) piece of code at a particular revision that is relevant to the given (vestigial) project as I refine and focus the github repositories to the finished product.
We'll see :-)