reveal.js

novaneon.com

blinky

workflow

Here's an example workflow. This isn't a full workflow, I've left out the fact that you'll probably do multiple revisions of everything and the fact that eventually you'll have to do it all again in order to get a product through manufacturing, but that's for another talk. You'll probably begin with a basic design or concept, figure out what you want to make. Then some hardware and firmware prototyping. Here, rather than building something from scratch, save yourself some pain and use an already working development kit, or put it together using arduinos or raspberry pis. You can also prototype your firmware code using library code or code provided by component manufacturers. This code may or may not make it into your final product, that's up to you. Once you're happy with your prototype you can get into your proper schematics and printed circuit board designs. You'll have a head start here as your prototype hardware will serve as a useful reference.

audio interface

effects pedal

synth

analogue

mics/sensors

faders/pots/inputs/outputs

testing & diagnostics

One tool in the arsenal is the oscilloscope. Oscilloscopes allow you to directly probe your electronics circuit to inspect and analyse the actual signals. This is how you can figure out what's really happening in your circuit. Scopes are very expensive, so if you don't have the budget you can probably hire one, or you can get USB scopes which don't have a screen. They tend to be a lot cheaper, if not quite as good as the real thing. Other equipment might include audio signal analysers such as prism sound's dscope or audio precision gear. Those are industry standard, i.e. expensive, pieces of equipment which you'll likely just want to hire out if/when you need them.

schematics

integrated circuits (ICs)

printed circuit boards (PCBs)

testing

circuit simulation

circuitjs (falstad)

limitations

digital audio circuits

I²S

microcontrollers

assembly (ASM)


                        str     fp, [sp, #-4]!
                        add     fp, sp, #0
                        ldr     r3, .L3
                        ldr     r2, .L3+4
                        str     r2, [r3]
                        ldr     r3, .L3+8
                        mov     r2, #1
                        str     r2, [r3]
                        dsb
                        mov     r3, #1207959552
                        ldr     r2, .L3+12
                        ...

cross-compiling

programming & debugging

interrupts

c/c++ features

stack overflow

Weird things happen when you run out of memory which is entirely possible in an embedded system. Your program will probably crash, but it might not, instead it may just corrupt some other memory being used for something else, which may still appear valid and continue running. This may result in weird, unexpected behaviours. This is commonly referred to as undefined behaviour, which is something you should avoid wherever possible. On a PC running an OS, you're protected against this kind of thing, not just because you've got GB of memory to use, so the OS can just give you more memory if you need it; but also because there are safeguards in the memory, so the OS knows when you've run out of memory before anything can be corrupted. Your embedded device may not have such provisions, so might not be able to inform the program that there's a problem. In this diagram...

audio buffer

digital signal processing (DSP)

just do software?