MUFF WIGGLER Forum Index
 FAQ & Terms of UseFAQ & Terms Of Use   Wiggler RadioMW Radio   Muff Wiggler TwitterTwitter   Support the site @ PatreonPatreon 
 SearchSearch   RegisterSign up   Log inLog in 
WIGGLING 'LITE' IN GUEST MODE

A question of microcontroller preference...
MUFF WIGGLER Forum Index -> nw2s  

Which microcontroller/toolchain?
SAM3X/Arduino
10%
 10%  [ 1 ]
STM32F4/gcc
90%
 90%  [ 9 ]
Total Votes : 10

Author A question of microcontroller preference...
scottwilson
Here's a question for you folk...

Would you prefer something like the Atmel SAM3X which would allow you to use the Arduino IDE, but you're limited to what the SAM3 provides, or would you prefer something running with an STM32F4 which would require you to run a gcc toolchain, but provides the following improvements...

floating point unit
(some) DSP capabilities
external SDRAM
2x USB
180Mhz
closer compatibility with a few other pedals/modules available.
(probably some more that I'm not mentioning)

I have the b2 SAM3 module designed since it's based on the Due, but the more I think about it, the more I feel like many of you would prefer either

1. "I'm not going to program it anyway, so make it as capable as possible"
2. "I'm going to hack the shit out of that thing, so make it as capable as possible"

and then the argument for the Due is

"I'm just getting started and don't want to have to worry about the toolchain"

Thoughts?
gattis
Personally between the two I would take the STM32F4, there is still plenty of community for it, and the Due isn't really that arduino compatible anyway, outside of the IDE. I almost always find myself writing custom code for the SAM3X hardware, and examples are more scarce on the net than with stm32f. Very few shields work at 3v3, and you're ditching shield pinout anyway, so that part of arduino is already off the table. Also plenty of people using STM32 in eurorack nation. For instance people making custom firmwares for MI Braids or the OWL folks compiling PureData to stm32f405 instructions.

I'd see about previewing a stm32f7 chip as well, an M7 that's pin compatible with stm32f4 and the M7 instruction set is backwards compatible with M4.

That said, if I were designing such a device, I'd probably go with this brilliant little chip I'm currently playing with, (which there is also arduino IDE support for): http://www.cypress.com/?docID=49437
dadek
[quote="scottwilson"
1. "I'm not going to program it anyway, so make it as capable as possible"
2. "I'm going to hack the shit out of that thing, so make it as capable as possible"
[/quote]

Does number one here correspond to the first selection in the poll? Which way do I vote for non-programmer, super powered. Just want to be clear as there's not likely to be hundreds of votes.
gattis
dadek wrote:
Does number one here correspond to the first selection in the poll? Which way do I vote for non-programmer, super powered. Just want to be clear as there's not likely to be hundreds of votes.


yes, you would be voting for the second option in the poll, STM32F4/gcc
scottwilson
@gattis - Yes, the M7 looks interesting, but the problems with it are that it's still incredibly new. ST has only a single version of the chip in it's catalog and it's only available in BGA which is pretty hard to work with in low runs. (They require X-ray analysis to know if the solder took!)

It does have _some_ benefits over the M4, but only one of them would be of particular interest: a more powerful SPI interface. Maybe an SPDIF interface would be cool to have, but even then, they are available via other means.

It may be a little while before you start seeing the M7 used as widely as the M4 is now.

It's funny you mention Cypress. Where I went to school (Mississippi State University), the EE (Computer Engineering was still new then) department produced two types of graduates - Power engineers who worked for the TVA (power authority) and Semiconductor engineers who did VLSI design for Cypress. I didn't want to do either, so didn't get along with many of my professors!

Oddly, and a total aside, the guy who founded MCI was an elecrical engineer from Mississippi State, but there's not a single person I went to school with who would have known or cared about that. Too sad.

Thanks for the feedback!
scottwilson
> there's not likely to be hundreds of votes

:) Thanks for your vote!
spacenoodle
The nw2sb is in my comfort zone, having learned to program with Megas and Unos. If it wasn't for the huge amount of documentation available (C++ mostly) it wouldn't have been an option - I might have been to frustrated. The thought of getting something more than twice as fast as the Due is intriguing but I'm not sure what this "gcc tool chain" is or how it might impede my ability to problem solve and get things done. How different would the methods be?

By the way, could we thread functions using the STM32F4?
scottwilson
Quote:
I'm not sure what this "gcc tool chain" is or how it might impede my ability to problem solve and get things done. How different would the methods be?


Technically, the Arduino IDE uses gcc under the covers. The Arduino environment gives you a few things that you don't need to worry about...

1. It abstracts away the compilation process. You don't need to install anything other than the IDE and hit the upload button.

2. It also hides the microcontroller setup code. When the ARM MCUs ship, they are a blank slate... 144 pins, each of which can do any number of possible tasks. When you layout the board, you have to assign a job to each of them... memory interface for these pins, USB to these, SPI to a few others. Configuration is done in software and is totally hidden away for Arduino users.

3. It exposes the setup() and loop() functions. Generally, you would only have a main() entry point, but Arduino exposes the setup() and loop() and does a bunch of other fancy stuff in the process. digitalWrite(), digitalRead(), etc. None of this exists without the Arduino framework.

As a hardware developer, it would be my job to provide for you things like #2 and #3. I'm already doing this with the 'b - effectively enhancing the Arduino framework with other useful tools like routines to manage DACs and event-based timing as well as a hierarchy of "devices" like clocks and sequencers.

What I wouldn't be able to do is to help with #1. To get a picture of what's required, you can check out the Mutable Instruments, Owl, or Monome tutorials...

http://monome.org/docs/aleph:development:app

http://mutable-instruments.net/forum/discussion/4344/mac-tutorial-how- to-compile-and-upload-the-firmware-of-mis-eurorack-modules/p1

http://diydsp.com/livesite/pages/AboutUs

Although, with that said (scared away yet?), there are ways to make it a tad bit easier... and unlike with the 'b where I was able to ship with a minimal framework, the 'b2 will need a fully functional firmware and array of presets to be useful out of the box.

Quote:
By the way, could we thread functions using the STM32F4?


Interesting question. Threading support is generally provided by an operating system of some sort... once you introduce the concept of a "thread", you also have to consider things like:

Memory allocation - the OS has to take charge of all memory allocation so that it can track which threads are using which memory.

Memory protection - the OS needs to protect access to each thread's memory space.

Interprocess communications - When the threads need to speak to each other, the OS needs to provide some mechanism to do so. Shared memory, sepaphores, and signals are the most basic of these.

Context switching - this is the crux of the matter. Each thread is effectively running in it's own world. When the microcontroller switches from executing one thread context to another, it has to do a lot of work to make that happen. This is called the context switch and takes a fair amount of overhead.

On small processors like the Cortex M, there are lightweight operating systems like FreeRTOS and ChibiOS that provide this functionality mostly in software.

There are bigger processors like the Cortex A (think: raspberry pi and beaglebone) which include a lot of hardware to help the threading process. So much so that they are nearly impossible to code bare-metal - which is why those all generally run a version of the linux kernel - which is very good at threading and managing the hardware abstraction.

Anyway, to answer your question... I've considered ChibiOS, and may move to that model at some point, but I'm not sure it's yet worth the overhead. We'll see...

-s
gattis
scottwilson wrote:
@gattis - Yes, the M7 looks interesting, but the problems with it are that it's still incredibly new. ST has only a single version of the chip in it's catalog and it's only available in BGA which is pretty hard to work with in low runs. (They require X-ray analysis to know if the solder took!)

It does have _some_ benefits over the M4, but only one of them would be of particular interest: a more powerful SPI interface. Maybe an SPDIF interface would be cool to have, but even then, they are available via other means.

It may be a little while before you start seeing the M7 used as widely as the M4 is now.

It's funny you mention Cypress. Where I went to school (Mississippi State University), the EE (Computer Engineering was still new then) department produced two types of graduates - Power engineers who worked for the TVA (power authority) and Semiconductor engineers who did VLSI design for Cypress. I didn't want to do either, so didn't get along with many of my professors!

Oddly, and a total aside, the guy who founded MCI was an elecrical engineer from Mississippi State, but there's not a single person I went to school with who would have known or cared about that. Too sad.

Thanks for the feedback!


Yea I have been really impressed by Cypress' PSoC's. They are the most innovative thing out there with microcontrollers, and I don't think I've ever had more fun playing with a chip. Love that you can do so many programmable things in the routable analog/digital hardware and take so much load off the CPU. For instance you can make a sawtooth VCO running completely off-cpu but still on-chip: http://www.cypress.com/?docID=33522 If it only had an M4, more analog blocks, and a network of passives you could add to the routable fabric, I can't think of any eurorack module it couldn't emulate pretty well. The IDE is great too for programming the circuits, except for the fact that some clown wrote it all in .NET, which means it'll probably never see the light of day on OSX or Linux.
gattis
scottwilson wrote:
Anyway, to answer your question... I've considered ChibiOS, and may move to that model at some point, but I'm not sure it's yet worth the overhead. We'll see...


How long is that going to take to boot?

I think the problem with moving beyond RTOS is that once you have the overhead of an OS scheduler and context switching etc, you need to add quite a bit of processor power before the timing is just so fast that it seems as tightly controlled as on a microcontroller, if that makes sense...

Plus with so much direct hardware connectivity on a microcontroller, it makes more sense to think of parallelism in terms of event-driven programming than threaded programming.
spacenoodle
Thanks for the explanations. Looks like I'm alone and vastly outnumbered in this but I'm voting for the simpler option. I'm not using your framework - well, some of it. I'm one of those people that will always be hacking shit together but outside of the familiar, very easy and fun world of Arduino I might be confused.

When you say that the b2 will need presets in order to be useful - maybe I'm not understanding that correctly - it sounds like I'd no longer be able to just, for example, copy and paste some Ardcore code in, do some minor tweaks, and get it working?
scottwilson
gattis wrote:

How long is that going to take to boot?


These aren't OSs like you think of Linux that scrolls everything by for days and then gives you a boot prompt. ChibiOS and FreeRTOS are quick boots. Almost immediate. [/quote]

gattis wrote:
I think the problem with moving beyond RTOS is that once you have the overhead of an OS scheduler and context switching etc, you need to add quite a bit of processor power before the timing is just so fast that it seems as tightly controlled as on a microcontroller, if that makes sense...


Yup. Exactly. This is the tradeoff. ChibiOS for example is dedicated to the STM32 processors, so it actually provides some abstraction away from the hardware parallelism that you mention, but is not so general purpose that you lose the specialization required for performance.

It's got relatively quick context switching, and is made for high performance in mind... As you would expect, this gives it a fairly steep learning curve.

It's something to think about - my pays-the-bills job basically consists of ripping up frameworks all day long and making them useful. You could call me a framework skeptic. At least with open-source, it's fairly utilitarian. When you get into some multi-million of dollar e-commerce platform, there's a lot of code there that is only there so some marketing guy can check a feature off a list. You can either rip your hair out trying program around it... or you can start from scratch. I'm usually making the case for starting from scratch.
scottwilson
spacenoodle wrote:

Thanks for the explanations. Looks like I'm alone and vastly outnumbered in this but I'm voting for the simpler option.


It's a pretty small sample size, so don't feel too alone! I definitely see the argument for that approach.

spacenoodle wrote:

When you say that the b2 will need presets in order to be useful - maybe I'm not understanding that correctly - it sounds like I'd no longer be able to just, for example, copy and paste some Ardcore code in, do some minor tweaks, and get it working?


I should say it will need an array of presets to make it useful to normal folk. Like having a few default program modes for each of the instruments... game of life, otogrid, 8 voice midi to CV, 4 voice midi to CV, midi CC to CV, Alanesque, Random Sequencer, glitch looper, etc.

If you wanted to glue together code a la arduino, that would be entirely possible as well, the main difference would be that you'd need a different development environment... Rather than the Arduino IDE, you'd need a text editor, GCC, and the uploader. It's definitely a scarier (and more frustrating) if you're not used to dealing with build environments.

What would be great is if someone broke down and forked the Arduino IDE for the STM32F4. If ST did that, they wouldn't be able to keep their Discovery boards on shelves!

s
MUFF WIGGLER Forum Index -> nw2s  
Page 1 of 1
Powered by phpBB © phpBB Group