PIC processors and ADCs

But, you are a genius and they are not. That's understandable.

Well, some professionals are not allowed to publish their source code. Or, perhaps they do not seek the attention. But many hobbyists are delighted to do so because it garners attention and praise.

Of course you will. Try to restrain yourself from releasing it on this group. Please find an appropriate group.

You judge ability based on contribution to the pool? You are very superficial.

Yes, it is a hardware group. So, why do you persist in posting your code here?

I can't find a reference where David said he ran out of speed. Do you have one?

Maybe it would benefit you to stop tipping the wine bottle and take a nap.

Some code is simple and can run on a small processor - other tasks are complex and need more processing power. I am sure that there are some programmers who "need" a fast core because they use floating point instead of scaled integers, or other poor practices. But there are a large number of reasons why a faster core /can/ be a better choice (as well as plenty of situations where it is unnecessary). To list a few:

You get lower latencies when you can handle your interrupts or events faster.

You get lower overall power by having short bursts of high-speed processing combined with long periods of cpu sleep, rather than continuous low-speed operation.

You can run your control loops faster with a faster processor - that can improve regulation accuracy or allow new application areas.

You can process more data, more accurately in the same time.

You can prioritise faster and simpler code development over run-time efficiency, such as by re-using libraries of code even if they are less efficient than more optimal customised code.

I have looked at lots of other people's code. Nothing you have written in this thread gives the impression that /your/ code is worth looking at. Certainly I wouldn't learn anything - I have zero interest in doing any more PIC assembly, and I don't expect to learn anything from your code even if I did.

Just to please you, however, I looked at one of your programs (picked at random) for a frequency counter. It was far from the worst assembly I have seen - reasonably well laid out and well commented. It was not as good a style as the PIC assembly I worked with long ago, which used macros better and more of the assembler's features in order to raise the level a little, but it's not bad for PIC assembly. However, if I had any doubts about the idiocy of working with PICs and assembly language in this day and age, your code convinced me.

I don't publish much source code - almost all of the programming I do is as a professional, working for customers. It is their code - I don't have the rights to publish it.

Different languages are appropriate for different situations, and picking the right tools is an important part of engineering. It doesn't matter how many tricks you know to get the best out of your stone hammer, when the rest of us have workshops full of tools to get the job done.

Don't forget to polish your tin-foil hat - shiny side out to keep /them/ out.

C only so far, been playing with c++11 which is very nice too.

Yeah yeah... I wrote a "full screen editor" in 6502 machine code. Without an assembler. Things move on.

On Sunday I wrote a canbus driver running on an STM32F205. That chip runs at 120MHz. Mine does pulse analysis on a 1MHz ADC data stream, histogramming pulse heights and widths in continuous real time. It also does USB host + fat32, datalogging, dual RS485, canbus, a GUI, keyboard, battery-backed RTC, and does precision pulse generation and timing to run a multislope converter circuit. I don't believe you will do that on your PIC12F.

When I retire maybe, if I ever do, and if I can still program. What I do now is paid for by other people mainly, some of us have to do it for a living.

Python has only been suggested on the PC side, it is very useful there.

C/c++ can be as efficient as assembler on a modern 32-bit core (not on old 8 bit ones though). There is a reason; the cores have been *designed to run it efficiently*. I spent a bit of time trying to improve on the core of an algorithm for pulse height analysis and classification, I was unable to significantly improve on the C-generated one. And variations on the C language version tended to generate the same code anyway.

STM32F2xx costs me $3. It can bit-bang a PIO at 60MHz yet can run a GUI, Ethernet, USB stack, etc etc. Neither a rPi or PIC12 are appropriate for this. The PIC12F is too small and a rPi is too large and expensive. There is a space in between.

--

John Devereux

Actually, I also noted that I sometimes use Python on embedded Linux systems - but they can also be viewed as somewhat like a PC. Jan leapt on that as "proof" that I know nothing of hardware or programming - when in fact it is merely proof that I am flexible in picking appropriate tools for the task in question. He hasn't the faintest idea what I used Python for, because I didn't say and he didn't ask, but merely assumes it is inefficient.

In theory, assembler can always be smaller and faster than C or C++ - that much is obvious. But if you add the criteria that the source code must be clear, flexible, maintainable, developed in a reasonable time frame, and portable at least within the same processor ISA, it's a different matter.

To take a simple example, suppose you have code like this for a small micro with limited processing resources and no hardware multiplier (like a PIC16, or small AVR) :

static const uint16_t scaleHi = 123; static const uint16_t scaleLo = 892;

uint16_t adjustScale(uint16_t x) { return ((uint32_t) x * scaleHi) / scaleLo; }

A C compiler can turn those scales into a set of shifts and adds. An assembly programmer could do so too, of course, but it's a great deal of work to calculate the values and to prove that they are correct - and it must be redone if the scale factors change.

Compilers can do all sorts of optimisations that are infeasible for human assembly programmers except in the very smallest of cases.

For brain-dead 8-bit cpus, like the PIC, the 8051, or the COP8, compilers /can/ produce far better code than human assembly programmers for non-trivial projects. I don't know if good enough compilers exist for the PIC, but on the COP8 and the 8051 there are compilers that handle things like ram bank optimisation, multiplexing of parameters and local variables in statically allocated memory, code de-duplication, and other tricks to reduce the footprint and run time of the program in ways that would be a ridiculous effort to do manually.

For more modern processors (or older but better designed processors), compilers can relatively easily produce good code - and because they are better than humans at tracking register allocations, pipelining, scheduling, etc., they can generate better code than an assembly programmer given the additional criteria mentioned earlier.

Assembly programming makes sense for a few very old systems, for things that can't be expressed in C (such as the first few instructions from reset, interrupt handling, cache control, sometimes SIMD instructions), or for very occasional bits of critical code where the extra effort is worth making.

Sure, I meant to include the rPi there.

E.g. Jan did not write his newsreader in assembler as I recall.

Perhaps I never used good enough compilers. My experience with ~$2k commercial 8-bit compilers was that it tought me all sorts of bad habits in the name of "efficiency". Like making all variables global or static (to avoid stack operations). Making them all 8-bit where possible. Using pointers instead of arrays so as to eliminate index calculations. Manually unrolling loops. All of which is worse than useless now if done for no very good reason.

--

John Devereux

Some of these bad habits are essential for getting the best out of an

8-bit processor, no matter what the compiler (or language - they apply to assembly too). Using 8-bit data were possible is a good example.

But a good 8-bit compiler will make your local variables static automatically - and it will do a better job of it than "manual optimisation" (because it can do lifetime analysis across the whole program, and combine data when there is no possible conflict). Good compilers also do a better job with arrays and indexes directly than if they are converted to pointers, because it knows more about the array and can use that extra information for alias analysis and other tricks.

Now that you are using better processors (and presumably better tools - free gcc and llvm for ARM are vastly better than anything produced for the PIC, 8051, etc.), you have to unlearn those habits!

On a sunny day (Mon, 20 Apr 2015 09:43:36 +0200) it happened David Brown wrote in :

Probably that one I just modified :-)

So, you gave no real example, no code, just general stuff that main stream hardware and software sellers thrive on. And we all know how well that works, if it is not hacked then it does not fly. :-)

I just imagine the day some-boy remotely hacks a mars rover and finds life.

It is out there, but a man that does not want to see is effectively blind.

I suppose you are replying on at least a quad core?

Its your 'tricity bill!

On a sunny day (Mon, 20 Apr 2015 01:05:21 -0500) it happened John S wrote in :

There is a lot of thing you can't !

On a sunny day (Mon, 20 Apr 2015 08:53:19 +0100) it happened John Devereux wrote in :

Looks like you can program.

But I believe John is right - I don't think I ever suggested that I stopped using PIC's because I ran out of speed. I stopped using them because they are crap - the cpu is crap, and the tools are crap. There were and are vastly better alternatives. The speed (or lack thereof) of the cpu is one aspect of why they are a bad choice for almost any job, but it is not necessarily the main one. I have done projects for which a PIC16 would easily be fast enough - and projects for which it hasn't a hope of keeping up.

But you can. Like polishing a turd. Yet it is still a turd.

This is such a vague statement. The speed compared to what? You know you ar e not really stuck with an 8-bit PIC16s. You can always move up the chain. You can get PIC32s in DIP packages that can run 50 MHz @ 1 instruction/cycl e for less than $2. I'd agree with you if you have actually compared the pr ice/MIPS on two different cpus and one of them came a speed winner at the s ame price.

I dare you not think this is cool

On a sunny day (Mon, 20 Apr 2015 12:38:14 +0200) it happened David Brown wrote in :

Maybe you are crap?

Sure, it is cool :)

--

John Devereux

Compared to a snail with a headlamp :-)

More seriously, I am fully aware that not every task requires much processing speed. And I have made systems with chips that are slower than a PIC16. But for a great many modern embedded systems, these chips are not fast enough - people expect more features and more power from their systems now. People used to be happy with a 2x20 character LCD display to show English-language messages on their boxes, and a PIC16 would be fast enough. Now they want a graphics screen and support for a dozen languages - and a PIC16 is just not up to the job. When you can get a Cortex M device for half the price, 50 times the processing power and 20 times the memory, why even consider the PIC?

I know there are other PICs - however, this thread has been about PIC16's (with a brief mention of PIC18's). The PIC32 is a totally different beast with no relationship to the "real" PIC's other than the manufacturer and the buggy peripherals. The MIPS core in the PIC32 is a very nice design, and I would be happy to use MIPS cores instead of ARM cores - the embedded world would be a far better place if more manufacturers implemented MIPS devices in competition with ARM.

However, the PIC32 is a terrible implementation of the core, and has done much to destroy the chances of MIPS in small embedded systems - the peripherals are buggy (/years/ after being introduced with the key feature of being the first cheap 480 Mbps USB microcontroller, it still doesn't work in high speed mode), and the tools are crap and overpriced.

Sometimes I get the feeling that there are at least two "Jan Panteltje" posters as you jump between highly opinionated, but reasoned posts (I know my own posts here have been just as highly opinionated) to comments like this one.

I guess this means we are unlikely to get anything more useful out of this thread.

So why did you compare it to a Cortex? Compare it to MCUs in the same class, then complain about speed.

PIC16s are slow. My Quad Core i7 is much faster.

I am afraid I have lost track of much of what was said in this thread. You are correct that the Cortex M would be better compared to the PIC32 than the PIC16.

But most of the speed comparisons with PIC16's were to AVR's, with Cortex mostly mentioned as being /much/ faster as well as cheaper.