• OK, but seriously ... Hackaday Reorganization

    07/24/2019 at 19:25 5 comments

    I have a pretty good idea now how hackaday.io works.  My first three months have resulted in a hodpodge of projects, pages, log entries, and links to a bitbucket repository.  Although I would like to salvage what I can from those projects, pages, log entries, and repositories, I feel it is now time to kind of "start over" to provide a better framework going forward.

    The most important Hackaday "thing" is the now published link to the rPi bare metal vGuitar rig hackaday.io project and my three (3) followers :-)

    Besides that, my general profile serves as a master container for subprojects and pages, and that entry point will also be retained going forward.

    (1) I need to move the source code, generally out of Bitbucket and into GitHub.    Why?   I think I might trust Microsoft more than Atlasian, and I just feel like GitHub will be here for sure, going forward.

    (2) Add lots of readme.md's to the GitHub project and subdirectories.    Why?   Because I like the idea of providing static or semi-static contextual information for the source code at the directory level.   In fact, I am not thrilled with using Hackaday.io for the long term preservation of static information about the source code, how to build it, etc.   I like the idea of information that is keyed to the commits I make, as the structure, semantics, and usage of the code is a moving target and can change over time.   Hackaday does not lend itself to versioning, it seems better for recording snapshots of a moment in time, and presenting them in a separate linear context. i.e. as a fixed index into the morphing github commits.

    (3) Create GitHub "pages" for the long term documentation of the architecture, components, APIs, etc, in the project(s).   Why?   this is a tough one.   Mostly because they are a natural fit for linking from the readme.md's in the source repository directories and subdirectories.

    Although in a sense I like the hackaday.io "editor" functionality, and the ability to upload images to their servers, etc, I sometimes find it constraining.   Even if I try to use the <> raw HTML feature, it is just the nature of WYSIWYG html editors that they stomp on the HTML and create lots of artificial constraints on the presentation.   One thing that I have always struggled with, even in pure html, is to get two images to present side by side with a caption underneath each.    It can be done in html, but I would be afraid to do it in the hackaday.io editor for fear that that it will get stomped on in some round trip to html and back.     I had a heck of a time just getting the bullet list on my history page to work consistently.  The editor seems to want to make it's own decisions about the font faces and attributes of the text and does not change well between outdended (no bullet list) and indented (bulletted) items.  It's not a slam on hackaday.  I've written these kinds of WYSYWIG editors and they are not easy and always iffy somewhere around the edges.

    (4) Use hackaday to present the most visually appealing aspects of what I'm doing.   I think hackaday.io serves as a great entry point for people surfing the web looking for interesting things to look at.  I think there is still a role for hackaday "pages", like this one, for extemporaneous stream-of-consciousness writing.

    I like the eye candy of hackaday. 

    If anyone else was interested in joining the project, perhaps that is what hackaday would be best at.  Unfortunately (a) no one has expressed an interest, and (b) I'm wary of inviting people because a one-person project gives me ultimate flexibility.   In order to properly move to a multi-person project, a LOT has to be established between the players ... from coding conventions to areas of responsibility to processes and procedures.  I think I ...

    Read more »

  • Pi Circle to Teensy Audio Shield and Quad Audio device

    06/19/2019 at 03:11 0 comments

    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. 


    Read more »

  • There is really only one project ...

    06/02/2019 at 06:49 0 comments

    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


    First Arduino Circuits

    • Foot Pedal test

    • HIDUINO USB device early experiments

    • USB Host Shield Library

      • usbHSLHostExample
      • Max3421E

      • myUsbHostExample
      • myUsbDeviceExample
      • myUsbPassThruExample

    First Teensy Circuits

    • Broken Softstep II
      • Teensy Logic Analyzer
      • myCL2 library
      • extract firmware from midi sysex file
      • reflash Softstep II
    • Teensy USB devices

    • Denormalized Teensy USB Library

    • teensyStandardDevice

    • teensyMyDevice

    • teensyPassThruDevice

    Teensy Audio Shield 1

    • Initial Tests

    • teensyLooper1

    • First SD Card Looper

    • teensyLooper2

    • Initial LoopControl breadboard

    First rPi boot - Raspian (rPi 3b+)

    rPi Bare Metal Beginnings (rPi zero)

    • dwelch

      • devenv
      • console.pm
      • Initial rPi reboot circuit
      • SREC bootloader
      • Initial Komodo integration
      • rpiSerialMemory
      • rpiParallelMemory
    • Placid

      • XMODEM bootloader
      • Komodo Integration

    Initial Circle work

    • Windows Build
    • devenv
    • Ethernet TFTP bootloader
    • Komodo Integration
    • Circle Bootloader

    • FATFS read and write kernel
    • my Binary Serial Protocol
    • bootcode.bin probe
    • Build System and recoveryN.img

    Teensy Audio Shield 2

    • Circle I2S

    • myAudioDevice

    • rPi zero to teensy i2sQuadDevice

    • teensyLooper3

      • devolved to a test program for I2S


    • Sound Injector (my wm8731)

    • rpiLooper1

    • teensyControlBoard 2

    • Circle Bluetooth

      • initial testing

      • denormalized source

      • rewrite

      • HCI

      • L2CAP

      • SDP

      • RFCOMM

    Audio Injector Octo

    Initial Integration


    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...

    Read more »