Audio programming for hardware

From circuitbending to homebrew stompboxes & synths, keep the DIY spirit alive!

Moderators: Kent, luketeaford, Joe.

Post Reply
magicdust
Common Wiggler
Posts: 103
Joined: Wed Oct 19, 2016 9:22 am
Location: Internet

Audio programming for hardware

Post by magicdust » Sat Feb 20, 2021 7:47 pm

I want to create my own audio gadgets. Plugins, modules, desktop boxes, fx units, the lot!

I’ve made a couple of modules, all through hole stuff. Tiny bit of SMD.

I’m wondering how module designers code software for their modules and whether there is a common programming language for more sophisticated digital modules or whether they are based on preflashed chips or something else.

Please would someone enlighten me as to what coding skills are required to get programming for hardware and software applications?

I’m half hoping that I could learn C++ in Juce and be able to build out both vsts and 3u/5u modules.

These are probably quite silly statements, would love to hear your thoughts, experiences and advice.

Thanks

User avatar
MikeDB
Veteran Wiggler
Posts: 524
Joined: Fri Feb 08, 2019 8:28 am
Location: UK

Re: Audio programming for hardware

Post by MikeDB » Sat Feb 20, 2021 9:23 pm

There loads of audio languages if you google for them. Some people like them, I've never bothered. But when you get onto heavyweight stuff or coding vsts you'll still need C/C++.

One of the easiest ways to get going is to get a Teensy or Daisy Seed and program those first, before producing custom dedicated modules.

magicdust
Common Wiggler
Posts: 103
Joined: Wed Oct 19, 2016 9:22 am
Location: Internet

Re: Audio programming for hardware

Post by magicdust » Sat Feb 20, 2021 9:27 pm

MikeDB wrote:
Sat Feb 20, 2021 9:23 pm
There loads of audio languages if you google for them. Some people like them, I've never bothered. But when you get onto heavyweight stuff or coding vsts you'll still need C/C++.

One of the easiest ways to get going is to get a Teensy or Daisy Seed and program those first, before producing custom dedicated modules.
Would it not be best to go heavy and start with c++?

User avatar
emmaker
Ultra Wiggler
Posts: 769
Joined: Sat Mar 10, 2012 5:07 pm
Location: PDX

Re: Audio programming for hardware

Post by emmaker » Sat Feb 20, 2021 10:11 pm

Typically SW for things like plug ins or host based apps are written in C++ and embedded applications for uCs in modules code is in C. But you can use either language if you know what you're doing.

As far as development environments there's 3 that are main ones for embedded work. Arduino, Eclipse and a tool chain in the command line. For PC/MAC/Linux each has it's own development environment and libraries. I don't deal with those so you'll have to look those up.

Arduino has hardware and a SW development environment to support it. A number of other uCs and uC boards have support in the Arduino SW environment too. There's a lot of support libraries for different peripherals, peripheral chips and functionality (including audio DSP). Some are real crap but some are pretty good too. Arduino has limited debugging capabilities and most of the SW is downloaded over USB using a preprogrammed bootloader.

Most uC chip makers take Eclipse (some give their own names too it and don't use the name Eclipse) and make a specific version to support their chips. They will typically add functionality to support the peripherals so if yo want to use an I2C interface you spec which one, pins and how you want it configured. It will then generate init code and a driver for you. Again some of these are good and some are not. There is a debugger built into Eclipse that gives you access at C/C++ or the machine level that works decent enough. Downloading is usually done with a vendor specific JTAG or custom interface. The hardware to do the programming is usually cheap and if you go this route get the chips manufactures and not a clone. Some clones work well and some don't. Now days a lot of uCs have an USB interface with a boot loader that can be enabled too.

Lastly there is what is called a toolchain which is a set of tools that are usable from a command line. It will typically consist of a compiler, assembler and linker. Additionally you'll have to get make, gdb (debugger) and an editor. You'll have to pick the proper toolchain for you're uC and download and install it and the other tools. Programming the chips are done with applications that support the manufactures HW interface or USB. This is pretty low level and you will need to understand the HW and go looking for libraries yourself.

There's a lot of libraries out there on the internet for various things including audio DSP and MIDI. Again some good and some bad, you'll just have to go out and look to see what will work for you.

PC based programs/plugins and embedded uC stuff require different skill sets. Algorithms can be the same if done in a certain way. Look up "abstraction layers". You can use those to provide a common SW interface from your code to PC libraries or uC HW. For PC stuff you'll want to know about multi-media timers, audio/MIDI IO and audio/MIDI files. For uC stuff you'll have to work more at the hardware level and know how interrupts, timers, digital/analog IO pins and how SPI, I2C and I2S interfaces work. With embedded stuff timing issues can crop up depending on what you are doing and the processor you're using. These can be tricky to find and debug. Most the time for uC stuff I use a logic analyzer or oscilloscope with pins programmed to help me debug.

Don't know what your programming skills are but if you are starting at ground level I'd start on a PC/MAC/Linux machine and get my programming and language skills up and solid. After that I think I would recommend a Teensy with an audio interface and the Arduino development environment. There is a lot of support for the Teensy boards and there are a number of synth based modules using them. You can look at schematics and code for those and get some ideas on how to add synth based HW (digital/analog HW support, audio interfaces....). In general any 3.3V ARM chip will interface to the outside world with the same support HW. But always look at the data sheet for your chip and verify that.

Good luck.
Jay S

User avatar
EATyourGUITAR
has no life
Posts: 6087
Joined: Tue Aug 31, 2010 12:24 am
Location: Providence, RI, USA

Re: Audio programming for hardware

Post by EATyourGUITAR » Sun Feb 21, 2021 1:40 am

magicdust wrote:
Sat Feb 20, 2021 7:47 pm
I’m wondering how module designers code software for their modules and whether there is a common programming language for more sophisticated digital modules or whether they are based on preflashed chips or something else.
a little bit of both. something like the daisy seed comes flashed with a lot of the hard development process already done. if you are more serious about it then you would become an embedded developer so that you could actually develop a product like the daisy seed. almost everything is ARM based. this ranges from ARM M0 up to M3 or M4 running at 80MHz. there are even things like the H7 at 480MHz. some are single core some are multicore. some of the multicore processors have big little architechure. the standard that is used in ARM M4 is CMSIS and CMSIS-DSP. this works regardless who the manufacturer of the M4 silicon is.

without any real tutorial to get you started, here is a peek at the library and the language of embedded C++ for audio DSP.
https://arm-software.github.io/CMSIS_5/ ... dules.html

there is another platform that was used by many many reverb pedals and reverb modules.
http://www.spinsemi.com/products.html
magicdust wrote:
Sat Feb 20, 2021 7:47 pm
Please would someone enlighten me as to what coding skills are required to get programming for hardware and software applications?

I’m half hoping that I could learn C++ in Juce and be able to build out both vsts and 3u/5u modules.
there are wrappers but they are not good. you will need to completely rewrite the app when porting over from juce. here is a video tutorial for embedded C on ARM. some things will change when you use a different ARM vendor with a different part number and maybe different libraries but the concepts are mostly the same.



here is the board from the videos


you can get a slightly different dev board here


on a more professional level you will need to make your own PCB design and do your own assembly. this then requires you to wire up the programming and debugging interface to the board using a flasher debugger tool like this.

https://www.segger.com/products/debug-p ... s/j-trace/

you don't need it but if you have it you can do way more real time debugging, data streaming, data logging, profiling, and live coding. you also get real time trace so you can see what functions were called before a crash. without advanced tools like this, you are stuck using emulators to get this level of debugging in a simulation.

both kiel and IAR are free but it is size limited to 32KB. ST has CUBE-IDE that is free based on eclipse. segger has an IDE that you can use if you buy the debugger. I use a program from silicon labs because I use silicon labs. but I also use CUBE-IDE even with silicon labs. a lot of the segger features work in simplicity and cube so I don't really need to use segger embedded studio unless I am testing out real time trace or real time transfer.

https://www.segger.com/products/debug-p ... -transfer/

this technology allows me to connect juce and the eurorack module so that I can make a VST that controls the eurorack module through my own proprietary protocol running on top of RTT. all the stuff I build eventually gets ripped out when I finish development because you then need to implement the same features over USB without the probe in the middle.

https://www.silabs.com/developers/simplicity-studio
WWW.EATYOURGUITAR.COM <---- MY DIY STUFF

User avatar
plushterry
Common Wiggler
Posts: 240
Joined: Mon Oct 02, 2017 6:52 pm
Location: Cornwall

Re: Audio programming for hardware

Post by plushterry » Sun Feb 21, 2021 6:18 am

IMO start with an Arduino and the Arduino IDE. once you get the hang of that, move to a Teensy and platformIO running in VScode.

Teensy is a lot more powerful and has a great audio board add-on. You can also use Arduino libraries and shields.

The Arduino IDE is very basic but makes it really easy to get started, you'll soon be held back by it once you move on to projects that have multiple files. PlatformIO is a plugin for the VScode IDE which makes dealing with the teensy/Arduino much easier.

The sooner you can learn some C /C++ the better. They're pretty similar if you're learning (you can write C in a C++ environment and it will work). A lot of embedded stuff is programmed in C because it's fast. Arduino uses C++.

Just get a board and some shields and go with it. You'd be surprised at how quickly you can get something working with the Arduino environment. I managed to get a reasonable synth together within a few months of starting from scratch. I mean it was nothing special, but it mostly worked as intended and made wap wap noises.

User avatar
plushterry
Common Wiggler
Posts: 240
Joined: Mon Oct 02, 2017 6:52 pm
Location: Cornwall

Re: Audio programming for hardware

Post by plushterry » Sun Feb 21, 2021 6:21 am

The hardest part, for me at least, is making the step from Arduino to bare metal, the curve is steep at this point. Lots of things to go wrong and not as much useful literature aimed at beginners. It is out there though, you just have to do a lot of reading.

magicdust
Common Wiggler
Posts: 103
Joined: Wed Oct 19, 2016 9:22 am
Location: Internet

Re: Audio programming for hardware

Post by magicdust » Sun Feb 21, 2021 6:33 am

emmaker wrote:
Sat Feb 20, 2021 10:11 pm
Typically SW for things like plug ins or host based apps are written in C++ and embedded applications for uCs in modules code is in C. But you can use either language if you know what you're doing.
Hi Jay, thanks for sharing and taking the time to respond. When you say, if you know what you are doing do you mean there is a basic coding framework that would allow me to transfer skills from one programming language to another?
Thanks

User avatar
EATyourGUITAR
has no life
Posts: 6087
Joined: Tue Aug 31, 2010 12:24 am
Location: Providence, RI, USA

Re: Audio programming for hardware

Post by EATyourGUITAR » Sun Feb 21, 2021 10:41 am

magicdust wrote:
Sun Feb 21, 2021 6:33 am
emmaker wrote:
Sat Feb 20, 2021 10:11 pm
Typically SW for things like plug ins or host based apps are written in C++ and embedded applications for uCs in modules code is in C. But you can use either language if you know what you're doing.
Hi Jay, thanks for sharing and taking the time to respond. When you say, if you know what you are doing do you mean there is a basic coding framework that would allow me to transfer skills from one programming language to another?
Thanks
sorry for answering a question that was meant for someone else but anyway: all embedded programming that is designed for high performance will be written in ARM assembly, ARM embedded C, ARM embedded C++. there are some really rare programmers out there who use Java byte code, Forth, Zig. Arduino on ARM is basically an OS that works like an emulator for code that is architecture independent. PlatformIO has a bug that it will not install if you already have WSL and VSCODE installed on windows 10. I had to completely remove WSL, then VSCODE, then uninstall and reinstall ardiono IDE with the correct java path (3 hours of troubleshooting this on forums). then reinstall arduino IDE. Then reinstall VSCODE, then install platformIO. then run a maple driver fix. then I had to edit all the config files for platformIO and now I have no linux on my machine because I have this broken software for 4th grade robotics.

the only "framework" here is the CMSIS library. this is unavoidable. this is not really a framework but it is a driver and an API for SD card, USB, I2C, SPI, ADC, DAC, GPIO. if you use any kind of OS like RTOS then that is more like a framework or the arduino software stack. I advise people to not use an OS on the M3 or M4. you just don't want to lose real time control. you are not building HMI with a built in web browser and photo editing with wifi. none of that stuff from the OS will be of any benefit. it will only slow things down and use more RAM. you must instead learn how to program your own error handling and interrupt service routines in C or ASM. the C++ is not really used until you get into CMSIS-DSP, macros, RTOS, multi-core architechure.

you absolutely need this book. this is considered the one true book of the 1988 C standard.


at some point you will want to learn about C++ 2011 or C++ 2017. I have no idea what books are good.
here is something
WWW.EATYOURGUITAR.COM <---- MY DIY STUFF

Bachelard
Wiggling with Experience
Posts: 476
Joined: Sun Oct 09, 2016 8:37 am
Location: Canada
Contact:

Re: Audio programming for hardware

Post by Bachelard » Sun Feb 21, 2021 10:59 am

Monome stuff is also a direction you can go in. You can build a Norns Sheild for not a lot of money, and the programming language for it is dead easy from what i know. And it integrates really easily with Eurorack with a Crow module.

The other part of the knowledge is electronic circuits, which sounds like you already got a bit into. I've found circuit emulators great for that, things like Falstad, and eventually something like KICad if you want to design your own PCB. I was able to recreate some simple circuits on the Doepfer DIY page using Falstad.

Personally I've struggled for years to sink my teeth into programming. I tried to get into Max, I downloaded PureData, tried to get through "for Dummies" books, and...I'm just not a coder. My brain is wired to play instruments and "programming" modular with my hands and with cables. But I might start over again by learning Arduino, because it's so flexible and there are so many variations of hardware for it.

I also think it's helpful to have a specific thing/project in mind you want to make, IMO. That way you don't feel like you need to learn every single line fo code or function, and you build your skill set and vocabulary (in whatever language you use) through little manageable projects. I myself find it way too hard to just be like "I'm going to learn Max from the ground up" or "I'm going to learn every function in Reaper." I don't think I've ever managed to learn any piece of software or hardware that way.

User avatar
EATyourGUITAR
has no life
Posts: 6087
Joined: Tue Aug 31, 2010 12:24 am
Location: Providence, RI, USA

Re: Audio programming for hardware

Post by EATyourGUITAR » Sun Feb 21, 2021 12:42 pm

I did learn max from the ground up and I did it with small projects. those are not mutually exclusive. you actually can't learn a programming language by %100 reading and %0 writing code. if you are using arduino, you actually don't learn anything about debugging C++ because the way the debugger is setup. you may think that arduino is easier but it is actually harder because that is the worst way to learn C++ without learning arm assembler and C first. When you learn C you do it by looking at the assembler machine code that comes out of the C compiler. when you learn assembler you do it by looking at the C code that you already understand. when you use arduino you are assuming that the library does what you want but you have no knowledge of how or why and you are faced with a massive unreadable software stack for debugging arduino libraries that have bugs. arduino lets you build robots fast. but it does not go very far beyond that. large projects run slow and bugs NEVER get fixed unless some C++ master validates the libraries and your tool chain and your source code and your hardware.
WWW.EATYOURGUITAR.COM <---- MY DIY STUFF

User avatar
MikeDB
Veteran Wiggler
Posts: 524
Joined: Fri Feb 08, 2019 8:28 am
Location: UK

Re: Audio programming for hardware

Post by MikeDB » Sun Feb 21, 2021 2:57 pm

magicdust wrote:
Sat Feb 20, 2021 9:27 pm
MikeDB wrote:
Sat Feb 20, 2021 9:23 pm
There loads of audio languages if you google for them. Some people like them, I've never bothered. But when you get onto heavyweight stuff or coding vsts you'll still need C/C++.

One of the easiest ways to get going is to get a Teensy or Daisy Seed and program those first, before producing custom dedicated modules.
Would it not be best to go heavy and start with c++?
Definitely. They didn't have C++ when I began but it's a lot better than hacking FORTRAN or Assembler. Another thing I'd suggest is try the code first on a PC or Raspberry Pi. Even write some VSTs. Always best to get the algorithm right before optimising it to run on a MCU.

User avatar
bgreeves
Common Wiggler
Posts: 112
Joined: Fri May 26, 2017 2:33 pm
Location: Illinois, USA
Contact:

Re: Audio programming for hardware

Post by bgreeves » Sun Feb 21, 2021 3:23 pm

Just to add another option into the mix: consider developing plugins for VCVRack. The programming environment is C++ and there are some handy tutorials on the VCVRack website, and tons of examples in the form of open source plugins and the Rack source code itself.

The Mutable Instruments modules are coded in C++ as well, there's loads that you can learn from there.

I will warn based on my experience that the rabbit hole of Digital Signal Processing is quite deep and can get quite academic at times. It helps to have studied Calculus and Differential Equations. I've found myself having to return to Khan Academy to help me try to wrap my head around certain topics.

I'll caution against starting on Arduino or microcontrollers, unless you have solid experience with C/C++ and feel confident in your ability to optimize code for 8-bit processors. Those micros have very limited computing power and DSP is very compute-demanding.

I'll also second that Max/MSP is a good startup environment, but only if you already have it or are willing to buy it for a bit.

magicdust
Common Wiggler
Posts: 103
Joined: Wed Oct 19, 2016 9:22 am
Location: Internet

Re: Audio programming for hardware

Post by magicdust » Sun Feb 21, 2021 4:59 pm

MikeDB wrote:
Sat Feb 20, 2021 9:23 pm
Definitely. They didn't have C++ when I began but it's a lot better than hacking FORTRAN or Assembler. Another thing I'd suggest is try the code first on a PC or Raspberry Pi. Even write some VSTs. Always best to get the algorithm right before optimising it to run on a MCU.
I’m glad to hear that. I’ll probably start coding c++ with the express intention of creating an effects unit of some sort and see how far I can get without completely melting. Thanks for your input. Will start on a pc.

magicdust
Common Wiggler
Posts: 103
Joined: Wed Oct 19, 2016 9:22 am
Location: Internet

Re: Audio programming for hardware

Post by magicdust » Sun Feb 21, 2021 5:02 pm

EATyourGUITAR wrote:
Sun Feb 21, 2021 10:41 am

you absolutely need this book. this is considered the one true book of the 1988 C standard.


at some point you will want to learn about C++ 2011 or C++ 2017. I have no idea what books are good.
here is something
I’ll buy the c book for reference. Thanks for your input. Some of the stuff you are saying is above my level of understanding at the moment but I’m sure it will be a useful reference once I have some understanding of how the various processes interact with each other.

magicdust
Common Wiggler
Posts: 103
Joined: Wed Oct 19, 2016 9:22 am
Location: Internet

Re: Audio programming for hardware

Post by magicdust » Sun Feb 21, 2021 5:05 pm

Bachelard wrote:
Sun Feb 21, 2021 10:59 am
The other part of the knowledge is electronic circuits, which sounds like you already got a bit into. I've found circuit emulators great for that, things like Falstad, and eventually something like KICad if you want to design your own PCB. I was able to recreate some simple circuits on the Doepfer DIY page using Falstad.

I also think it's helpful to have a specific thing/project in mind you want to make, IMO. That way you don't feel like you need to learn every single line fo code or function, and you build your skill set and vocabulary (in whatever language you use) through little manageable projects. I myself find it way too hard to just be like "I'm going to learn Max from the ground up" or "I'm going to learn every function in Reaper." I don't think I've ever managed to learn any piece of software or hardware that way.
Falstad looks interesting and I’ll certainly be delving into pcb maufacture at some point in the near future. I totally agree with your approach, Go in with a required outcome and attack it. Only learn what is required to get the job done. Once complete change the objective. Learn piece by piece.

User avatar
cackland
Super Deluxe Wiggler
Posts: 2345
Joined: Thu Dec 28, 2017 5:42 pm
Location: Los Angeles, California

Re: Audio programming for hardware

Post by cackland » Sun Feb 21, 2021 5:06 pm

My 2 cents.... skip the Arduino environment all together. The abstraction doesn't lend a hand to those who really want to get into low level embedded programming, it only muddy's the waters. Datasheets are your friend here, you'll learn a lot from really understanding them.

But before anything, learn the fundamentals of C. You can branch off into the what C++ offers after.

magicdust
Common Wiggler
Posts: 103
Joined: Wed Oct 19, 2016 9:22 am
Location: Internet

Re: Audio programming for hardware

Post by magicdust » Sun Feb 21, 2021 5:17 pm

cackland wrote:
Sun Feb 21, 2021 5:06 pm
My 2 cents.... skip the Arduino environment all together. The abstraction doesn't lend a hand to those who really want to get into low level embedded programming, it only muddy's the waters. Datasheets are your friend here, you'll learn a lot from really understanding them.

But before anything, learn the fundamentals of C. You can branch off into the what C++ offers after.
Thanks for your input. It seems more and more that this is the approach I should take. C offering the foundations of c++ and being the language for most audio hardware applications. I think I’d maybe be starting on the wrong foot with arduino or teensy.

Thanks again.

User avatar
emmaker
Ultra Wiggler
Posts: 769
Joined: Sat Mar 10, 2012 5:07 pm
Location: PDX

Re: Audio programming for hardware

Post by emmaker » Sun Feb 21, 2021 5:23 pm

magicdust wrote:
Sun Feb 21, 2021 6:33 am
emmaker wrote:
Sat Feb 20, 2021 10:11 pm
Typically SW for things like plug ins or host based apps are written in C++ and embedded applications for uCs in modules code is in C. But you can use either language if you know what you're doing.
Hi Jay, thanks for sharing and taking the time to respond. When you say, if you know what you are doing do you mean there is a basic coding framework that would allow me to transfer skills from one programming language to another?
Thanks
Sure. But let me start out by saying some things.

For stuff I do for fun I will code in C as much as possible and avoid assembly code if I can. Also I'm not going to cheap the processor out. If I get what I need done with a $5 processor but it's going to take me 2 months of hard work to get it done or I can use a $20 processor (more RAM, FLASH and faster) and it will take 1 month of easy work I'll go for for the $20 processor. I'm not at work trying to cheap things out and save a company money over a million units.

First embedded programming exists for quite a broad range of systems from chips with 256 bytes of RAM with no OS to full blown Intel Xeons with gigi-bytes of RAM running Linux or some RTOS (Real Time OS). So different tools could/may be used for the systems. I will be talking about using uCs without an OS (well maybe a RTOS).

Second is I'm not a fan for C++ in an embedded environment. It's good for GUI and database applications in my opinion. My bias' may be dated because when I tried to use it it was the early '90s and the compilers and libraries are a lot better now. There use to be a lot of bloat in the libraries and the code generation wasn't that good. Embedded C++ seems to have simplified things from what I've read which is good. But C works for me and I don't see any point for me to get into C++, especially since I'm retired.

OK, onto the answers.

First off even if you do work with in C++ you can still integrate and use C code in C++ applications.

Next is algorithms are logic based and math is math. If you know C and C++ you can write the code so it will work in both.

Objects
To me one of the most powerful things from C++ is that it is object based. Using objects is one of the most powerful tools out there even for embedded systems. You'll go need C++ for that and that is not true. You can implement objects in C, it just takes a little more work because C++ does things for you. If you take a simplified look at C++ and it's objects it basically takes an object, creates a structure for it with the objects info (in its constructor a this structure) and data and then generates code to use that structure. So in C you can create your own structure for an object, constructor/destructor and then write you code/class to use a pointer to that structure. An example might be a chip has 6 serial ports in it. Typically all the serial port registers and the bits in them are the same just at different offsets in the memory space. So instead of writing code for each with the different addresses you can write the code once using a structure which contains the serial port base address and other data items.

Abstraction
I've done embedded projects where a significant portion of the code was written and debugged on Windows/Linux before it was put into a uC. It's a lot easier if you can do it that way with better tools and not having to program and reboot chips. A number of times these were more algorithm or infrastructure based verses HW based but even if they are HW based a lot of time you can do the base work on a host. There are a couple of things that are useful here.

First is black box testing. In a lot of cases you can write code on a host especially algorithms and infrastructure and get them to compile and debugged. Next you'd write an application that provides input for the routine or class and calls it. Then you either have the software look or you look yourself to see if the data results are valid.

Second is abstraction. Here you take a portion of your system and make an abstraction layer for it to isolate components, usually it's at the interface level. For example if you want to run an audio algorithm on a host and embedded uC. There would be 2 instances of the abstraction layer code. Here you'd create an abstraction layer where the top level interface would be yours and talk to your application which we'll say is an audio application. For the host the bottom end would be doing either audio file IO or IO with an audio interface. Then the second instance for a uC would have a bottom end that talks to the I2S audio interface with an audio ADC and DAC. Another area this is beneficial is when you're doing host cross platform development. You could have abstraction layers with the bottom ends for Windows/MAC/Linux and if you're going to do that you might look into Qt for a GUI. Yes an abstraction layer may make your code less efficient so it maybe something you look at removing at some point. That's your call.

Bottom line is there are a number of ways to do things and in general there is no one perfect way of doing an embedded project. There are a number of solutions that are as good as each others, some not so good that work and others that are just as bad. Another aspect is there are a number of opinions on how to do this. So just take everything with a grain of salt, educate yourself and come up with what works for you.

Happy coding.
Jay S.

User avatar
EATyourGUITAR
has no life
Posts: 6087
Joined: Tue Aug 31, 2010 12:24 am
Location: Providence, RI, USA

Re: Audio programming for hardware

Post by EATyourGUITAR » Sun Feb 21, 2021 10:01 pm

Hardware abstraction layer HAL is part of CMSIS. Everything is already done. All you need to do is read the docs for your HAL which is usually just a special version of CMSIS provided by the manufacturer of the ARM processor that you purchased. If you don't want to start from scratch you will be at the mercy of the creator of the HAL library. CMSIS does not require C++ but CMSIS-DSP and RTOS definitely require C++.

Building a HAL is sometimes more difficult than using one that exists. But sometimes it goes the other way for simple projects with an optional complicated HAL library that you may not want to waste time digging through the docs. When you build your own, your time is spent reading the specific ARM M4 datasheet and reference manual for your part as well as the docs for your C compiler and the ARM v7m instruction set.

Emmaker has a very good point that you can build applications on windows or linux that are written in C and execute in windows or linux. I think he was referring to arm emulation but maybe he was talking about universal C code that compiles to x86 or 64bit x86? That is actually a great idea because you still learn C even if you are not doing anything with arm. Super beginner level it doesn't matter what instruction set you use as long as you practice basic examples with pointers in C.
WWW.EATYOURGUITAR.COM <---- MY DIY STUFF

mouren
Learning to Wiggle
Posts: 27
Joined: Fri Mar 15, 2019 9:26 pm

Re: Audio programming for hardware

Post by mouren » Sun Feb 21, 2021 10:19 pm

I learned and got familiar with C before going to C++. I feel ya on feeling that C is faster than C++. Don't think that's true anymore though. Modern C++, as in C++ 11 and on, especially C++17 and 20, there are many awesome features, like Lambda or custom allocators or allocation in place, etc.

I would only recommend C if the learner has enough programming sense to be meticulous or have the patience. You can do OOP with void pointers and etc, but you won't have the Parser to protect you.

In the end, you have to ask yourself, do you want to make interesting effects or learn how to program this chipset? If you want absolute brutal speed, you will have to learn some assembly.

Interestingly enough, I watched this talk a while back. Pretty fascinating. It touches up on C/C++ for embedded systems.



emmaker wrote:
Sun Feb 21, 2021 5:23 pm
magicdust wrote:
Sun Feb 21, 2021 6:33 am
emmaker wrote:
Sat Feb 20, 2021 10:11 pm
Typically SW for things like plug ins or host based apps are written in C++ and embedded applications for uCs in modules code is in C. But you can use either language if you know what you're doing.
Hi Jay, thanks for sharing and taking the time to respond. When you say, if you know what you are doing do you mean there is a basic coding framework that would allow me to transfer skills from one programming language to another?
Thanks
Sure. But let me start out by saying some things.

For stuff I do for fun I will code in C as much as possible and avoid assembly code if I can. Also I'm not going to cheap the processor out. If I get what I need done with a $5 processor but it's going to take me 2 months of hard work to get it done or I can use a $20 processor (more RAM, FLASH and faster) and it will take 1 month of easy work I'll go for for the $20 processor. I'm not at work trying to cheap things out and save a company money over a million units.

First embedded programming exists for quite a broad range of systems from chips with 256 bytes of RAM with no OS to full blown Intel Xeons with gigi-bytes of RAM running Linux or some RTOS (Real Time OS). So different tools could/may be used for the systems. I will be talking about using uCs without an OS (well maybe a RTOS).

Second is I'm not a fan for C++ in an embedded environment. It's good for GUI and database applications in my opinion. My bias' may be dated because when I tried to use it it was the early '90s and the compilers and libraries are a lot better now. There use to be a lot of bloat in the libraries and the code generation wasn't that good. Embedded C++ seems to have simplified things from what I've read which is good. But C works for me and I don't see any point for me to get into C++, especially since I'm retired.

OK, onto the answers.

First off even if you do work with in C++ you can still integrate and use C code in C++ applications.

Next is algorithms are logic based and math is math. If you know C and C++ you can write the code so it will work in both.

Objects
To me one of the most powerful things from C++ is that it is object based. Using objects is one of the most powerful tools out there even for embedded systems. You'll go need C++ for that and that is not true. You can implement objects in C, it just takes a little more work because C++ does things for you. If you take a simplified look at C++ and it's objects it basically takes an object, creates a structure for it with the objects info (in its constructor a this structure) and data and then generates code to use that structure. So in C you can create your own structure for an object, constructor/destructor and then write you code/class to use a pointer to that structure. An example might be a chip has 6 serial ports in it. Typically all the serial port registers and the bits in them are the same just at different offsets in the memory space. So instead of writing code for each with the different addresses you can write the code once using a structure which contains the serial port base address and other data items.

Abstraction
I've done embedded projects where a significant portion of the code was written and debugged on Windows/Linux before it was put into a uC. It's a lot easier if you can do it that way with better tools and not having to program and reboot chips. A number of times these were more algorithm or infrastructure based verses HW based but even if they are HW based a lot of time you can do the base work on a host. There are a couple of things that are useful here.

First is black box testing. In a lot of cases you can write code on a host especially algorithms and infrastructure and get them to compile and debugged. Next you'd write an application that provides input for the routine or class and calls it. Then you either have the software look or you look yourself to see if the data results are valid.

Second is abstraction. Here you take a portion of your system and make an abstraction layer for it to isolate components, usually it's at the interface level. For example if you want to run an audio algorithm on a host and embedded uC. There would be 2 instances of the abstraction layer code. Here you'd create an abstraction layer where the top level interface would be yours and talk to your application which we'll say is an audio application. For the host the bottom end would be doing either audio file IO or IO with an audio interface. Then the second instance for a uC would have a bottom end that talks to the I2S audio interface with an audio ADC and DAC. Another area this is beneficial is when you're doing host cross platform development. You could have abstraction layers with the bottom ends for Windows/MAC/Linux and if you're going to do that you might look into Qt for a GUI. Yes an abstraction layer may make your code less efficient so it maybe something you look at removing at some point. That's your call.

Bottom line is there are a number of ways to do things and in general there is no one perfect way of doing an embedded project. There are a number of solutions that are as good as each others, some not so good that work and others that are just as bad. Another aspect is there are a number of opinions on how to do this. So just take everything with a grain of salt, educate yourself and come up with what works for you.

Happy coding.
Jay S.

User avatar
emmaker
Ultra Wiggler
Posts: 769
Joined: Sat Mar 10, 2012 5:07 pm
Location: PDX

Re: Audio programming for hardware

Post by emmaker » Sun Feb 21, 2021 11:22 pm

EATyourGUITAR wrote:
Sun Feb 21, 2021 10:01 pm
Emmaker has a very good point that you can build applications on windows or linux that are written in C and execute in windows or linux. I think he was referring to arm emulation but maybe he was talking about universal C code that compiles to x86 or 64bit x86? That is actually a great idea because you still learn C even if you are not doing anything with arm. Super beginner level it doesn't matter what instruction set you use as long as you practice basic examples with pointers in C.
EATYourGUITAR,

I was thinking of doing the code in native 'x86'. Don't know if you can really call it x86 any more since Pentiums have a very extended instruction set and some have micro-code.

At this point you're just interested in getting the code to compile and debug working in an environment that is easy to work in. You can do black box testing and get pretty far along in your development then move to the target to finalize and test.

I would still code it as much as possible for the target though. This would include using stdint.h and explicitly define data/variable size to see if there might be word size issues. Another thing I've found is that using 'register' for object pointers and some internal loop data can speed things up. Sometimes you can get a significant performance doing this, sometimes not. To know how many registers and types (data, pointer) are available you'll have to review the specs for the compiler you're using.

Yes pointers are a very important part of programming in C. Knowing how to use them is mandatory for efficient and good C code.

Jay S.

Post Reply

Return to “Music Tech DIY”