Main > Main Forum
Leobodnar Electonics
MacGyver:
Wow RandyT, that is a really good breakdown of features and explanation. :applaud:
BadMouth:
RandyT, will this new device work with 5k arcade pots?
Would it be smoother with higher resistance pots?
MonMotha:
--- Quote from: RandyT on March 21, 2013, 11:52:48 am ---If the code was written in optimized assembly, like we do with ours, it's probably fast enough. But if it's done in compiled C, as most microcontrollers seem to be nowadays, I'd have some concerns.
--- End quote ---
Amusingly, good C compilers often do a better job of optimizing than most programmers these days. I think the whole "assembly is fast, compiled C is slow" comes from the fact that 1) Microchip's C compilers have historically sucked (and still kinda do, partly because the 8-bit PIC is a pain to compile for, the 16-bit PIC24 series is a LITTLE nicer), and the free versions of them many people use are deliberately crippled to produce bad code and 2) it's way easier to do complex, big stuff in C than doing it all directly in assembly.
I've done USB IO boards on an 8MHz AVR with little issue, even using a fairly complex and overgrown USB stack, though 16MHz does indeed provide a lot more overhead. Of course, the AVR is a mostly single cycle core whereas the PIC is typically at least 2 cycles per instruction.
RandyT:
--- Quote from: MonMotha on March 21, 2013, 01:18:28 pm ---Amusingly, good C compilers often do a better job of optimizing than most programmers these days.
--- End quote ---
I think that says more about the state of programmers these days than it does the compilers ;). Tight and clean assembly is nearly a lost art nowadays. It was a lot more common in days past, where processors were slow and it was necessary in order to get things done. There's no doubt that complex functions are better handled in C nowadays, strictly from an ease, code re-use, and speed of development standpoint. Even so, while many rightly claim it's not necessary given the right combination of processor and compiler, optimized assembly will almost always be faster. In fact, there are some things which absolutely require it. For example, something like the LED-Wiz would be very difficult to do any other way, without dedicated peripheral hardware, or an extremely fast microcontroller. Bit-banged timing sensitive communications protocols are also a good example.
But I have to admit, several months ago I began doing some C development with the above "right combination", for an upcoming product offering, and my tests are showing very good performance. Of course, the processor is also 2 to 8 times faster than the one shown in the link (depending on whether it is clock-doubled and the number of cycles per instruction). C is definitely easier and the development time shorter.
MonMotha:
It also depends on the complexity of the pipeline and how "smart" your compiler is. Intel's C compiler will out-optimize almost anybody on their modern CPUs on tight inner-loop kernel performance simply because the pipeline is so complex that it's very difficult for a human to 1) fully know/understand all the interactions, and 2) keep it full. People who are really good with compilers and know the pipeline extremely well have sat down and automated the process. Even gcc does amazingly well on many x86 targets.
On smaller MCUs with much simpler pipelines and less mature compilers, yeah, a human can often out-optimize the compiler without too much effort. Of course, the real speed gains usually come from things the compiler doesn't know how to do, like improving the runtime complexity of the algorithm. You can do this in C or assembly, but the guys willing to write tight-coded assembly are usually more willing to put forth the effort and better at it. In general, I've found that, if you have a fixed time budget on a project, you do much better to write the whole thing in C, profile it, and figure out where the hotspots are and give them manual attention. Inspecting the output of the compiler (e.g. a disassembly with symbols) is often a very useful thing.
Also, figure you can now get a ~50MHz 32-bit MCU (ARM Cortex-M0) for like $1-2. That's so much CPU time that you'll get far better gains from using the thing properly (e.g. taking advantage of DMA) than trying to count instructions. I do still use 8-bit MCUs, occasionally, mostly when I want a small package (e.g. 8 pins) and something really cheap in low quantity. My goto part is usually something in the tinyAVR series. I've used e.g. a tiny25 recently which is about 50 cents in low quantity and can at 16MHz off the internal oscillator if you don't care too much about timing accuracy and jitter. Anything where I need USB, at this point, I'm going to reach for an ARM.