06/19/2019 at 03:11 •
I added the AudioControlSGTL5000 object to my port of the Teensy Audio Library available at https://bitbucket.org/phorton1/src-circle/src/master/ This is, of course, just part of my ongoing rPi bare metal vGuitar Rig project, but I felt like a “page” would be the best way to present this information.
These classes allows one to connect a Teensy Audio Shield, or other SGTL5000 to a Raspberry Pi within the bare metal Circle environment.
It turned out to be a little more difficult than I originally thought it would be. The sgtl5000 / teensy shield absolutly requires an input MCLK. For 44.1khz sound, that clock has to run at 11.289Mhz. Here’s a handy snippet of code to produce an 11.289 Mhz clock in Circle:
LOG("starting MCLK",0); u32 freq = SAMPLE_RATE * 256; // 11289600 u32 divi = CLOCK_RATE / freq; // 44 u32 modi = CLOCK_RATE % freq; // 3257600 u32 divf = (modi*4096 + freq/2) / freq; // 1182 // printf("divf=%d should equal 1182\n",divf); // the above math overflows 32 bits divf = 1182; m_MCLK.Start(divi, divf, 1);
There is no good way on the Pi to generate 3 synchronized clocks, the other two being needed are the the BCLK (bit clock) and FCLK (frame clock, also known as the LRCLK). The bcm2835 PCM peripheral can, as a special case, generate a synchronized FCLK for a given BCLK, so it can usually act as a master to i2s devices, but for the sgtl5000, which requires a 256fs master clock, it just cannot reasonably be programmed to act as an i2s master.
So, instead, my code for the rpi generates the 11.289Mhz MCLK on GPIO4, sends it to the sgtl5000 (teensy audio shield), which then acts as the i2s master, generating the BCLK and FCLK signals based on that. And therefore, in Circle, the AudioControlSGTL5000 is actually not implemented, and you must use the AudioControlSGTL500slave device instead.
It works ok, however, and so is worth checking in.
Below is a diagram showing the pin connections between the Raspberry Pi and the Teensy Audio Shield. Note that this is *just* the Teensy Audio Shield … there is no Teensy running the codec … it is connected directly to the Pi.
I made a simple breadboard for the Teensy Audio shield by gluing two of the small standard breadboards together (after sanding the joining edges to remove some space), and running jumpers. This allows me to just use regular wires to connect things. I HATE DUPONT FEMALE CONNECTORS !!!
Circle TeensyQuad device
I also added two additional new classes, AudioInputTeensyQuad and AudioOutputTeensyQuad to the library. These allow the Pi to be connected to a Teensy that is actually running an existing Teensy Audio Library program, so the Pi can act as a (relatively larger, big
brother) audio co-processor to the Teensy.
The teensy MPU has two i2s modules (as opposed to the one on the bm2835) that run synchronously. Paul has created the AudioI2SQuad input and output devices to allow two teensy sound shields to be stacked for quad io.
These classes allow you to easily use any rPi, including the zero and 3B+, as a DSP co-processor to a teensy audio application. It *may* even allow you to retrofit such an additional processor into your existing Teensy audio application with a minimal set of changes.
+-------------------+ teensy +--------------------+ | Teensy Audio | quad channels | rPi | | application | 2 & 3 | acting as an audio | | using quad | <===============> | co-processor | | audio device | | | +-------------------+ +--------------------+ ^ | | | teensy quad | v channels 0 & 1 IN OUT
The teensy quad device channels 0 and 1 are used for the main audio input and output, from a mic or line input, out to line or the headphones. The teensy quad device channels 2 and 3 are used to communicate with the rPi.
From...Read more »
06/02/2019 at 06:49 •
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
- AudioInjector Octo
more to follow ....
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...Read more »
05/24/2019 at 18:32 •
I am just getting started with Hackaday and am learning how to present the information I want to present.
I'm not sure what's what at this point, so am starting by "adding a page". I'm believe this "page" is associated with my profile (not with a specific project), and so is probably the most general stuff, in nature, that I can type.
I suspect this constitutes my profile-associated stream-of-consciousness, real-time "blog". Similar to what I might write on Facebook, there are a series of "pages" that are topical to whatever I happen to want to talk about at a given point in time. It *might* reference projects, sub-projects, repositories, or other web-pages of my own or other folks, and parts of it *might* be project specific, or not.
Associated with each project are a number of structures, including a "Details" box, and
I'm not sure how to best use these. I have already started the "Details" box, but I don't think what I typed there is appropriate. I think "details" is a single set of text and would be best served as a brief presentation of the highest level architecture of the system. I feel like "Logs" or "Discussion", and even references to external "Files" are probably more appropriate for keeping a history of the project and/or providing more rigidly structured information like detailed architectures and designs.
I do know that I want to document this journey. Both my personal emotional and day-to-day feelings and situations, as well as providing a more stable and static technical presentation and discussion of the pieces and parts of it.
From this page, I feel like I need to try each of the above things "Files thru Discussion" and see how they work.