element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet & Tria Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • About Us
    About the element14 Community
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Japan
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      •  Vietnam
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Bluetooth Unleashed Design Challenge
  • Challenges & Projects
  • Design Challenges
  • Bluetooth Unleashed Design Challenge
  • More
  • Cancel
Bluetooth Unleashed Design Challenge
Blog Smart Doorbell System – Part 8 – FM Sound Synthesizer and XDS110 Debugger and Tag-Connect Adaptor
  • Blog
  • Forum
  • Documents
  • Polls
  • Files
  • Events
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
  • Share
  • More
  • Cancel
Group Actions
  • Group RSS
  • More
  • Cancel
Engagement
  • Author Author: shabaz
  • Date Created: 11 Jul 2018 4:15 AM Date Created
  • Views 3704 views
  • Likes 9 likes
  • Comments 14 comments
  • bluetooth
  • cc2640r2
  • ti launchpad
  • bluetooth le
  • bluetooth_unleashed
  • bt_smart_doorbell
  • design_challenges
  • bluetooth 5.0
  • texas_instruments
  • cc2640r2f
  • bluetooth_le
Related
Recommended

Smart Doorbell System – Part 8 – FM Sound Synthesizer and XDS110 Debugger and Tag-Connect Adaptor

shabaz
shabaz
11 Jul 2018

For all the parts to this project, click here! Smart Doorbell System

 

Introduction

The Smart Doorbell System is an idea for a wireless and portable bell-push/chime system with hopefully better range and features than expected from existing systems!

image

 

This blog post covers a couple of things. It discusses how to implement sounds (music or sound effects) on a microcontroller, and secondly, for anyone wishing to build their own Texas Instruments ARM Cortex-M boards, it discusses how to use custom boards with TI’s USB Debugger and the Tag-Connect system, which is explained below.

 

Connecting the Debugger to Custom Boards

The Smart Doorbell System has a custom circuit board with a TI microcontroller with embedded Bluetooth LE functionality. It needs a programmer to get the microcontroller uploaded with firmware. Ordinarily this is achieved on a development board using a USB connection and on-board debugging circuitry, however the Smart Doorbell bell-push module is tiny and there is no on-board programmer, just some pads for a Tag-Connect cable to press on to.

image

 

An external programmer, called the Texas Instruments XDS110 will be used.

 

The XDS110 comes with various cables for popular connection schemes using dual-in-line headers, however I wished to use the Tag-Connect system which relies on no connector on the PCB, just some tiny pads that the springy prongs can press against. The Tag-Connect system is essentially a ribbon cable with a dual-in-line socket at one end, and the prongs at the other.

image

 

So, I needed an adaptor to convert from the XDS110 connector to dual-in-line header pins that the Tag-Connect cable can attach to.

 

There isn’t a lot to the design; as mentioned it just has a couple of connectors for interfacing the Tag-Connect cable to the XDS110 cable. The connector required to attach to the XDS110 is Samtec FTR-110-51-L-D-A.

image

 

I thought I’d try a fancy oval shape. There are two portions; the larger portion isn’t for connecting to the Tag-Connect cable, but is just a generic breakout board for non-standard wiring when (say) prototyping.

 

I figured it could be useful to annotate each pin on the underside:

image

 

It has submitted it to the PCB factory but I’m still waiting for the boards to arrive, so it is currently untested (EDIT - now tested! See below for a video of how to use the adaptor). However, the files are attached, in case anyone else wants to try such an adaptor too (for personal use, not for commercial sale). This should work for any Texas Instruments ARM Cortex-M device (not just the CC2640R2), connecting using the XDS110 debugger and a Tag-Connect cable. To see how this connects to the microcontroller, please see the schematic here: Smart Doorbell System – Part 5 – Final Bell Push Circuit and Antenna Design . One important thing to be aware of when using Tag-Connect, is that the springy pins are numbered like a dual-inline-package (DIP) IC with pins numbered sequentially along a row, but the 10-way ARM Cortex-M connector has pins numbered like a dual-in-line (DIL) header, i.e. odd numbering on one row and even numbering on the other.

 

The video here shows how to connect up the adaptor and XDS110.

You don't have permission to edit metadata of this video.
Edit media
x
image
Upload Preview
image

 

FM Music Synthesizer

The Smart Doorbell system needs sound generation capability, whether that is used for chimes/tones or for complete tunes. The hardware for this comprises of a digital to analog converter (DAC) that is connected to a serial I2S interface to the microcontroller. This interface allows the microcontroller to send a stream of 16-bit digital information that will get converted to sound.

 

Basic software to communicate over this interface was discussed in the earlier blog post. Now I needed to build a more useful sound effect or music synthesizer because just a sine wave alone is quite boring to listen to.

 

There are many things that can be done, and the approach I took was to implement the core of a music synthesizer. Music (or sound effects; the difference is not important in terms of the software that needs to be written to implement it) can be synthesized in different ways. One technique that was very popular in the 1980’s and 1990’s was FM synthesis. It was attractive to keyboard manufacturers such as Yamaha because it required very little RAM (which was expensive at that time), it could produce quite realistic instrument effects, and also it eliminated many of the disadvantages of analog synthesizers (analog synths required lots of set-up time, they were drifty in tone, and couldn’t easily be shrunk down to a single chip!). I got the chance to explore it briefly a while ago; some information is written here: Sound Synthesis and the Billion Dollar Paper

 

The technique uses the concept of operators that are assembled together to form a voice. An operator is an oscillator with two inputs; amplitude and frequency. A ‘voice’ is the particular combination or algorithm formed from multiple operators and input values that together create an instrument-like final sound. As an example, one of the most popular keyboards with FM synthesis was the Yamaha DX7. It had six operators and these could be assembled into one of 32 different combinations. By changing the input parameters to the combination, there were practically unlimited voice (instrument) possibilities.

 

For the Smart Doorbell, I implemented four operators, assembled into just one combination/algorithm. The algorithm can be easily changed if desired. More operators can be introduced if needed. They take up very little RAM, but they do consume processing power, so 4 seemed a good compromise for a proof-of-concept until the code can be optimised.

 

The diagram here shows what was implemented; this is not my diagram, it is from the original paper written by the inventor of FM Synthesis, John Chowning, called The Synthesis of Complex Audio Spectra by Means of Frequency Modulation. For this project I decided to replicate this diagram as closely as I could in the software.

image

The AND gate style of symbols are not actually AND gates, but represent an operator. There are four operators, called OPER_0..3 in the diagram. If there is a sine wave symbol then that operator is functioning to generate a sine wave output. There is also the possibility to set an operator to generate a different shape instead such as an envelope shape. The convention used is that the left side input represents an amplitude value, and the right side input is the desired frequency.

 

So, if the left side is set to the number 10, and the right side is set to the number 100, then the output of the operator will be a sine wave with frequency 100Hz and amplitude of 10. The triangle shape is used to sum outputs. In the diagram, the blue lines between the blocks are essentially like patches of wire but in software. It could also be built entirely in hardware if desired. By combining these blocks and setting the initial parameters (shown in blue text at the top of the diagram) then interesting sounds are formed. John Chowning suggested in his paper the particular values that would correspond to some typical musical instrument sounds such as the clarinet.

 

Turning the diagram into code was fairly straightforward, but is complicated by the fact that some accuracy is needed. The human ear is quite sensitive to errors. I made the mistake of using 16-bit arithmetic nearly everywhere in the code, but with hindsight I should have used 32-bits. Still, as a proof-of-concept it works.

 

This is the six-line code block I came up with that represents the diagram, and it is easy to follow how it maps to the diagram:

 

ug4=oper_run(OPER_0, instrument.amplitude, instrument.note_duration_reciprocal);
ug5=oper_run(OPER_1, instrument.deviation2, instrument.note_duration_reciprocal);
ug6=instrument.deviation1+ug5;
ug1=oper_run(OPER_2, ug6, instrument.modulation_freq);
ug2=instrument.carrier_freq+ug1;
ug3=oper_run(OPER_3, ug4, ug2);

 

The oper_run function runs the oscillator just for one iteration or sample, so this code needs to run in a loop for as long as the musical note needs to play for. So, at 16,000 samples per second, the code block also needs to be executed 16,000 times per second.

 

The operators are initially set up to the conditions that are written at the top of the block diagram. The actual musical note that is played is contained in the ‘carrier freq’ parameter shown there. Once the note has been played fully, then that parameter is updated and then the operators are run again repeatedly until the next note has completed too. In this way an entire tune can be played. If multiple notes need to be played simultaneously (i.e. polyphonic synthesizer) then the code block needs to be executed for those notes too, and the output is summed.

 

Incidentally different combinations of operators, forming different algorithms, are what are printed on the top of many music keyboard synths from the 1980/1990's. They are a reference to any musician who wishes to choose an algorithm and provide custom parameters to invent their own instrument effects.

image

 

The code was implemented in C and with no additional libraries required, so that it is as portable as possible. As mentioned it is merely proof-of-concept code written in a few evenings and needs to be modified to use 32-bit maths for better quality. It also needs some optimisation and tidying up. The envelope shaping takes up most of the resources, because the code models the Attack/Decay/Sustain/Release shape using some floating point calculations. These should be eliminated because this code runs 16,000 times a second. In all other places in the code, simpler calculations are used. Some things are pre-calculated and look-up tables are used. For example, no sine wave is computed and instead there is a look-up table containing 1000 samples of a complete sine wave.

 

Although the design challenge entry uses dev-boards and custom hardware, the synthesizer code is completely portable so anyone can try it, even on a PC or a Raspberry Pi. It is attached in a to this blog post, the file is called synth.tar. To use it, type the following:

tar xvf synth.tar
cd synth
make
./synth

 

The last command will execute it and will generate a standard WAV file called out.wav that can be played with (say) aplay on Linux, or Windows Media Player. For the Smart Doorbell system, the same code is used except that instead of saving the digital audio stream to a file, it is instead sent over the I2S interface to a DAC board.

 

Summary

The ten weeks or so for this design challenge are flying by. I hope this project can complete. I definitely took a risk thinking that I could get up-to-speed with a new microcontroller and develop circuits and code for it during weekends and evenings, but it is what it is and let the chips : ) fall where they may. I’m still optimistic the PCBs and code can be worked on over the next nine days!

 

Hopefully the circuit boards should arrive later this week.

Attachments:
https://community.element14.com/cfs-file/__key/communityserver-blogs-components-weblogfiles/00-00-00-01-94/synth.tar
1104.export-jtag-1.zip
  • Sign in to reply

Top Comments

  • fmilburn
    fmilburn over 7 years ago +3
    Excellent instructions, theory, and references. This is the kind of post that keeps me checking e14 first thing each morning.
  • shabaz
    shabaz over 7 years ago +3
    The XDS110 Debugger to Tag-Connect Adaptor has now been tested, it works. I made a silly error where the connector would have been nicer rotated by180 degrees, but nevertheless the wiring connections are…
  • aspork42
    aspork42 over 7 years ago +3
    Awesome job on the boards! I love the little adapter board you created
  • Fred27
    Fred27 over 6 years ago

    Yes - I think you need to temporarily disable Linux from booting to be able to debug the PRU on CCS. I saw that as just for writing / debugging a complicated PRU project in isolation.

     

    You're right that without Linux you're missing the point and might as well have used a microcontroller. I'm sure there are people using the power of a multi-core Sitara bare metal or with an RTOS, but I expect that's the minority.

     

    You have written some really useful PRU stuff in the past which I've read with interest. Thanks. I hope that the thought of that XDS110 and spare headers doesn't distract you and drag you off into the PRU world again! (Or maybe I am hoping that.) I'm trying to resist getting a new XDS110 toy I don't really need , but if I do then I'll let you know how I get on. I normally crumble after about a week.

     

    This TI guide seems useful too:

    PRU Training: Hands-on Labs - Texas Instruments Wiki

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • shabaz
    shabaz over 6 years ago in reply to Fred27

    Ahh, I see.. interesting.

    To be honest I think there may be alternate ways than discussed there, because the user is disabling Linux. That may meet their needs, but for many users it would be under-using the BBB. Unless I'm missing something (likely) - I need to read it in more depth. I'll see what I can find concerning PRU debugging, while leaving Linux running. In theory it should be possible to have on-board debugger on Linux, using memory sharing.

    One key advantage of PRU is that it can read/write memory block accessible to Linux too, so you get best of both worlds - simultaneous hard real time perfomance from the PRU, and Linux apps able to read/write the data and process it (e.g. filter it, share it via web server, etc) using developer-friendly existing apps or open source libraries.

    I've written quite a bit on PRU in the past, but I'm not sure it is worth reading now (or only reading with the understanding that methods have changed and the workflows there are dated), the main point there though is that the development and execution occurs with Linux running.: BBB - Working with the PRU-ICSS/PRUSSv2

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • Fred27
    Fred27 over 6 years ago in reply to shabaz

    These are two guides I found useful on PRU debugging. I can't comment much on them as I've not got it working yet. I suspect the XDS110 on the Launchpad is a cut down version.

     

    https://pvittali.bitbucket.io/bbb1/

    https://blog.parr.us/2014/11/14/beaglebone-black-debugging-via-ti-usb100v2-jtag-emulator/

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • Fred27
    Fred27 over 6 years ago in reply to Jan Cumps

    Basically, I used a 10-pin 0.05" idc connector at the Launchpad end and soldered the ribbon cable directly to some of the pads of the unpopulated 20-pin header at the BBB end. I tried connecting reset to both nSRST and nTRST but in both cases CCS recognises the debugger but not the target. It's essentially the same adapter as Shabaz created but used in the opposite direction. Unfortunately I've already given up and desoldered it.

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • Jan Cumps
    Jan Cumps over 6 years ago in reply to shabaz

    shabaz  wrote:

     

    Hi Fred,

    ..

     

    I think the XDS110 is worth getting, because it is used on so many TI chips (although I think as you say the Launchpad debugger should also work).

     

    ...

    I have a few LaunchPads with an XDS110 emulator, CCS and a BB(green). I could try this too. I'm interested in getting to know the PRU better. Fred27, where are you stuck in your trial?

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • More
    • Cancel
>
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2026 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube