PIC processors and ADCs

On a sunny day (Sat, 11 Apr 2015 01:29:10 -0700 (PDT)) it happened Sonnich Jensen wrote in :

See datasheet

Jan Panteltje wrote in news:mgammi$631$ snipped-for-privacy@news.albasani.net:

Many newer PICs let you configure pins as analog or digital individually in any order. Search the datasheet or device specific header for "ANCON" to see if this feature is available.

However older PICs like the PIC16F73 only let you allocate analog pins in order. e.g. if AN3 is in analog mode, then AN0 through AN2 will be as well. You can still use a pin in analog mode for digital output (if you are careful to code to avoid the RMW effect), but its port bit will always read '0', preventing you useing it as a digital input.

On a sunny day (Sat, 11 Apr 2015 13:31:53 +0000 (UTC)) it happened Ian Malcolm wrote in :

But you can use an analog input to read a digital signal, at some speed penalty.

Or reconfigure on the fly as needed perhaps.

If you can use anything other than a PIC, do so.

Yes.

what is you reason for this statement?

Ok I will then use it for the basics, and get a newer one when it comes to the prototype.

The PIC cpu is crap. It was crap 20+ years ago when it was introduced, and it hasn't improved since. The tools are not quite as bad as they were then, but they haven't improved at the rate alternative tools have improved. The peripherals and the rest of the chip are robust, but were merely mediocre when the the chip in question was new, about 15 years ago IIRC.

The microcontroller world has moved on, leaving chips like that /far/ behind. The one thing the PIC's have going for them is that if you made a mistake and picked one 15 years ago, you can still get them (and that is one of the few strengths of Microchip's microcontrollers).

On a sunny day (Sun, 12 Apr 2015 22:27:31 +0200) it happened David Brown wrote in :

There are several types, what or which are you talking about?

You come in from the wrong angle altogether. It is just a Turing machine. There are many types. It does what it does and it is up to the programmer to know how to use it.

I see many complains about PICs. Sure, some hardware in some PICs (all) has its limitations or simply bugs, so should not be used or worked around, or else use a different PIC.

For the rest I dare claim you cannot program, especially given your rant about the 'tools'.

A real musician can make great music on a child's flute, and a bad one can only make bad sound even if you give him a Stradivarius.

So know your stuff, IF you had done so you, then you would have selected the right processor and right tool to begin with.

Other manufacturer's chips also have pages of errata (Intel comes to mind), also to the point where promised functions do not even exist.

It was cool, and you find PICs in anything from mouse to thermostat to what not.

Wrong again, the peripherals are the weak part, SPI could be not working what not, see erratas.

A controller is a controller and if you cannot program it just stays a piece of silicon looking at you with that expression" dummy

:-)

There was an other anti picker here some years ago, have not heard much from him lately.

Yes, the CPU is crap. But the peripherals are wonderful compared to e.g. AVRs. And IMHO the most important thing in this segment are peripherals...

Best regards, Piotr

I agree that peripherals are important here - but not that the cpu (and tools) are unimportant. I also disagree that the peripherals are "wonderful compared to AVR's". There are advantages and disadvantages in most variations in peripherals, but the PIC16 peripherals are in no way outstanding compared to what is found on an AVR or other small microcontrollers.

I don't think they (PICs) are quite as crap as you imply.

They are not well suited to HLLs but they can still be a decent choice for some smaller applications where they happen to have just the right combination of ADC/DAC and IO for a minimalist single chip solution.

I agree that if starting today ARM cores are *much* nicer to use.

You need to consider life cycle carefully when buying AVR.

Try to implement an MCU-based SMPS (e.g. with digitally controlled voltage in order to justify an MCU at all) using an AVR. With e.g. PIC16F1709 it is a no-brainer. COG, CLCs and PPS are just great.

Best regards, Piotr

The CLC is an interesting peripheral that I haven't seen before. Of course, the PIC in question here (PIC16F73) doesn't have a COG, CLC or PPS.

It's a while since I have looked at newer AVR devices, but from a very brief check of an example ATxmega8E5, it completely outclasses the peripherals of the PIC16F1709 with lots more analogue, PWMs, timers, etc., as well as an "event" system and DMA letting the hardware deal with a lot of the work.

And of course the cpu is 10 to 20 times as powerful, as well as being much easier to work with (though not perfect) and having far better development tools. If you don't want to spend $1000 on real tools for the PIC, and use the crippled free compiler, the speed difference in the processor will be another factor of 4 or so (since the AVR development tools are /really/ free).

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

Than makes no sense, I spend exactly nothing on 'development tools' and assembler (do not use C on a 16F or small 18F).

I had build the noppp programmer from parts from the scrap box for 16F84,

So I wrote the programming software for 18F PICs for that programmer too:

I use gpasm in Linux (part of gputils) as assembler, and there you go.

All you need is luf^H^H^H is an I/O pin and get serial working on any of those PICs, I'v done 12F, 16F, 18F, and that is really all you need, and a scope helps.

All that crap about MPlab, and 'slimulation', people live in a phantasy world where NASA shows artist impression of animals on alien planets, and nobody can do the real thing or even know hat a soldering iron looks like or do a serial port in software or whatever,

For that reason and that reason ALONE one should start in asm on a PIC.

You talk ARM, well, if you want ARM you should stay clear, I repeat STAY CLEAR, of all those expensive proto boards that are pushed by chip makers, but buy a Raspberry Pi. gcc is the best C compiler around, you can program in C, and have most of the tools you can think of, and most software ever thought of, ready for download, plus HDMI HD TV out, hardware MPEG decoding, ethernet, USB, and what not. All for 35$ and huge user group to help you.

So small, learn embedded, and bigger, Raspberry, its GPIO port can do a lot of things. For real time there is also risc OS, but I have to admit I have no clue about that, installed it once on a SDcard, and really did not know what do with it or what to type. So use Linux (Unix) buy a good book (on Unix) and start on the Raspberry if you have bigger plans than just making a single chip scope (ran out of memory on more features). That investment of 35 $ pays of. Stay clear of python and other failure modes of people who are trying to re-invent languages.

?? I heard the latest raspi has a quad core, is that true?

more... :-)

It's good to know that even Atmel has finally implemented good peripherals. :-)

But: it's a 32-pin CPU and the PIC is 18. 16F1705 is just 14 (same as 1709, less pins). Additionally, you can order these PICs in almost any package you want, from DIP through (T)SSOP down to QFN. It allows me to experiment with a DIP one and put the SOIC version onto the board.

It's faster, but not that much faster. And if you need performance, just use an ARM in a tiny package and don't waste your time with 8-bitters of any ilk.

Here there is no way to disagree... :-( The XL compiler is a real crap.

Best regards, Piotr

Den tirsdag den 14. april 2015 kl. 13.04.04 UTC+2 skrev Jan Panteltje:

expensive?

around 10$

and that includes a proper debugger

-Lasse

I haven't done any comparative study of peripherals in the AVR and PIC over time, but I am confident that there has never been a time when there was a vast difference in the choice, or that the PICs were ever a leader in the types or quantities of peripherals.

Atmel has AVR's down to 8 pin sizes - but so what? This was just one example. My guess that an AVR with enough pins and peripherals for a SMPS will have approximately 14-20 pins. And as I have said before, I don't think DIP packages are relevant - there are few cases where it makes sense to use one rather than a ready-made board or evaluation kit when doing testing or pre-prototyping.

I haven't done any timings, but I think it is /that/ much faster. To start with, it is 32 MHz rather than 8 MHz - that's a factor of 4. Then there is the limitation of the PIC architecture, with everything passing through the one register (the AVR has 32) - you need more instructions to do the same thing on a PIC compared to an AVR. Then the memory banking (ram and flash) eat up additional time, as do the lack of multiply instructions and other differences. Of course there is going to be variation for different types of code - multiply-heavy code will be a lot more than 20 times faster on the AVR, while code that does bit-banging, sticks to 8-bit arithmetic and doesn't need bank switching will perhaps only be 6 times slower than an AVR.

And of course there are AVR's that run slower than 32 MHz, and presumably PIC16's that run faster than 8 MHz.

I agree 100%.

I would also say that if you value your software development time, or are interested in using normal, portable C and good tools, then a Cortex M device makes most sense (though msp430 is also a good choice, and the AVR is not bad).