Text to Speech Click on an ARMbasic Powered UChip, and Other ARMbasic Powered SBCs

Intro: Good day. My name is Tod. I am an aerospace and defense professional that is also a bit of a geek at heart.

Inspiration: Hailing from the era of dial-up BBS, 8-bit Microcontrollers, Kaypro/Commodore/Tandy/TI-994A personal computers, when Radio Shack stores were plentiful (the good ole days), one of my first hobby embedded projects was working with a MEK6800D2 Motorola Microprocessor Training Kit, which I had purchased while working as a co-op at the MSU EE labs (after completing my High School Electronics VoTech training in Southern Lower MI). That project involved my prototyping the Radio Shack SP0256 NARRATOR™ SPEECH PROCESSOR onto the MEK6800D2, wiring it up and programming the 6800 to get it to emit pseudo-speech (those who've worked with the SP0256 based HW know exactly what I am alluding to). It worked wonderfully and I progressed down the path of cutting my teeth in embedded microcontrollers and Assembly. After High School, life got in the way, Military, War, Spouses, Children, entering the civil sector, starting a career, etc. all added up to my shelving my hobby in favor of pursuing the endeavors of life in a Western culture (here in the US).

Skip forward 20 years, coming to the inevitable time where the kids are maturing to the point that the Bride and I are distractions, the mortgage/vehicles/college bills are slowly being paid down, earnings getting better with advancements, and my having enough spare time to the point where I could start to refocus on some selfish endeavors, I picked back up on the hobby electronics gig. Anyways, given my lineage and history, I sought out and found a dev environ that I quickly bonded with - ARMbasic - BASIC was my first love and this fit the bill of not only reacclimating myself to programming, but working with hardware that was wildly more powerful than what I had started with decades earlier, and thus the journey began.

This was circa 2006-2009. Then, for reasons well beyond our control, life changed (as it had for many during those years). Hobbies shelved - focus on a new career, recovering from financial struggles (was heavily vested in the real-estate domain and we took it in the shorts and the youngins were just getting to the point where College funding was an imperative). Basically, Life and First-World problems (we are really blessed, considering the challenges and toils that folks in other parts of the world struggle with on a daily basis) manifested themselves and ... the hobby got shelved. I picked back up briefly on it in 2011-2012-ish then was met with another career change - hobby shelved yet again.

Fast forward another decade and ... I am back and, Good Lord Willing, hopefully for the duration (until I take that proverbial dirt nap and start pushing daisies up from below). So, here we are. Wow - Arduino (what is that weird word?) had stormed the market. Makers?? What the heck are they?! ... :) My friends at Coridium Corp (proprietors of ARMbasic and ARM-based microcontroller dev boards) had remained steadfast and true. Now, instead of the LPC2xxx series of controllers, there is this new (to me) entity of ARM, and Cortex M0/M3/M4, and Arduino, and ... WOW! The culture has morphed quite a bit, and in many a great way. Peeps are collaborating remotely and, indeed, globally. Hardware is getting amazingly fast and powerful, and ARMbasic, having matured and steadfastly hardened with employment across many different families of silicon, is a thing of beauty for me and many others.

So, making a short story very long, I recently stumbled across the TTS click by MikroElectronika and felt a wash of nostalgia flow over me. Had one ordered in a manner of minutes, and was anxious over the next days until the unit arrived in hand. Hence begins the story...

Supplies

1 ea MikroElectronika Text To Speech Click,
contains the Epson S1V30120 - the module's TTS ASIC
1 ea ARMbasic Target, fulfilling the role of TTS Host
1 ea Uno Breakout Shield (or prototyping bread board, or ...)
1 ea speaker, or a set of speakers
suggest PC desktop powered speakers with 1/8" TRS plug thereon
1 lot Prototyping wares
wire, solder, flux, wick, soldering iron, headers, IC sockets and the like..
1 lot Embedded Dev Tools
DMM, Logic Probe, Logic Analyzer, Scope, etc. - for new TTS Host MCUs

Step 1: Hardware Interconnects

To replicate this using an ARMbasic target in a Uno form factor, or with an Itaca uChip, one would likely be best served by making use of a prototyping shield, as I have done in the above pictures (plain amazon link)

Some will see the twisted together wire-wrap wire and wonder why - common-mode noise rejection is the simple answer. Yeah, we aren't dealing with balanced signals here, but I figured it couldn't hurt(?) so I did that when I was doing the buildup of the board.

It is a pretty benign design. The prints are attached hereto, in the form of a graphic (AutoCAD 2D is what I am most used to - having worked with it for decades on my day job - I'm still cutting my KiCAD teeth and this was too simple an endeavor to justify the learning curve as a first project in KiCAD). Anyways, I chose to mount the uChip socket directly to the shield to enable a stand-alone use-case when using the uChip as a host. I added a JST for powering it via battery, should I desire to do so and, because I have a few extras, I castellated an Adafruit SWD Breakout to enable me to use my Segger J-Link EDU Debug Probe, should the need arise. It didn't, but I am keeping the SWD i'face thereon for use with future projects.

Castellated means, in this context, to file down the edges of the PCB so that the plated through holes were reduced to half-cylinders, enabling soldering onto a carrying PCB - in this case the shield breakout board. I elected to do this as the flat-pack fanout portions of the shield didn't quite align with the row spacing between the two header rows on the SWD BOB. Broke out a flat file and 5 minutes of filing and problem solved.

Step 2: Programming and Testing

Once the hardware is built up, there will need to be a full ring-out to validate that the wiring is good. Then, I always do a Power and Grounds check. This not only ensures that Power and Ground are where they are supposed to be, but that any of the other terminations that shouldn't have power/ground there don't. It is not a tedious task on a small project like this, but with larger systems-of-systems it, while indeed being a tedious step, is absolutely necessary to ensure no sub-assemblies or connected systems get taken out by a silly mistake that could and should have been caught. I usually get the bare minimum of goods attached so that power is generated on the board and then check every pin/termination for power and ground prior to plugging in sub-assemblies, chips, etc., making sure that power is of the proper level (considering non-5V-tolerant devices/IO, 1v8 and 3v3 requirements, etc.) and that ground is where it needs to be and only where it needs to be. I've witnessed a cascade of failures on an aircraft from people failing to do proper pre-connect checks. In one case, it took out over $100K of LRUs - not a fun time to be in charge of a project and to have it go sideways in an instant because someone short-circuited the process. Another thing I am guilty of is doing tedious 'vicinity checks' - making sure that contacts/terminations aren't shorted to adjacent contacts/terminations. This becomes critical if one is dealing with coaxial assemblies, multi-conductor/shielded harnesses, etc. Ok, I am off the soap box...

Once safety is assured, connect things, power it up and then get down to programming the TTS Host (ARMbasic Target MCU) just as one would with many embedded MCU targets. I recorded a video that depicts the programming and simple use of the TTS Click. You can view it here.

The ARMbasic source code can be downloaded from here - a forum post that has additional details. Coridium did a blog post on these efforts, which you can get to by clicking here.

Step 3: Modifying the Source for Other ARMbasic Targets, and Various Musings.

I'll not belabor you with the steps needed to modify the source code to work with other ARMbasic targets, other than to indicate that I drone on about doing so in an abundance of source code comments therein . Please take the time to crack open the tts.bas file and read about what changes are needed if you choose to port the code to another ARMbasic-powered controller.

Attached hereto are some images that I took during the dev cycle of getting this to work.

Lessons learned:

If you've a Logic Analyzer with unused inputs and have extra target IOs not being used for the work at hand, do not be afraid to use those IOs as debugging tools - sprinkling a wiggling of an IO at various points in the code can be a huge help in tracking down what is and isn't working as expected, to identify goofy timing issues (i.e. interrupts affecting bit-banged serial comms), and to overall gain a better understanding of your efforts as a whole.
Not all ARM controllers are the same. This is obvious. However, I got bit by doing the initial dev on a LPC1765 Coridium SuperPRO. In hindsight, what made this a bad choice is that this ARM core's implementation allowed non-word-aligned access to memory. When porting the C code over to ARMbasic, things went pretty smoothly until I tried to use it with a SAMD21 target - all hell broke loose and things were borked beyond belief due to unaligned access when filling buffers, manipulating flags, working with the ARMbasic version of structures/unions that I came up with, etc. It was a painful lesson. The take away here: If one wishes to have portable code, dev on the most restrictive candidate target, just to ensure that one is not faced with drama at the trailing end of the project, when one is likely most excited to employ the fruits of their efforts.. :)
Porting C code to ARMbasic is NOT impossible. This effort was largely one gigantic porting training evolution. If one takes the time to compare the original C sources with the ARMbasic code I crafted, one should be able to come away with some ideas how to implement things that might not be part of ARMbasic's core design (i.e. Structures).
Tackle things like this in manageable chunks. By default, I am one who like to see gratification on a regular basis. An endeavor such as these porting and dev efforts is not likely to be something to be able to accomplish in a single night. Set realistic goals and work towards same, trying not to get overwhelmed by 'the big picture'.
A Logic Analyzer was crucial in this effort. Yes, I have a lower-mid-range DS-Logic+ unit, but I can state emphatically that a cheap $12.50 24MHz Bandwidth LA from Amazonia would have more than sufficed. Couple that with Sigrok's PulseView (free) (does protocol decoding) and one will have a very robust system that should work in a vast multitude of scenarios such as what I endeavored to undertake with this project. Make sure to get a unit that has test clips, or order test clips separately, as they are hugely (how Trumpfeldian) beneficial.
A simple logic probe is a very useful tool as well. On the overview pic of the workspace you'll note an ancient Archer (Radio Shack) logic probe in the lower right corner of the image. I was genuinely surprised to find just how useful something like that is on a daily basis, even with a well equipped lab.

I may have linked to these earlier in this but I can't remember and am too lazy to look. Here is a blog post that has a video of the TTS module in action (Itaca uChip hosting it at that time), and the ARMbasic Forum post where one can download the ported ARMbasic source code.

Take care and have fun hacking away!

-MHz