If you were intent on designing effects that used a microcontroller for managing modulation and maybe signal flow of an otherwise analog signal path, what would be your choice of what's currently out there, and why? For example, current consumption? #A/D inputs? PWM outputs? RAM? clock speed? convenience of instruction set?
It's time for me to start catching up, but I need to know where to allocate time and energy.
I just received an order of Arduino plus ADA plus peripheral tidbis. I doubt I could ever tell you something of interest, but I can document my "progress" meticulously :)
I like PICs, but then that's what I grew up with. The user base, base of already-developed software for free, number of different flavors of chips, I/Os and so on is huge. The same could be said for AVRs. And a few companies are trying to catch up, notably TI. You're going to find much of what you want for starters/help in either PIC or AVR.
I recommend not getting too hung up on either one unless you're going to learn to program in the native assembler. I recommend picking a basic uC architecture based on what high level language is available and easiest for you to learn, not what the bits in register A do. The vast bulk of your time in programming anything from a standing start is (1) picking a language to use, (2) picking a tool set ("development environment" to make that into working code, (3) learning and using the language and (4) getting over the hurdles of actually getting final code into the chip to try out.
I have been through so many computer languages that I've become essentially language-agnosttic. I started with Fortran, back with the dinosaurs, then learned about eight varieties of assembler, BASIC, PASCAL, COBOL (which is not something to admit in mixed company), APL (which is methematically fascinating, but unreadable even to skilled APL programmers), FORTH, C, C+, and smatterings of other more esoteric or downright strange languages. What I fall back on is writing down what I want to happen in computer language pseudocode, making things like IF-THEN-ELSE, CASE, WHEN, comparisons, and logical tests, and then transcoding that pseudocode into the language of the month. With good compilers available, I mostly get out the old BASIC compiler, but it works almost as well to memorize the framework code for the pseudocode in the assembly language of the processor you're working on. I'm pretty conversant with the PIC assembly language, largely because the processor is so very simple, with very few instructions to learn.
In my view, picking what you can learn to program to get your thoughts down for what to do is more important than the actual hardware in the vast majority of cases.
When it comes down to actually picking a processor, pick one that's likely to have the programming space and enough I/O pins and built-in periperals to do what you want. Since you don't (yet- ) know what you want, select PIC or AVR.
Forgot to mention: there are some all-in-one starter setups. One of these is the BASIC Stamp, another is the Arduino. The BASIC Stamp is programmed in ... surprise! BASIC. The Arduino is programmed in what amounts to a variant of C. Both are very cheap - in the US$5-20 range. Both can do very useful work. Both are bigger than you'd probably like to put in a pedal all by itself. They're great starters, but not a destination for stuff to put in a pedal.
Since RG mentioned TI already, I'll plug my employer a little more. :)
TI has starter kits too - they call them LaunchPads: http://www.ti.com/lsds/ti/tools-software/launchpads/overview/overview.page.
I personally know little about them, but they are as low as US$10 and TI also provides free software to program them which from what I am told is very good. Some of the software tools are developed in the Toronto office where I work (not my team).
Have to second R.G.'s weak endorsement.
If you are standing there going "duhhh??", get a BASIC Stamp (https://www.parallax.com/catalog/microcontrollers/basic-stamp) starter pack. Manual (https://www.parallax.com/downloads/basic-stamp-manual)
It does what a computer should do. The board pins are klutz-size. The language is not much BASIC, but it isn't some strange concoction. (Control code is a lot of GET/PUT, rinse, repeat; not elegant structure.) The download process is simple. Made for non-geeks.
Yes, it is large and costly relative to a fuzzbox. If you have gone crazy, you run out of output pins. There are extender boards, more cost.
I got one for a "simple" problem, which could have been a buffered '555, but I felt frisky. I had the core logic working in a few minutes, working a fat relay a few minutes later.
Having "wet your feet" with "simple scales", you will be in a better position to pick and use something else for a next project.
Depends on what you want to do and what is your level of technical expertise.
I would start with Arduino. Mostly because of the huge library, community projects and open source stuff, so you don't have to reinvent the wheel. They come in several shapes and sizes and someone probably made 90% of what you need.
If you need more horsepower, NXP has an ARM based Arduino equivalent, but more "professional", or "enterprisey" if you will, the Freedom Boards. Its IDE is a pain to set up, but works very well. As with Arduino, it has a big library of components with high level of abstraction.
If you need even more power, TI has the Beagle boards. They run Linux and can do DSP. There's even a digital pedal based on it, the Mod Device Duo. Cool stuff.
TI's Launchpads are nice. IIRC the uC used, MSP430, is super low power.
I have 15+ years of experience as an embedded systems engineer, but as a hobbyist, I try to keep it as simple as possible. Arduino's libraries are so amateur and ineficient that it hurts, but they work well enough and I don't want to spend my free time debugging peripheral registers or whatever. I'm using one to control a switching matrix for 3 effects in one enclosure. Took less than half an hour to write the code.
> Arduino. Mostly because of the huge library ... ...
I don't know Mark's level of programming. But I suspect he dabbled in the 1970s and merely picked at it since. I suspect he'd me most comfortable in a less obscure FORTRAN, like BASIC. (He may barely know we do not number our punch-cards today.)
Libraries tell me a programming system has grown too large for my britches. I've even written libraries: when I started in Pascal and realized the stock system did not include MS BASIC's useful string functions, I wrote Pascal to do the same thing with BASIC-like calls. When I ported a large (for me) string parser (HTML processor) from Quick BASIC to Perl to PHP, I ended-up calling some outside libraries where appropriate. But for diddling a few relays or PWM pins, he should not need libraries. You get lost in massive collections of things that almost do what you need done.
Three years ago, when I faced this dilemma, from everything I read it was 50-50 PIC vs AVR. Buying the startup gear you need is not a lot of money, but it doesn't make sense to invest in both. I chose AVR. I had some coding experience from school (basic, fortran and c) and some more from work (visualBasic mostly), which helped the learning curve. Lots of forums and source code out there.
Didn't take long for me to drive LEDs, read switches, program my own optofet muted relay bypass, and eventually read analog voltage input and output a filter pwm. Learned how to save settings/values to eprom memory and even drive an LCD display. Found code to digitally interface to I/O expanders, and also LFO synthesis, but have only experimented a bit with this.
I've had no regrets with Atmel AVRs.
Programming, my personal vision of hell. There aren't enough pixels on enough monitors to express how much I hate programming... (any guesses where I stole borrowed that from?). Anyway...
I happened to be searching for electronic apps and saw that there is a PICmicro database app for all the PIC and dsPIC microcontrollers made by Microchip. Stuff like pinout diagrams, etc. Don't even know if this is relevant but maybe it'll be of some use...
I've done my time in the trenches (ok, not really. I never had to assemble code by hand or enter it into a machine using toggle switches, etc.), writing assembly code, worrying about which registers were used by which resources, and carefully keeping track of clock cycles. It gets to be pretty frightening once you eventually start thinking through ordinary tasks like making coffee in terms of assembly code. Nowadays, I just buy Arduinos. So much simpler. I like the Arduino Pro Trinket. Simple and small, yet very versatile. I've used it in a pedal.
I suppose I should clarify (although the discussion generated so far has been helpful and interesting). Back in May, I struck a handshake deal over dinner with Joel Korte of Chase Bliss and Steve Bragg of Empress to try and codesign something. For my part, I think that would require more on my end than simply saying "You guys should make something that does this" (insert vague sonic objectives <here>). Both Joel and Steve frequently use microcontrollers to manipulate an otherwise analog signal path. For things like the Empress Echo System, I can't imagine anything on an 8-pin chip would do the trick, but for many other kinds of effects, something in the 14-18 pin range would probably be sufficient. Perhaps some of the Molten Voltage or Pedalsync modules would do what I want, but I gather I need to start from scratch.
The TI modules that Gord directed us to ARE cheap and very powerful...but probably too much. I have the requisite Raspberry Pi and Arduino Uno at home, recently supplemented by a BBC micro:bit. R.G. had generously sent me a PIC programmer and a handful of 628 PIC chips a while back. I shamefuly let them gather dust and finally turned them over to forum member Alain Parent, who works in I.T. two floors below me (for now; I retire in 10 working days) and knows more about such matters. But I did pick up a Velleman PIC programming board recently, and wanted to get back into it. The goal is to have a small dedicated microcontroller of some kind embedded in a pedal, doing smart things with an analog signal (assuming I can come up with smart things). Maybe I will ultimately defer to something like the Molten Voltage/Pedalsync products if they already do what I want/need. But I think I should know more about the entrails of such things.
When I asked Joel at dinner what his favourite MCU was he mentioned one, whose name/number went by me too quickly to recall, but the virtues he touted had to do with the PWM outputs. For him, that provided a convenient way of manipulating the LED in an optoisolator. That's the sort of info I'm trying to squeeze out of people here: things you know about certain MCUs, be they PIC or other, that prompt you to think "Jeez, that would be a handy feature to have". It's not power I'm interested in, per se, but rather convenience.
Analog inputs and PWM outputs are really the essential convenient features. However, you may also find some built-in interfacing handy for talking to some other chips. I've used I2C to control a bicolor LED bargraph module, which was quite convenient. Being able to easily control some digipots would be nice too. Some of those use SPI.
I have always been a PIC guy. Most of my uC projects have been using different flavours of PICs, from the typical 16f86 using assembler to dspic using C.
The good thing about PICs is that there is a product for almost every need, depending on the project, and there is a lot of information online.
On the other hand, you really need a deep understanding of the hardware architecture of the device you are using, and this can be very time consuming.
Lately, I have been embracing the Arduino platform. There are now cheap clones with a reasonable small footprint that can fit into pedals. My choice usually is the Arduino Nano for multiple reasons:
-Small footprint
-You don't need a programmer, just a usb cable
-Plenty of documentation and libraries ready to be used
-It has 8 analog inputs and 6 PWM outputs
-Reasonably priced for DIY projects. For a mass production design I might choose a different approach.
-It includes an EEPROM to store your configurations/presets
The Arduino Pro Mini is another good option, but you lose the usb.
Mat
Hi
I forgot to mention one thing that for me is essential. I want to use a platform I can debug easily, and if possible being able to simulate it. The reason is, I'm a bad programmer, and need a lot of trial/error.
Arduino does not have an included debugging function, but you can use the serial over usb to send data to your pc and do some debugging. But, you need to code the tracing of data yourself. And, I use Proteus for simulating circuits, and I have the arduino simulated there. This allows me to develop the software even when I don't have the hardware yet.
Mat
Thanks. I know this sort of content might better fit in the digital/DSP sub-forum, but more and more pedal-manufacturers are migrating in this general direction, so I think it is the sort of information that "regular" pedal-makers should probably start contemplating.
There will ALWAYS be a place for two-transistor fuzzes (and keep 'em coming, folks), but as the contents of the effectsdatabase grow ever larger, it becomes harder and harder for newer pedals to seem like they do anything "new" or yield greater convenience. Our ever-increasing expectations push pedals, both commercial and DIY, in that direction.
So this is information that should be planted in the back of all pedal-builders' minds. It might not germinate for a few years, but it warrants planting.
Actually, your description helps. Several things come to mind.
> PWM is indeed an easier way to deal with making analog do what digital wants. Until the recent generations of PICs, it would have been difficult to recommend PICs for beginners with this as a requirement, because they did not include a hardware PWM feature and AVR did. You had to bit-bang the PWM, and that requires a deep understanding of the internal hardware at the bit level. However, the recent generations of PICs include hardware PWM modules, which again even them up with AVR. In fact, the recent generations of PIC also include hardware Numerically Controlled Oscillators (NCOs) that remove the deep understanding needs for making something like an arbitrary waveform output, like an LFO.
> I hope I got across clearly: the actual chip is somewhat irrelevant; the big swinger is your needs in programming it. Like most people, for whom it's easier to change spouses than it is to change word processors, what you start with is what you will forever be most comfortable with.
>Finally, something you would likely say to someone else, some variation on this: Play to your strengths, practice to your weaknesses. My impression of your strengths is that you have a really good grasp of what kinds of things are musical, usable, and practical in a playing situation, and a feel for what kinds of circuits might get you there. If your co-conspirators regularly do uC stuff, they will run rings around you in coding - which is OK. They value and respect your strengths, and would enjoy collaborating with you on improving your weaknesses. You all get the best from one another and all get personal improvement out of it.
Thanks, bro. That means a lot, coming from you.
This has got me thinking, which is always a dangerous thing to do. So many effects these days are coming with expression-pedal inputs. Most oif us will think about such inputs in terms of a simple foot treadle to control how much "more" or "less" of something we want. Companies like Source Audio have introduced 2-parameter control with the Hot Hand, and EHX brought in their 8-step sequencer/programmer. But apart from those sorts of things, expression-pedal inputs remain highly under-explored. What sorts of new sounds could be produced and manipulated in interesting ways via external microcontrollers feeding that expression-pedal input? And what if we could alter what those external controllers do via their own expression pedal inputs? (e.g., change waveform type or reduce/increase sequence steps/smoothness with a foot treadle)
The universe of auxiliary control remains underexplored. I'm going to put on my pith helmet and backpack, take my digital machete, and see if I can cut a path through that jungle! :icon_biggrin:
(https://www.ehx.com/assets/jpg640h/8-step-program.jpg)
I like to think of these problems in the following terms:
"There are about 8 right ways to solve a given problem. Pick one of them."
I often find when I get in the loop of painful deliberation about the "best" way to do something it takes some of the joy out of it and adds very little value in the end.
There is enough example code and community built around PIC, AVR and TI that you can just PIC one and go with it. They all have the right stuff to solve the problems at hand :)
Well,
In software development people learn a few tricks, or a new language, and then go looking for something to do with it. This can be very frustrating as there is no objective.
What I always suggest is to look for a problem/project FIRST and THEN try to solve it with the tool you want to learn.
Example: My friend wanted 3 units of the same distortion in one enclosure. Clean bypass, clean with some dirt, rhythm and solo tones. One solution is an uC and a bunch of digital potentiometers for storing presets. Another is wiring three copies with the same circuit and using a uC to control the signal routing. We decided on the second approach. Easier for him to adjust on the fly and easier for me to program.
OTOH I wanted to do something with CMOS inverters, which I discovered a few months ago. I'm still looking for something non trivial to do with them...
Mikro has compilers for a bunch of different microprocessors in several different languages:
https://www.mikroe.com/products/#compilers-software
Just pick the one that you want to use and give it a try. Basic, Pascal, C? They have them all. They also have demo versions that can compile up to 2k, which is plenty for a lot of pedal projects.
One hint is that even if you know the language that you are going to use, I find that some knowledge of assembly, ports, registers and other basic stuff about the microprocessor is essential in getting the project to work.
regards, Jack
Hootchie mama!! Are you sure there's enough choice, there, Jack? :icon_lol:
We covered all the ports, handshaking, registers, rising/falling edges in class back in 1982 (as a research psychologist, I had to learn about real-time control of lab equipment and data acquisition). The clock speeds have changed significantly since then, but a lot of the basic stuff still holds, I gather.
Many thanks,
Mark
Quote from: potul on September 13, 2017, 08:44:16 AM
The good thing about PICs is that there is a product for almost every need, depending on the project, and there is a lot of information online.
On the other hand, you really need a deep understanding of the hardware architecture of the device you are using, and this can be very time consuming.
This and this (my underlining).
I'm a PIC guy too. If you have some experience writing code in just about any language, then I don't think it will take long to pick up enough C to get a PIC to do something interesting and/or useful via the free microchip xc compilers.
As potul said, the major time suck is reading the data sheet. As an example, this is the datasheet for a fairly new 8-pin PIC, which I have used to generate LFOs, etc.
http://ww1.microchip.com/downloads/en/DeviceDoc/40001737C.pdf
It is 397 pages long.
Of course, you won't have to read all of it, but you will have to read enough to work out how to make use of the very cool peripherals that take care of PWM, ADC, etc.
I think my mind got made up for me by happenstance. When I got home from work, I dug out the Velleman PIC programmer I bought last year and discovered there was a 16F627A PIC sitting in foam that came with the programmer. Seems to have enough in common with other MCUs that it's a reasonable place to start. No shortage of support for it out there either.
> Joel and Steve frequently use microcontrollers to manipulate
Then go with what they do. Even throw that decision in their lap. If say Joel is hep for the XYZ987, then he will show you how to wire and code, and will know right-off if a Hammer bright-idea doesn't quite suit the XYZ987 as good as a HAL9001.
As R.G. says, they are not partnering you for 40 years of bit-boffing experience, but your decades of listening and music-theorizing. At some point you *can* show them a breadboard smothered in jumper-cables, lengthy re-patching, and if it has the ZING factor they'll work the control interfacing.
A point that I used to think was important (maybe less today): User Interface. My Stamp project was one button and one LED (and a relay). You can "easily" interface a 40x2 text display and bang it like a teletype, but that was ho-hum 25 years ago. Still ample for some things, way behind-times for other things in this icon-mad world. There are small graphic displays but I could see wasting a lot of time making-nice. OTOH an rPi direct-connects TV and such for rich display with standard computer interface, but won't fit in a Hammond.
And there is a trend to off-load the whole GUI through boo-tooth to a cellphone. But this immediately begs iPhone+Android, and O/S drift 5 6 7 8..? revisions..... And security: punk in the crowd or the other band reprograms your gear?
Which leads back to a Stamp with prototype area. Any amount of analog patching/parameters can be set on-the-fly with a button or two. The rig covers a bench but consolidation is chimp-work compared to innovation. This type BASIC is nearly pseudo-code already, so any C or Python geek can easily extract the key actions and wrap it up pretty.
I think that's all sage advice. I think it behooves me to at least explore what is possible a bit, simply as a way of generating ideas I might not have thought of before.
One always needs to give serendipity a bit of a headstart, right?
An interesting thing about the Mikroe compilers is that they generate assembly code that is saved in a file and then compiled into the hex for use in programming.
Once you get to looking at the asm code, one computer language is about the same as the others, so use what you are comfortable with. There is not going to be any difference between Basic or C or Pascal once the final code is generated.
regards, Jack
I have a Velleman K8048 kit that programs 8, 14, 18 and 28 pin PIC controllers. It needs a Pentium PC with Windows from 95 to XP, a CDROM and a serial RS232 port that cannot be a USB to RS232 cable. This looks like it is going to be a pain - I have a Dell Inspiron laptop connected to the internet but it has no RS232 port. I have an older XP tower that is not currently connected to the internet but it might have an RS232 port. I am not too sure how to get the programming done here. This looks like it is going to be a pain to use. The RS232 cable needs pins 3, 4, 5, 7, 8 and 9. The 15 VDC adapter is something I can get.
Once I get the hardware sorted out, I can download code to program stuff. PIC code seems a bit off-putting - I can see what they are doing but it all seems so awkward. So I have a programmer and access to devices but I have no idea whether I will ever get anything done with it.
Exact same one I have. I think we'll be PM-ing a bit in the future.
Welcome aboard, Mark! Glad to have more people exploring this sort of stuff! It's an exciting place to be for effects, and the combination of analog processing with digital control offers a lot of possibilities without having to turn everything into just another DSP algorithm.
Since it looks like you're heading PICwards, I'll add a couple of things to what other people have said.
The newer "enhanced" PICs with numbers that start 12F1xxx or 16F1xxx are a big improvement over the earlier chips. They're faster, they have more powerful peripherals, and they add several extremely useful instructions to the instructions set which fill in the holes that the early chips had (add with carry, for example).
People have mentioned PWM as a way of doing analog output, and that works. However, the NCO peripheral (where available) can be set up to do a better job, using Pulse Density Modulation rather than Pulse Width Modulation.
The best way of all of doing an analog output is using a DAC! Several of the newer chips include either 5-bit or 10-bit DACs which are very easy to use.
Finally, trying to use a Velleman programmer connected to a serial port is going to get old fast. A USB programmer will do the job quicker. I use a PICKit3, which is good and not too expensive, but there are clones which are cheaper.
HTH,
Tom
Quote from: PRR on September 13, 2017, 07:07:34 PM
>
A point that I used to think was important (maybe less today): User Interface.
I don't think it's any less important today. The ability to put text an graphical displays on pedals has made those units more flexible at the inevitable expense of usability. There's a local guitar player I'm working with on some pedal ideas. He currently owns a Z Vex thing a ma bob, which he told me "is totally tweakable, but I just always leave it on one setting". So why not have that setting just be the one setting (for him and people who want to sound like him)? I use the FV-1 a lot, and one of its inherent limitations is the number of knobs you can put on it to tweak parameters. 3 usually, 4 if you add some circuitry and code. I can easily create patches that want MORE than that for full tweakability... but it can't be done.
so then I often do things like double controls on one pot, e.g. LFO width and scaled inversely, speed, for a chorus... but that means I have locked you out of super fast super wide (spaceship) sounds. I'm sure it's the 5,000th time I've said it, but making these tradeoffs is IMO a way tougher decision than coming up with the sonic possibilities in the first place. But since a simple FV-1 circuit (without a micro to drive it and save "presets") has these limitations that tilt it towards a performance rather than studio application, you have to make those tradeoffs. There's no obvious formula to follow either, because my sensibilities about these things are personal and not guaranteed to match those of any other individual. So that's one reason it's nice that DIY, where your target audience is just YOU, has come a long way since I was a kid.
Totally agree with Larry. Never underestimate the UI! Especially on digital stuff where it's even easier to screw it up completely and have some hideous thing with ten modes accessed by multiple button presses or hold-for-two-seconds-while-standing-on-one-leg or press-X-while-holding-down-Y and so on. ARGGH!! So wrong. Adding the sophistication of a LCD display and actual words doesn't always make it better either - just encourages people to add every single parameter as an editable option, whereupon you're in that tedious world of trying to paint the hallway through the letterbox.
As Larry says, the hard choices about what gets tweaked and what doesn't are a big part of making something useable. Sometimes having limitations that force you to make those choices makes for a better design in the end. That's one of the reasons I still use a lot of 8-bit PICs. I *like* the fact I can't just sling the kitchen sink in there. Forces me to make my mind up about what's important and what's not, and that's crucial.
Tom
I'll add a third to that. Historically, the user interface is the most difficult part of most programing applications. Even when the only user interface is a switch and an LED, it's usually the most difficult part.
That's because what you're doing is NOT making the part flip bits. You are crawilng inside the unknown user's head and trying to figure out how they can MIS-understand what that blinky light means. More sophisticated UIs just add more ways for them to get it wrong.
You're really trying to get a desired result from an unknown user, not just get the thing to work. And the human mind is the most complicated object in the known universe to date.
Pic, PicKit, C, MPlab. Can't go wrong. Plus it's the most common sort of entry-level embedded programming you find in the industry (at least in UK). If you can program a PIC in C, someone will employ you.
> If you can program a PIC in C, someone will employ you.
Good advice; but Mark is retiring from work.
Which means he will be busier than when he worked.