Author Topic: PIC versus Atmel/ESP/STM/etc.  (Read 6766 times)

0 Members and 1 Guest are viewing this topic.

Offline 0xFFF0Topic starter

  • Regular Contributor
  • *
  • Posts: 87
  • Country: de
PIC versus Atmel/ESP/STM/etc.
« on: April 03, 2023, 07:03:11 pm »
Does a project with a PIC still make sense? I have the impression that the PICs are no longer properly supported. In comparison, there are 100x more code examples and projects with the new MCUs. Does a PIC still have an advantage?
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3146
  • Country: ca
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #1 on: April 03, 2023, 07:20:30 pm »
There are over 2000 different PICs. All different. Which one are you asking about?

There are also thousands of ways to use MCUs. You chose MCU based on your needs. What is your particular goal?
 
The following users thanked this post: SiliconWizard, woofy

Offline AVI-crak

  • Regular Contributor
  • *
  • Posts: 125
  • Country: ru
    • Rtos
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #2 on: April 03, 2023, 07:22:40 pm »
There is little.
Pallets with PIC chips surprisingly have the same dimensions - as pallets with WCH chips. You can use the chip storage space without buying new racks.
And yes, PIC can be thrown away.
 

Offline jpanhalt

  • Super Contributor
  • ***
  • Posts: 3479
  • Country: us
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #3 on: April 03, 2023, 07:28:22 pm »
And yes, PIC can be thrown away.

So can any other chip brand.  Can you suggest a brand that is indispensable?  If it works and is priced right (i.e., less) should be the determinants.  I do not include in that consideration fraudulent chips.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13748
  • Country: gb
    • Mike's Electric Stuff
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #4 on: April 03, 2023, 07:38:06 pm »
Every MCU has good and bad points, and also factors not directly related to the physical part.
e.g.
You can buy pre-programmed parts from Microchip Direct with minimal setup and programming costs.
Need a 32 bit MCU in a DIP or SOIC? AFAIK Microchip is the only vendor offering the former at least.
Most PICs are available in a choice of 3 or 4 packages
Want to use the same IDE and programming hardware ( and very similar peripherals) across a range  of 8, 16 and 32 bit parts, from a SOT23-6 to a 288 pin 200MHz parts - again Microchip is the only game in town
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline 0xFFF0Topic starter

  • Regular Contributor
  • *
  • Posts: 87
  • Country: de
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #5 on: April 03, 2023, 11:51:17 pm »
The Arduino environment is growing and growing with tons of example whereas the MPLAB is a very sad party. Microchip simply has very little to offer.
 

Offline fchk

  • Regular Contributor
  • *
  • Posts: 245
  • Country: de
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #6 on: April 03, 2023, 11:54:52 pm »
Does a project with a PIC still make sense? I have the impression that the PICs are no longer properly supported. In comparison, there are 100x more code examples and projects with the new MCUs. Does a PIC still have an advantage?

Most people only know the old 8 bit PICs and forget that there are also very neat 16 and 32 bit PICs (complete different architectures). Think of 100 MHz dual core motor controllers etc.

And even today's PIC16 are much different from an old PIC16C50. They have an enhanced (more C friendly) CPU core, some have small programmable logic, numeric controlled oscillators, and other core independent peripherials. There is still a market for this.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4039
  • Country: nz
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #7 on: April 04, 2023, 12:31:57 am »
The Arduino environment is growing and growing with tons of example whereas the MPLAB is a very sad party. Microchip simply has very little to offer.

Microchip also have AVR, Arm, and RISC-V parts. And of course some of those PICs are MIPS.
 
The following users thanked this post: MK14

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4039
  • Country: nz
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #8 on: April 04, 2023, 12:41:49 am »
Need a 32 bit MCU in a DIP or SOIC? AFAIK Microchip is the only vendor offering the former at least.

SOIC is easy. 32 bit MCU in SOIC 8 pin (10c each) and 20 pin (14.6c each) right here:

https://www.aliexpress.us/item/3256804850399956.html

32 bit in DIP ... not easy. But here's one. 3324 in stock. Not even Microchip.

https://www.digikey.co.nz/en/products/detail/rochester-electronics-llc/LPC810M021FN8129/12102361
 

Offline PCB.Wiz

  • Super Contributor
  • ***
  • Posts: 1546
  • Country: au
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #9 on: April 04, 2023, 12:53:43 am »
Does a project with a PIC still make sense? I have the impression that the PICs are no longer properly supported. In comparison, there are 100x more code examples and projects with the new MCUs. Does a PIC still have an advantage?

PIC is a prefix, not a specific microcontroller.
There are 12/14/16 bit opcode PICs and PIC18 and PIC32 plus dsPIC ....

Of course, older MCUs fade as their FAB support tails off, and the price bathtub curve discourages new design ins, but they are still sold to mature products where the inertia of things like approvals may make a re-spin too costly.

Few would select a PIC12 for a new design in 2023, but the very cheap asian clones in lowest pin counts often use close to brain-dead cores.

If you only need a smart timer, any MCU will do ....

 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14482
  • Country: fr
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #10 on: April 04, 2023, 01:41:39 am »
The Arduino environment is growing and growing with tons of example whereas the MPLAB is a very sad party. Microchip simply has very little to offer.

Fixed: "has very little to offer non-Atmel MCUs that aren't supported by Arduino."

Microchip has been owning Atmel products for a while now. Most Atmel products (even the 32-bit ARM) are supported by Arduino.

As to historical Microchip MCU lines and models (which are many as others have said), they usually aren't, although I'm not 100% sure none of them aren't (for instance the 32-bit ones.) For various reasons.
But they can still be pretty useful, there's a whole world outside of Arduino. You don't even need to wear a mask to discover it! ;D
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4039
  • Country: nz
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #11 on: April 04, 2023, 01:41:50 am »
Few would select a PIC12 for a new design in 2023, but the very cheap asian clones in lowest pin counts often use close to brain-dead cores.

The 3c Padauk chip with 1k instructions of OTP and 64 bytes of RAM certainly has uses. 8 bit PIC-alike instruction set, supported only by a custom not-quite-C language and compiler. Can't debug it.

If you splash out 10c you can get a 32 bit RISC-V CH32V003 with 16k of flash (5000-6000 more powerful instructions), 2k RAM. You can use standard C/C++ (or Rust if you want) via upstream gcc or LLVM. You can use gdb.

Reckon it's worth the extra 7c, unless you're doing incredible volumes.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14482
  • Country: fr
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #12 on: April 04, 2023, 01:47:13 am »
8-bit PIC MCUs are pretty good, are very well documented, have good support, product ranges are very wide with tons of configurations and some are ultra low power, some can withstand 150°C.
Try using an obscure chinese MCU in your next product - it may work fine but good luck with documentation, support, or any guarantee from the manufacturer. So different use cases, different requirements.

And simple 8-bit MCUs can still have their place - sometimes a very simple architecture with simple peripherals is just better to lower the overall complexity of a system.
You can pretty much fully master how an 8-bit PIC works, down to the clock cycle. Good luck with even a Cortex-M0.
Sometimes it doesn't matter, sometimes it does.
 
The following users thanked this post: freda

Offline dobsonr741

  • Frequent Contributor
  • **
  • Posts: 674
  • Country: us
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #13 on: April 04, 2023, 02:34:24 am »
I think we should be talking open source tools and libraries support for hobbyist purposes, maybe for light commercial use. This is where the PIC goes under. Not Microchip, happily grabbing a nice share with the Atmel lines.
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 3461
  • Country: it
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #14 on: April 04, 2023, 05:02:55 am »
Does a project with a PIC still make sense? I have the impression that the PICs are no longer properly supported. In comparison, there are 100x more code examples and projects with the new MCUs. Does a PIC still have an advantage?

Who cares!
Besides, how many of those examples you mention are close to the metal so you really know how to program them? How many threads do you see in the various forums in which the person is stuck due to their lack of understanding of the library or wants to do something the library doesn't let him or the lack of information in the documentation? There could be ten thousand projects for new MCUs but if the only support and programming tools i get is platformIO or arduino, thanks but no thanks i'll grab any for which i have real documentation and a C compiler

Also: If we look at sales number in the west microchip is huge, there seems to be an inverse relationship between popularity and actual number of devices sold

Also: The newest PIC18F Q20 will be one of the first publicly available devices with I3C support, PIC18F keep getting newer and more advanced devices, even though we really are getting at the end of the line (there is no more space available for SFRs, they are resorting to banking the banks. yikes!) why invest in the architecture if it's dying due to lack of popularity? (hint: all the parts we use are firstly designed for clients that need them in huge numbers and we get the leftovers)

Also: As already said, most people think about "PIC" or "AVR" with the 16F84A/876A/18F2550 and the 328P respectively. Ancient parts with decades on their shoulder, the world have moved on and we have excellent 8/16bit parts, pretty good (ATSAM,PIC32MX) and meh (PIC32MZ/MK -- because of the erratas, and because MIPS is more or less dead, and experts that talk online are much harder to find that ARM) 32bit parts
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4199
  • Country: us
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #15 on: April 04, 2023, 05:55:26 am »
Quote
32 bit in DIP ... not easy.
A bunch of the PIC32MX series is available in SPDIP-28.  Up to 256k flash and 64k RAM.
---


I don't think I'd start a new project on an 8bit PIC (PIC12, PIC16, PIC18) unless I specifically needed some unique peripheral feature that wasn't available on AVR, ARM, or RISC-V chips at similar cost (There's a PIC18 with Ethernet MAC and Phy, for instance.  Most hobbyist projects don't end up using "special" peripheral features, but they were included on the chip for SOME application!)  That doesn't mean that 8bit PICs have lost their usefulness, they're just ... less pleasant to work with.  (that bank-switched RAM.  Compilers don't like it either.)  (that said, many applications won't run into the unpleasantness.)
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13748
  • Country: gb
    • Mike's Electric Stuff
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #16 on: April 04, 2023, 07:48:43 am »
I think we should be talking open source tools and libraries support for hobbyist purposes,
Hobbyist volumes are insignificant. I don't care if tools are open source as long as they work.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4039
  • Country: nz
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #17 on: April 04, 2023, 09:05:19 am »
Quote
32 bit in DIP ... not easy.
A bunch of the PIC32MX series is available in SPDIP-28.  Up to 256k flash and 64k RAM.

Microchip offering some was assumed in the post, as mentioned in the part you snipped. The challenge was NOT in finding a Microchip 32 bit MCU in DIP -- we already knew they have them -- but a NON Microchip.
 

Offline woofy

  • Frequent Contributor
  • **
  • Posts: 334
  • Country: gb
    • Woofys Place
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #18 on: April 04, 2023, 09:06:40 am »
The Arduino environment is growing and growing with tons of example whereas the MPLAB is a very sad party. Microchip simply has very little to offer.

I use a lot of PIC's from PIC16/18's through to PIC32MZ. Microchip are continually bringing out new chips with new features/peripherals even in the PIC16 flavors. They would not do that if there was no demand.

Offline ppTRN

  • Regular Contributor
  • *
  • Posts: 117
  • Country: it
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #19 on: April 04, 2023, 09:51:56 am »
I personally uses old pics like 16Fxxx and 18Fxxx for educational purpose. I must say tho that i find still helpfull pics from the dsPIC30F and dsPIC33 series. They are fast and full of hw resources. I never worked with newer pics but i am sure that microchip is keeping up with the market even tho STM32 seems more diffuse.

PS: have you noticed that in many dyson products, in the ads where you see the internal PCB, there is a PIC uC!!
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13748
  • Country: gb
    • Mike's Electric Stuff
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #20 on: April 04, 2023, 11:08:16 am »
The Arduino environment is growing and growing with tons of example whereas the MPLAB is a very sad party. Microchip simply has very little to offer.
Sad in what way ?
MPLAB is a tool for professionals.
Arduino is for teaching and hobbyists.
Microchip care about commercial design-ins, not whether  hobbyists chooses PIC or ESP. They've been doing pretty well on that.
Having said that, Microchip have been more hobbyist-friendly than most other MCU manufacturers over the decades.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline WatchfulEye

  • Regular Contributor
  • *
  • Posts: 110
  • Country: gb
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #21 on: April 04, 2023, 11:25:42 am »
Also worth remembering that a number of the atmel MCU lines have been experienced some cross pollination, and the progeny are now called PIC.

For example the PIC32CMLx series with cortex M23 core is so similar to the atmel SAML2x series that you'd better check the docs carefully to spot the changes (and which errata have been fixed and also which ones haven't).
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4199
  • Country: us
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #22 on: April 04, 2023, 03:39:25 pm »
Quote
Microchip have been more hobbyist-friendly than most other MCU manufacturers over the decades.
That was their big advantage for a long time.  PICs (of the 8bit variety), and their development tools, were available to hobbyists at reasonable prices for probably a decade or more before other vendors caught on to that whole "catch them when they're young" concept.  First small (and relatively cheap) UV-eraseable chips, first OTPs (cheaper), first serial programmable EEPROM-based chip, first to appear at hobbyist vendors (yeah Parallax!)
Atmel had the "first" flash-based microcontrollers, but they were nearly impossible to obtain (on the hobbyist market) for a long time, while the PIC16C84 was gaining mind-share.


Now-a-days, we are all spoiled.  Digikey grew up, other formerly-professionals-only vendors automated to the point where they were willing to handle small orders, and thanks to Internet, many manufacturers will sell direct to anyone.
It's hard to imagine the days when the entry cost to working with a microcontroller was several hundred dollars worth of board-level products and EPROM programmers, plus several thousand for a computer (or similar equipment) to connect it to (rare!) (pre-inflation $$, too) instead of the cost of a fast food meal for something that plugs into the computer you already have (to watch cat videos and argue with people, you know.)
 
The following users thanked this post: mikerj, tooki, newbrain, PCB.Wiz, SiliconWizard

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4039
  • Country: nz
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #23 on: April 05, 2023, 12:23:40 am »
It's hard to imagine the days when the entry cost to working with a microcontroller was several hundred dollars worth of board-level products and EPROM programmers

I remember them, and it was daunting and kept me out.

I designed and built some things using 74xx, 555, 741 and transistors when I was in high school in the late 70s. There was a company in Auckland, David Reid Electronics, that sent a huge bound catalogue (with a Moire pattern on the cover) to anyone who asked for one, including kids. You could post an order to them and usually get your stuff in a week.

In my 3rd year at university (1983) I worked on an extra-curricula project with two others, designing and making a wire-wrapped M6809 with DRAM (with software refresh), a UART, and an 8" floppy interface. One of my contributions was the clock logic, which could independently make each of the HI and LO phases either 0.25µs or 0.5µs based on the hi bits of the address bus: 2 MHz for RAM, 1 MHz for peripherals, and 1.33 MHz (asymmetrical) for the Motorola monitor ROM based on a careful study of its timing diagram :p We also wrote a BCPL code generator for it (running on VAX), and a mini multi-tasking OS.

After that I didn't touch hardware for a LONG time.

I became aware of BASIC Stamp in the late 90s I think, but that didn't appeal. PICKit seemed too expensive and fiddly. A friend got the first Arm MBED in 2009 I think, and I was thinking about that when someone locally in NZ started selling Arduino Uno and BOOM I was in.

People criticise Arduino a lot here, but the on-ramp is SO GENTLE, and yet it doesn't constrain you in any way. You don't have to use their editor. You don't have to use their libraries (or only use parts of them). You can see exactly what commands it is running, so you can easily copy&paste the right commands to run gcc or avrdude directly if you want. But it is all there to be used up to the point that you don't want it. I actually often use the Arduino IDE terminal emulator in preference to minicom or something even when I'm working with boards that aren't supported in the IDE.
 

Offline Kim Christensen

  • Super Contributor
  • ***
  • Posts: 1327
  • Country: ca
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #24 on: April 05, 2023, 03:22:12 am »
It's hard to imagine the days when the entry cost to working with a microcontroller was several hundred dollars worth of board-level products and EPROM programmers
I remember them, and it was daunting and kept me out.

It was a huge challenge for the hobbyist doing it on the cheap. My first foray into that world was with the Z80 in the mid 1980's. Built a system with battery backed up RAM for the program memory. Then built a TTL/CMOS keypad interface so I could enter HEX codes into the RAM and run it. (I didn't own a computer) Wrote all the code out on paper for the monitor/debugger and hand assembled it. When it was done, studied the 2716 eprom datasheet and wrote some code so it could copy the monitor/debugger code to the eprom. This was my final year project for tech school and I probably wouldn't have done it otherwise.

My first microcontroller was the 68HC11 in the 90's. I chose it because of the built in bootloader that let you program it via the serial port which was way easier than the Z80. But being cheap once again, I ended up making my own assembler in BASIC which ran on an old Tandy COCO2 and later on my first PC.

So when I discovered PICs and MPLAB  I was pretty stoked. Things suddenly got a lot easier. I still have a quite a few of them in the bin and will occasionally grab one for a project because a micro in the hand is worth 100 on backorder.
But if I was starting from scratch, I'd choose whatever is currently popular and fits my needs. It's always a tradeoff about ease of use, software support, capabilities, tools you already have, etc. No shame in using a PIC or dated tech if it works for you.


 

Offline barshatriplee

  • Regular Contributor
  • *
  • !
  • Posts: 130
  • Country: bd
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #25 on: April 05, 2023, 05:49:39 am »
The choice can come out differently for different applications. But considering the cost, people are inclined to STM32 more. Here are some articles that you may find helpful.

https://www.wellpcb.com/pic32-vs-stm32.html
https://titoma.com/blog/stm32-pic32-manufacturing
 

Offline 0xFFF0Topic starter

  • Regular Contributor
  • *
  • Posts: 87
  • Country: de
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #26 on: April 05, 2023, 11:23:08 am »
Development cycles are extremely fast these days. I don't want to deal with data sheets and registers for months. What every developer needs, are powerful libraries and a large number of sample applications. Almost all MCUs that are not in the Ardunio environment have lost.
 

Offline voltsandjolts

  • Supporter
  • ****
  • Posts: 2300
  • Country: gb
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #27 on: April 05, 2023, 11:41:53 am »
I don't think the OP wanted an answer, they just started this thread to express their (blinkered, misguided) opinion.
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 3461
  • Country: it
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #28 on: April 05, 2023, 12:23:02 pm »
I don't think the OP wanted an answer, they just started this thread to express their (blinkered, misguided) opinion.

Which, IIRC, i not their first time

Development cycles are extremely fast these days. I don't want to deal with data sheets and registers for months. What every developer needs, are powerful libraries and a large number of sample applications. Almost all MCUs that are not in the Ardunio environment have lost.

You have the right to your opinion  :-//
 

Online newbrain

  • Super Contributor
  • ***
  • Posts: 1719
  • Country: se
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #29 on: April 05, 2023, 12:37:55 pm »
Almost all MCUs that are not in the Ardunio environment have lost.
You might have misspelled lots.
Nandemo wa shiranai wa yo, shitteru koto dake.
 
The following users thanked this post: voltsandjolts, Kim Christensen

Offline peter-h

  • Super Contributor
  • ***
  • Posts: 3700
  • Country: gb
  • Doing electronics since the 1960s...
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #30 on: April 05, 2023, 01:42:14 pm »
I would answer this a bit differently. Most applications can be done by most CPUs, within broad limits. But some companies discontinue parts much more readily than others. I used an Atmel part, it went OEL, I started a design with a replacement from Atmel, that got dropped even before I got around to doing the PCB (we had a fair stock of the old part). So, no more Atmel for me.

I would trust ST and (from many years ago; not sure about present) Hitachi/Renesas.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3146
  • Country: ca
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #31 on: April 05, 2023, 02:39:25 pm »
Development cycles are extremely fast these days. I don't want to deal with data sheets and registers for months. What every developer needs, are powerful libraries and a large number of sample applications.

No need. Just use ChatGPT and it'll write the program for you instantly and much better than you ever could.
 
The following users thanked this post: JPortici

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14482
  • Country: fr
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #32 on: April 05, 2023, 06:53:38 pm »
Almost all MCUs that are not in the Ardunio environment have lost.

Really! :-DD
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #33 on: April 05, 2023, 06:59:18 pm »
The best microcontroller for a project is usually the one you are familiar with and know how to develop for. If I were starting out today I'd probably go with STM32 but since I know AVR I've stuck with the 8 bit AVRs, they're adequate for most of my needs. For other stuff there is the ESP8266 and ESP32, I use the Arduino framework on those, but Arduino is really only good for hobby projects.
 
The following users thanked this post: bookaboo, peter-h

Offline voltsandjolts

  • Supporter
  • ****
  • Posts: 2300
  • Country: gb
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #34 on: April 05, 2023, 07:03:49 pm »
^ Yeh. I think AVR MCUs + avr-gcc is the best 8-bit development experience.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4199
  • Country: us
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #35 on: April 05, 2023, 10:28:36 pm »
Quote
AVR MCUs + avr-gcc is the best 8-bit development experience
how about 8051 with Keil (say, using the SiLabs advanced 8051 chips and their free version of the compiler/IDE)?
(Has someone used both enough to compare them?  I'm not interested in "8051 isn't really designed for use with C" arguments...)


Keil IDE and compiler have a good reputation, except for the price, and the SiLabs deal negates that...

 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14482
  • Country: fr
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #36 on: April 05, 2023, 10:38:07 pm »
You can't beat a Z80 with Turbo Pascal 3.0!
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4039
  • Country: nz
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #37 on: April 05, 2023, 10:46:04 pm »
You can't beat a Z80 with Turbo Pascal 3.0!

I never used TP3, but from memory I could beat Turbo Pascal 1.0 with my eyes closed. On suitably small functions, with enough time to spend.

It was massively better than any compiler for 6502 at the time though. Maybe even now.
 

Offline nigelwright7557

  • Frequent Contributor
  • **
  • Posts: 690
  • Country: gb
    • Electronic controls
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #38 on: April 05, 2023, 11:14:45 pm »
I have sort of got bogged down in PIC.
I have been programming then since mid 1980's.
I have so many projects I can draw on for functions like USB, FFT etc.
Why reinvent what I already have in abundance ?

The current chip shortage is a nuisance, I have to buy what Microchip have in stock then convert my code to that.

 

Offline peter-h

  • Super Contributor
  • ***
  • Posts: 3700
  • Country: gb
  • Doing electronics since the 1960s...
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #39 on: April 06, 2023, 06:35:00 am »
Big mistake of Zilog to not bring out a Z80 based microcontroller. They owned the world, and gave it away.

They had all the peripherals anybody might want.

The chip shortage is over, but the distis are desperately trying to prop up the cliff before it breaks off completely.
« Last Edit: April 06, 2023, 07:35:57 am by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4199
  • Country: us
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #40 on: April 06, 2023, 07:47:48 am »
Quote
Big mistake of Zilog to not bring out a Z80 based microcontroller.
They did, eventually.  The whole EZ80Acclaim series, apparently introduced in 2001.
But it was too little, too late.  Or perhaps too much, too late - the smallest current chip is a 100pin QFP for $10; I don't remember them ever doing a low pin count or low-priced uC, and those seem to have been what captured peoples' imaginations...


In the early days, companies without a flash process were at a significant disadvantage.  And Z80 programmers expected RAM-rich systems by then.
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 3240
  • Country: gb
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #41 on: April 06, 2023, 07:50:05 am »
Quote
AVR MCUs + avr-gcc is the best 8-bit development experience
how about 8051 with Keil (say, using the SiLabs advanced 8051 chips and their free version of the compiler/IDE)?
(Has someone used both enough to compare them?  I'm not interested in "8051 isn't really designed for use with C" arguments...)


Keil IDE and compiler have a good reputation, except for the price, and the SiLabs deal negates that...

The 8051 was the first microcontroller I ever used, though that was back when C compilers were available only to companies with deep pockets so it was assembler all the way.  The memory model of the 8051 architecture is rather awkward though (even compared to the 8 bit PICs) so I wouldn't say they are the ideal introduction to micros these days.  IME AVRs are in a different league in terms of ease of use for a noob.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13748
  • Country: gb
    • Mike's Electric Stuff
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #42 on: April 06, 2023, 07:51:47 am »
I have sort of got bogged down in PIC.
I have been programming then since mid 1980's.
I have so many projects I can draw on for functions like USB, FFT etc.
Why reinvent what I already have in abundance ?

The current chip shortage is a nuisance, I have to buy what Microchip have in stock then convert my code to that.
At least Microchip have had some stock of some parts through the shortage, whearas STM32 people have been mostly screwed.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13748
  • Country: gb
    • Mike's Electric Stuff
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #43 on: April 06, 2023, 07:54:39 am »
Quote
Big mistake of Zilog to not bring out a Z80 based microcontroller.
They did, eventually.  The whole EZ80Acclaim series, apparently introduced in 2001.
But it was too little, too late.  Or perhaps too much, too late - the smallest current chip is a 100pin QFP for $10; I don't remember them ever doing a low pin count or low-priced uC, and those seem to have been what captured peoples' imaginations...


In the early days, companies without a flash process were at a significant disadvantage.  And Z80 programmers expected RAM-rich systems by then.
Zilog did bring out a range of low-end MCUs, Z86 series, intended to compete with PIC16C5x - the pinout was compatible if you turned it upside down. ISTR it was used a lot for universe remote controls as they had licensed a library of IR codes.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4039
  • Country: nz
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #44 on: April 06, 2023, 08:23:13 am »
The memory model of the 8051 architecture is rather awkward though (even compared to the 8 bit PICs) so I wouldn't say they are the ideal introduction to micros these days.  IME AVRs are in a different league in terms of ease of use for a noob.

They are, though they are not without warts.

  • Only three pointer register pairs
  • weird register that must always be 0 -- except when a mul just overwrote it
  • limitations on registers for many instructions
  • different instructions to access data in flash (fixed on the latest ones I think?)

RISC-V has got 6800-level simplicity and orthogonality, but with registers to burn. RV32I is as sparse and easy to learn as any 8 bitter, and they now start from $0.10 (in qty 50) for a C-friendly, gdb-friendly, flash-based microcontroller (CH32V003).
 

Online Kleinstein

  • Super Contributor
  • ***
  • Posts: 14210
  • Country: de
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #45 on: April 06, 2023, 12:45:29 pm »
Most µC programming is today done in C or a similar languish. So the ASM details and memory layout does not matter that much, if there is a well working compiler.
The 8051 and PIC16 memory organization is a bit awkward and does not make it easy to the compiler, e.g. with larger structures in RAM.
In most areas the AVRs are easier, but they have the problem with seprate adress ranges for RAM and Flash, e.g. causing the separaet prog_mem pointers in GCC.
Making it easy for the compiler got them a relatively good GCC suport and this helped a lot.
AFAIK the is "fixed" to some degree with newer models (mapping some of the ROM to RAM space)

The NUL register with the AVR GCC is not a fault of the AVRs, but a fault if GCC's default register use, tha uses register 0 for the "fixed" 0 value - they should have changed this when the mega chips with HW muliplier came out. One could still change this , if one recompiles as the libraries.  Though late this could still be changed. The resoring of the zero value is handled by the compiler and the normal programmer does not have to care (maybe with inline ASM that used the MUL commands) - so I would consider this more like a missed optimization.

For a beginner the quality of the manuals / data-seets and the quality of the available tools is more important than the actual µC. With lacking of buggy decumentation or compiler a µC is pretty much useless.
 

Offline peter-h

  • Super Contributor
  • ***
  • Posts: 3700
  • Country: gb
  • Doing electronics since the 1960s...
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #46 on: April 06, 2023, 01:53:52 pm »
Quote
But it was too little, too late

Yes, in a world where most code (in that sector) was done in assembler, the mfg had to carve the market for any new CPU out of solid rock.

The small chips (of any mfg) are still mostly programmed in asm.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline voltsandjolts

  • Supporter
  • ****
  • Posts: 2300
  • Country: gb
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #47 on: April 06, 2023, 02:12:25 pm »
The 8051 and PIC16 memory organization is a bit awkward and does not make it easy to the compiler, e.g. with larger structures in RAM

The AVR memory layout is more pleasant to both the compiler and programmer.
Keil C51 is impressive and has extended 8051 architecture lifetime by decades, but data/idata/pdata/xdata qualifiers are a nuisance.
A linear RAM space is oh so nice.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13748
  • Country: gb
    • Mike's Electric Stuff
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #48 on: April 06, 2023, 02:53:16 pm »
Quote
The small chips (of any mfg) are still mostly programmed in asm.
I doubt that - it's perfectly feasible to (carefully) use C on tiny parts. I've done various designs with both application code and a bootloader on a 512-word 10F322, all in C

Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4199
  • Country: us
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #49 on: April 06, 2023, 05:19:28 pm »
Quote
Zilog did bring out a range of low-end MCUs, Z86 series
Those were Z8, not Z80, so they had no chance of winning the Z80-user market.


Quote
[AVR] are not without warts.
Only three pointer register pairs
Three pointers, four pairs for use with ADIW/SBIW instructions, and all 32 for MOVW.  Not all AVRs, BTW.

Quote
weird register that must always be 0 -- except when a mul just overwrote it
A compiler convention, not architecture.  avr-gcc chose R1 before there was a multiply instruction, which was a mistake. (RISC-V does something similar - An "always 0" register, right?  Although that IS at the ISA level, and doesn't have any weird exceptions.)
Quote
limitations on registers for many instructions
Mostly, the "immediate operand" instructions only work on the upper 16 registers (of 32 total.)
And the weird (newer) instructions like SPM, MUL, etc.
Quote
different instructions to access data in flash (fixed on the latest ones I think?)
only "fixed" on new chips with 48k or less of flash.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14482
  • Country: fr
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #50 on: April 06, 2023, 07:21:23 pm »
Big mistake of Zilog to not bring out a Z80 based microcontroller. They owned the world, and gave it away.

They did.
 

Offline peter-h

  • Super Contributor
  • ***
  • Posts: 3700
  • Country: gb
  • Doing electronics since the 1960s...
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #51 on: April 06, 2023, 07:23:46 pm »
I used the Z8 and Super-8 but the chips were not in production for long. Just a few years, IIRC.

I used the Z180, and the Hitachi 64180, but unless you count the 64180 with the huge ceramic windowed package, these were not standalone chips, needing ERPROM+RAM.

Same for the Z280. I was the first European production customer. Even wrote an RTOS for it.

Anyway, off topic :)
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14482
  • Country: fr
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #52 on: April 06, 2023, 07:32:30 pm »
The Z280 is an interesting beast! I dunno if you have the rights to publish your RTOS for it, but if so I bet that could interest a few people.
A few projects around it, like this: https://github.com/transistorfet/z280
Some seem to have gotten ahold of a few Z280's, although I'm not sure where to look. The Z180 is easier to find.

The eZ80 is still in production and still being used!
 

Offline peter-h

  • Super Contributor
  • ***
  • Posts: 3700
  • Country: gb
  • Doing electronics since the 1960s...
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #53 on: April 06, 2023, 09:34:33 pm »
My RTOS was very simple. A preemptive scheduler, with a system call to force a tick (for co-operative multitasking). No mutexes (it had a test and set instruction which is all you need), no queues, etc. It would meet with derisory comments here :) I can publish it; the company went bust in 1993 (I left in 1991).

I have some Z280s but in products which still run!

It was used with two EPROMs, 16 bit data bus, and had a burst mode where it would fetch four words rapidly. You used a 74S sync counter to drive the bottom two EPROM address lines. Used 50ns EPROMs. That product even had a token ring LAN, using a Z180 coprocessor and 85C30 SCC doing SDLC. 2mbps manchester MIL-STD-1553 based PHY. All in assembler, and no bugs :) No trace on the internet...

Z180, I have hundreds in stock and a product which still sells after 30 years. This is the old Z180; the later "improved" one has broken UARTs, IIRC. Zilog could never fix it so they sold the old silicon.
« Last Edit: April 06, 2023, 09:40:38 pm by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline 0xFFF0Topic starter

  • Regular Contributor
  • *
  • Posts: 87
  • Country: de
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #54 on: April 08, 2023, 02:34:13 pm »
What I noticed badly these days is that you can't fill the old PIC with c++. You have to buy new ones that will be recognized by the xc32. All sad.
 

Offline IDEngineer

  • Super Contributor
  • ***
  • Posts: 1926
  • Country: us
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #55 on: April 08, 2023, 10:20:49 pm »
Does a project with a PIC still make sense? I have the impression that the PICs are no longer properly supported. In comparison, there are 100x more code examples and projects with the new MCUs. Does a PIC still have an advantage?
I went through this exact decision process a few years ago. I'd been away from the microcontroller world for some time and didn't know what had become the ascendent chips in the meantime.

I researched all the major parts and their manufacturers. I'd never worked with Microchip before so they and their parts were completely new to me, and I had no bias for or against them. I called everyone's Applications Engineers and asked about their programmers/debuggers, their IDE's (if any), their compilers (including costs), etc. I read lots of spec sheets and became familiar with their CPU cores and their peripherals. I looked at major distributors to see whose parts were most commonly stocked in high volumes (of course, this was pre-COVID).

In the end I went with Microchip and we now buy tens of thousands of MCU's from them every year. They weren't a slam dunk in every area but overall they were the best choice and I've never regretted it since. We now use three of their MCU's across a variety of products.

Key factors for me:

* Incredible customer support. Their App Engineering staff was chatty and informative before I made the decision, and since then has been awesome when we've had questions. The single best customer support experience I've ever had, in any area of life, was with Microchip. I was having difficulty making one of their peripherals work and next thing I knew they had me on a conference call with 6-7 people including an App Engineer, a Silicon Engineer, Sales droid, somebody from management, and a couple of others. They spent most of an hour on this question and kept me on the phone until there was nothing more to discuss. The effective hourly burn rate on their end was amazing and this was for our very first product using their parts, which meant we weren't generating any revenue for them yet. I told them how impressed I was at the end of the phone call and one guy said "We never forget a huge amount of our business starts with small companies."

* Free toolchain, at least to get started (and free forever unless you need the highest levels of optimization). Hence zero risk to give them a try.

* Reasonable compilers. This can turn into a religious argument pretty fast, but the bottom line is that most MCU work these days is done in C/C++ and as along as the compiler isolates you from the core architecture, the oddities don't really matter much. It's true that the PIC family can have some weird internals but unless you drop into Assembly for some tight optimization you'll never really feel it. And most such Assembly will be for very tight code sections where you won't run into the oddities (like bank switching) very often anyway.

* Excellent peripherals. Overall they just work as you'd expect, and often include some little extras that others don't. Example: Their CCP's have modes that will measure duty cycle, or full period, entirely in hardware - something I expected to need to do manually. Microchip also has some rather unique peripherals (example: their CTMU) which can be surprisingly useful in unexpected ways.

* Wide range of packages. You can get MCU's with 6 pins, 100+ pins, and everything in between. Sometimes within the same family, in which case you can share an architecture and just pick the package based on how many pins you need for a given design.

* Decent range of operational choices. If you only need 1% clock accuracy many of their parts have laser calibrated internal oscillators so you don't need external timing components at all. If you need tighter than that, just slap down a crystal and a couple of caps and you can have whatever accuracy you wish to pay for. Both are possible with the same part, which drops the number of separate SKU's you need to stock.

* Availability, even during COVID. Yes, their parts were hard to find and often out of stock at distributors. But if you start buying direct via MicrochipDirect.com they will sometimes work miracles for you. There was an order mixup during COVID that was going to shut down our production line, and they found a whole reel of parts and shipped them to us at normal pricing. We had a LOT more trouble with a LOT of other manufacturers but Microchip has been there for us.

One more that deserves special mention: SPEC SHEETS. OMG, trying to decypher the spec sheets of some microcontrollers is a nightmare. Sections in the front would rely upon, but never mention, a minor sentence buried way in the back in a seemingly unrelated section. Language strangeness that leads you down rabbit holes of insanity. Just getting stuff to work at the most basic level was soooo frustrating. In contrast, Microchip's spec sheets are very clear. They read like they were written by native English speakers (no offense to anyone, but technical documentation does not benefit from multiple layers of translation). For the most part they are well organized and logical. Yes, they have a few hidden details that can require some sleuthing (example: pins that default to analog mode which is only documented in the A/D converter section) but far, far fewer than most others. I seldom have any difficulty finding what I'm looking for, and seldom have to go blindly chasing for some secret answer buried in an otherwise unrelated area of the docs.

Are their parts perfect? No. Nobody's are. But we've been happy with our decision. We've since looked at other parts and other manufacturers because they offer some seemingly key advantage, but generally we can't get past their spec sheets. The overhead just isn't worth what may, or may not, be an advantage. So we keep working with Microchip. They helped us get started, they've supported us along the way, they've kept parts flowing to us, all without ugly surprises.

Most comments are complaints, so I like to spread good news when I can. Hope this helps someone.
« Last Edit: April 08, 2023, 10:24:00 pm by IDEngineer »
 
The following users thanked this post: voltsandjolts, igendel, Ian.M, tooki, brichards42, FrancisM

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 3461
  • Country: it
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #56 on: April 08, 2023, 11:17:15 pm »
<the reality of things>

Thank you for getting it.
PIC vs anything else is perceived by the public as PIC16F84A vs anything made last year. FFS of course that pic is crap. That PIC was incredible in the 90s, when i was born. The world have moved on, microchip has too. But no, tutorials and everything are made for the 16F84A and the 16F876 to this day! I shit you not, in the last 18months there has been at least three threads in the microchip forum, by users based in india, that asked for info and assembly about those old POS parts because that's what they were allowed to use. Why, as here in the west one of those micro cost about 8€, whereas the newest part is more or less 1€?

Yes, if you CAN get a hold of of a FAE, they tend to employ excellent people. But it's getting really hard to talk with someone in engineering and not in sales :(
The compilers are excellent, if you know the architecture(s) they employ the quality of the generated code is excellent.

Well, not if you build shitty examples. I wonder if it's done on purpose but i once read somewhere that GCC for anything is really good at optimizing the code patterns that shitty programmers use for evaluating a processor, like an endless loop that toggles a pin, as if it indicates anything else than "the processor is working, the pinout definition is correct, and it's roughly being clocked at the target frequency.
Instead, XC8 and XC16 do an excellent job in producing and optimizing code for more complex statements, real world scenarios.

Any consideration about peripherals, accuracy i can just say, i agree. I don't really know of parts that are as easily flexible.

Microchip Docs? among the best out there. They are doing their best to ruin everything by copying the crappy atmel datasheet format, i wonder if atmel people were put in charge of datasheets. Still, tou can always find what you're looking for.

Availability, since 2020, the truth is, we had really two months of crisis in which parst should arrive anytime soon this week, but besides that i confirm the excellency of their service
 
The following users thanked this post: 8goran8

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3146
  • Country: ca
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #57 on: April 09, 2023, 02:25:29 am »
Key factors for me:

I would add periphery modules. They're now very flexible, interconnected, can trigger each other, so you can offload lots of work to periphery and it is done automatically without even using CPU.
 

Offline IDEngineer

  • Super Contributor
  • ***
  • Posts: 1926
  • Country: us
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #58 on: April 09, 2023, 03:15:13 am »
Yep! Hence my "Excellent peripherals" paragraph. And you're right about the interconnectedness... you can often set things up to be almost autonomous.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13748
  • Country: gb
    • Mike's Electric Stuff
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #59 on: April 09, 2023, 10:40:28 am »
One thing that IMO is under appreciated is Microchip's programming service. AFAIK no other manufacturer will supply ready-programmed parts in modest volumes with minimal setup costs ($29 setup and $60 min order value).  For smaller parts it's under 10 cents for programming, marking and re-reeling.
There are 3rd party services, but these are often too expensive to be useful, especially with the lower-end parts. I think Digikey offer programming but only to US customers due to them being paranoid that you'll be asking them to program export-controlled encryption in your SOT-23 PIC!
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7742
  • Country: ca
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #60 on: April 09, 2023, 10:55:38 am »
The Arduino environment is growing and growing with tons of example whereas the MPLAB is a very sad party. Microchip simply has very little to offer.
That's a professional commercial devices VS hobbyist everyday user toy argument.
If you do not want to write code, then go for Arduino.
If you do not want to know the hidden bugs because it is not your code base, then go for Arduino.

I have been contracted in the past to re-do projects with existing code.  It always comes down to throwing out all the old garbage wherever it came from and re-code everything from scratch in house.  If a problem occurs, we know exactly where to look and what to fix.

If you want the full speed of the processor, or ultra low power, it usually comes down to programming everything yourself anyways.
« Last Edit: April 09, 2023, 10:58:08 am by BrianHG »
 
The following users thanked this post: peter-h, SiliconWizard, Kim Christensen

Offline 0xFFF0Topic starter

  • Regular Contributor
  • *
  • Posts: 87
  • Country: de
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #61 on: April 10, 2023, 10:57:30 am »
I ported a project from PIC to ESP32 this week. The code size has almost halved. A lot of what you had to program with a lot of difficulty with MPLAB is already there in Arduino out of the box. There are libraries for almost everything.
 

Offline Kim Christensen

  • Super Contributor
  • ***
  • Posts: 1327
  • Country: ca
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #62 on: April 10, 2023, 04:04:03 pm »
The code size has almost halved.

Source code was halved?  :-DD
 

Offline IDEngineer

  • Super Contributor
  • ***
  • Posts: 1926
  • Country: us
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #63 on: April 10, 2023, 04:08:07 pm »
There are libraries for almost everything.
The same can be said of Python, but few are programming MCU's with that language.

Don't make this a religious argument. Pick what works for your project and move forward. There's no single correct answer that fits every circumstance.
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #64 on: April 11, 2023, 03:21:22 am »
I used the Z8 and Super-8 but the chips were not in production for long. Just a few years, IIRC.

I used the Z180, and the Hitachi 64180, but unless you count the 64180 with the huge ceramic windowed package, these were not standalone chips, needing ERPROM+RAM.

Same for the Z280. I was the first European production customer. Even wrote an RTOS for it.

Anyway, off topic :)

I bought a Z8 dev kit back when they were new and were on sale for around $10. I installed the included software and it totally borked my Windows installation to the point that I had to wipe and reinstall to get it to boot. I don't know how or why that happened but after that I never touched it again.
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #65 on: April 11, 2023, 03:24:28 am »
The Arduino environment is growing and growing with tons of example whereas the MPLAB is a very sad party. Microchip simply has very little to offer.
That's a professional commercial devices VS hobbyist everyday user toy argument.
If you do not want to write code, then go for Arduino.
If you do not want to know the hidden bugs because it is not your code base, then go for Arduino.

I have been contracted in the past to re-do projects with existing code.  It always comes down to throwing out all the old garbage wherever it came from and re-code everything from scratch in house.  If a problem occurs, we know exactly where to look and what to fix.

If you want the full speed of the processor, or ultra low power, it usually comes down to programming everything yourself anyways.

Arduino has a lot going for it, especially for a hobbyist platform, but the IDE, if you could even call it that, is pretty terrible and lacks any real debugging capabilities to speak of. It really doesn't even try to be a professional tool.
 

Offline 0xFFF0Topic starter

  • Regular Contributor
  • *
  • Posts: 87
  • Country: de
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #66 on: April 11, 2023, 11:38:57 am »
The new IDE 2.0 runs totally smooth and is sufficient. Even indexing is available for lightning-fast searching.
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #67 on: April 11, 2023, 11:32:54 pm »
It's sufficient for hobby work, and Arduino despite its warts really shines for that, there's no faster way I've ever found to throw together something that works, but it's a bit like building on perfboard vs designing a PCB in a professional CAD package. It's just not really cut out for professional production work, and I don't fault it for that, it isn't what it was ever designed for.
 

Offline IDEngineer

  • Super Contributor
  • ***
  • Posts: 1926
  • Country: us
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #68 on: April 11, 2023, 11:47:45 pm »
I agree but it's remarkable how many commercial products are shipping with hobbyist Arduino boards inside. I tend to look down at such "designs" but in all honesty they work, and they're shipping, so probably no worse than some blank-sheet designs out there.

Rough guess: I suspect ~50% of low end 3D printers are Arduino at heart.
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #69 on: April 12, 2023, 06:16:57 am »
I agree but it's remarkable how many commercial products are shipping with hobbyist Arduino boards inside. I tend to look down at such "designs" but in all honesty they work, and they're shipping, so probably no worse than some blank-sheet designs out there.

Rough guess: I suspect ~50% of low end 3D printers are Arduino at heart.

Using the Arduino bootloader and development is one thing, but there's no excuse for any sort of volume commercial product having an actual Arduino board inside it, that's just lazy.
 
The following users thanked this post: newbrain

Offline tooki

  • Super Contributor
  • ***
  • Posts: 11561
  • Country: ch
Re: PIC versus Atmel/ESP/STM/etc.
« Reply #70 on: April 12, 2023, 11:21:53 pm »
Arduino has a lot going for it, especially for a hobbyist platform, but the IDE, if you could even call it that, is pretty terrible and lacks any real debugging capabilities to speak of. It really doesn't even try to be a professional tool.
Well duh, of course not. Arduino is unabashedly designed and marketed for education and hobby use. Complaining that Arduino “doesn’t even try to be a professional tool” is like whining that Crayola doesn’t even try to sell gallery-quality oil paints!  :palm:

With that said, the Arduino IDE is an integrated development environment — barebones yes, but it is integrated and it does let you develop.

And FYI, Arduino IDE 2.0 does add debugging for some boards, along with code autocompletion and such. But it still can’t hold a candle to PlatformIO or Visual Micro.


And I’ll copy what I just wrote in another thread the other day:

Quote
Then your project will not have an Arduino bootloader and you will have to re-do all your Arduino work.


This is completely false.  The Arduino bootloaders are all completely separate and non-interacting with the user applications, whether they are "Arduino sketches" or programs written in some other development environment.  You can write Arduino sketches without using the bootloader (saves 0.5 to 8k of memory) (there's even an "upload using programmer" command), or you can use the Arduino bootloaders with non-Arduino applications.

The worst that is likely to happen is that for newer chips (ARM in particular), you may have to rebuild the application with a new segment start address for the vectors.  There are no run-time dependencies on the bootloader, and the bootloaders do their best to put the chip in a "just reset" state before starting the application.
I’ll add, because I have stated this elsewhere on the forum a few times and each time it comes as a surprise to some people:
“Arduino” really means three distinct big things:
1. Arduino-designed and branded MCU dev boards
2. The Arduino software framework, which provide easy-to-use wrappers for common functions and a few basic system functions like the millis() timer.
3. The Arduino IDE

These things are completely divisible, and you can use them in more or less any combination. (The only thing you can’t do, as far as I know, is use the Arduino IDE without using the Arduino framework, or with another programming language. Not that I see any reason you’d want to since the IDE is the least compelling part of the whole package!) You can use Arduino boards with other IDEs and languages. You can use third party boards within the Arduino IDE. You can use third party boards and another IDE, but use the Arduino framework (very common, for example programming the ESP32 with the Arduino framework with the PlatformIO IDE).

So you really can cherry-pick what you want out of the Arduino ecosystem. I’ll also add that while the Arduino framework provides wrappers for many functions, you don’t have to use them. For example, the digitalWrite() function is notoriously slow, but you are perfectly free to install an alternative library with faster IO, or write directly to the port registers. This means you can start programming with Arduino functions, and then progressively move away from them, since it’s basically C++ otherwise. It’s not an all-or-nothing situation like moving to a completely different platform.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf