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

0 Members and 1 Guest are viewing this topic.

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15270
  • 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: 4079
  • 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
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15270
  • 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: 4079
  • 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
 

Online 0xFFF0Topic starter

  • Regular Contributor
  • *
  • Posts: 105
  • 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: 1940
  • 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: 3523
  • 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: 3243
  • 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: 1940
  • 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: 13969
  • 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: 8083
  • 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

Online 0xFFF0Topic starter

  • Regular Contributor
  • *
  • Posts: 105
  • 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: 1686
  • 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: 1940
  • 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.
 

Online 0xFFF0Topic starter

  • Regular Contributor
  • *
  • Posts: 105
  • 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: 1940
  • 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

Online tooki

  • Super Contributor
  • ***
  • Posts: 12568
  • 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