Why do people not like Microchip? - Page 1
Forum section: electronics / general

author: Pineapple Dan
author_rank: Contributor
timestamp: July 22, 2021, 01:33:22 pm
content: Inspired by comments in the other thread I createdI have never really used any other MCU unless it came pre-packaged on another board (Arduino, pyBoard) but anything I designed the PCB for I have used PIC8 and PIC16. Not trying to start a flame war just interested to see what people don't like about them and what do they use instead.For me the biggest problem is how finnicky the ICD3 and Mplab have always been - ordered a Pickit 4 so hopefully this will be better. Just when I think i'm getting somewhere with a project I get random 'Transmission error on endpoint -2' messages, next thing the MCU has blown up, soldering on a new one has failed, rebooting yields new error messages and before I know it the PCB is completely shagged and I'm miles out at sea with no life jacket and a large shark fin circling around me.

author: ace1903
author_rank: Regular Contributor
timestamp: July 22, 2021, 02:09:04 pm
content: I miss good quality c compiler. Architecture of their 8 and 16bit micros does not allows efficient stack implementation.Compiler needs to be smart when needs to use 8 bit pointers and when 16 or 32 bit pointer.I am forced to use CCS compiler that is like a toy. They sell it without mentioning that does not support any C standard.If you have larger array of data trying to achieve atomic operation is mission impossible. They even not support PIC's built in instructions for efficient index operation.Never tried Microchip's XCC compiler. Would like to hear opinions.ICD4 is garbage and never tried Pickit4 although pickit3 is very stable.Debugging USB implementations is difficult without USB analyzer. Sometimes USB stack on pc side is in inconsistent state if device stops responding due to some breakpoint.Frequent PC restarts are required.My experience is that micros are well designed and stable. Only issue I had with them was that RC oscillator frequency was dependent on power supply voltage and temperature.Easily goes out of spec when both are changing.

author: woofy
author_rank: Frequent Contributor
timestamp: July 22, 2021, 04:17:49 pm
content: Why do people not like Microchip?Perhaps because people who are happy with Microchip just don't make a noise. For me, Microchip are the goto processor supplier. I'm reasonably familiar with the architecture and tools, so I select the lowest cost processor that gets the job done.I mostly use the XC compilers, so the architecture is irrelevant, either it gets the job done or it doesn't.

author: luiHS
author_rank: Frequent Contributor
timestamp: July 22, 2021, 04:47:36 pm
content: Expensive microcontrollers.Expensive evaluation boards.Expensive C compiler.Not compatible with other manufacturers.Just the opposite of ARM microcontrollers.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 22, 2021, 05:28:58 pm
content: I personally used to like Microchip. They had nice chips and were well positioned IMO. Pretty good documentation too. Until, I would say, about 10 years ago.At that point, I started to lose interest in their products. The offering for ARM-based MCUs (from very low power to pretty powerful stuff) literally exploded, and you could use 100% free and open-source tools with them. MPLAB X was also not really good news either for me. Not being able to use standard JTAG on most of their MCUs ended up sucking really bad too.Sure they now also have ARM-based MCUs with ATMEL, but that kind of was too late for me. They kind of missed the train with the PIC32 line. Don't get me wrong, it wasn't bad at all, but their venture with MIPS was eventually questionable, and the end result was less powerful and more power hungry than many other 32-bit MCUs from competitors.That said, even though I think it's not as good as it used to be, Microchip's documentation is still pretty good compared to many other vendors. Oh, and I rather liked the DMA in PIC32. Pretty cool.Another point is that if you stick to the 8-bit or 16-bit Microchip MCUs, they are much simpler than most 32-bit MCUs on the market, much easier to master, so that can be a real plus. I personally don't have a need for those anymore, but they are certainly still plenty usable in many applications.But really - as many others think too - the main issue is with their dev tools IMO at the moment.

author: SteveyG
author_rank: Unknown
timestamp: July 22, 2021, 05:36:42 pm
content: Microchip are great, especially when it comes to choosing a microcontroller for something that will hit production.Some people dislike using MPLAB, but again when it comes to needing a validated tool, this makes things easy.Also worth noting that Microchip have huge stores of bare die ICs for almost every PIC they have produced and can package these very quickly if there's ever a stock shortage.

author: bd139
author_rank: Super Contributor
timestamp: July 22, 2021, 06:03:24 pm
content: Microchip are really good until you read the errata. Oh whole I2C peripheral unusable? Oh.At least STM32 bugs are mysterious

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 22, 2021, 06:16:53 pm
content: Quote from: bd139 on July 22, 2021, 06:03:24 pmAh, I remember the I2C peripheral being completely non-functional on a PIC24F16KA102 I used for some project about 9 years ago. IIRC, I had to implement a bit-bang I2C. Funny.

author: jpanhalt
author_rank: Super Contributor
timestamp: July 22, 2021, 06:23:40 pm
content: Quote from: bd139 on July 22, 2021, 06:03:24 pmLike you say, the real datasheet is in two parts. The first part is how Microchip planned the chip. The second is what the chip is really like. I learned a long time ago to always check the errata. The good part is that as bugs get fixed, the errata is updated. That practice dates way back to its earliest chips, e.g, 16Cxx with interrupts.

author: bd139
author_rank: Super Contributor
timestamp: July 22, 2021, 06:43:19 pm
content: Quote from: SiliconWizard on July 22, 2021, 06:16:53 pmdsPIC33 too. Man I got angry with that one. Fortunately it was a personal project so it was canned.I picked up some AT89C2051 out of spite after that

author: janoc
author_rank: Super Contributor
timestamp: July 22, 2021, 07:53:44 pm
content: Quote from: bd139 on July 22, 2021, 06:43:19 pmDon't bash the AT89C2051! That was the first micro I have learned on, back in 1998 or so. Heck, made an ultrasonic 3D mouse with one of these and another one was meant to control a small mining locomotive instead of a huge metal box full of a Z80-based control system.Those things were surprisingly good, especially when compared to the EPROM-based '51s ...

author: bd139
author_rank: Super Contributor
timestamp: July 22, 2021, 08:01:25 pm
content: Oh yes 100% not knocking the things. I was merely saying fuck you to Microchip

author: lucazader
author_rank: Regular Contributor
timestamp: July 22, 2021, 08:24:16 pm
content: For me its mostly about the toolchain.Open toolchains that can be used with modern build systems, to allow ci and unit tests are a must.

author: bd139
author_rank: Super Contributor
timestamp: July 22, 2021, 08:26:18 pm
content: As someone who maintains modern CI systems, I’d rather use a shitty old tool chain at this point.I miss my entire build stack being make or a single cmd file on windows.

author: jenniferkim
author_rank: Contributor
timestamp: July 22, 2021, 08:44:13 pm
content: The main reason is their compiler ..... Their official compiler is MPLAB, which is so out of date.When I have to work on PIC Microcontroller, I normally use MikroC as it has built-in libraries plus examples.On the other hand, Arduino compiler is too user friendly, they have built awesome libraries, so programmingArduino Nanois way too easy.

author: nctnico
author_rank: Super Contributor
timestamp: July 22, 2021, 08:49:34 pm
content: Quote from: Pineapple Dan on July 22, 2021, 01:33:22 pmFor the 8 bit devices the banked memory is the major downside; you can't write normal C for it as you can for controllers which have a single memory space (and thus support pointers natively). Needing a proprietary C compiler is also a big downside. I've standarised on GCC for all microcontrollers I use so I can re-use code across various platforms using the same compiler specific extensions.But in general I consider every part from Microchip to be low quality & troublesome so I don't use anything from Microchip (including the formerly Atmel parts). The exception are the formerly Microsemi parts.

author: bd139
author_rank: Super Contributor
timestamp: July 22, 2021, 09:06:00 pm
content: Quote from: jenniferkim on July 22, 2021, 08:44:13 pmThe trick with the arduino is to steal the avr-gcc toolchain out of the IDE and use that with a half decent text editor instead.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 22, 2021, 09:29:28 pm
content: FYI, Code::Blocks is quite comfy, and easily set up for GCC on AVR, ARM, etc. I haven't used AVR Studio in ages, and good riddance (and never touched Arduino).If nothing else, resorting to Notepad++ or the like, is certainly an option, but you won't have project visibility, function prototypes, comments, etc. handy as you would in a proper IDE.Tim

author: westfw
author_rank: Super Contributor
timestamp: July 22, 2021, 10:32:37 pm
content: Well, first of all the 8-bit PIC architecture is UGLY by modern standards. It's designed to allow assembly language programmers to write very small programs that fit in the very small memory (it does that OK, and it was first, cheapest, and most readily available for a long time.) The ugly architecture means that HLLs are hard to write, which means that there are fewer of them, and they tend to be "expensive." (especially compared to the "free" gnu compiler(s) that many other CPU architectures support with "not much effort" on vendors' parts.)Hobbyists get misled by "projects" from the decade-or-so when the PIC16F84 was THE go-to choice, leading them down paths that are frustrating to watch.For the non-8bit-PIC architectures, Microchip flouts the spirit of OSSW by taking gcc and selling it, with a "free" version that removes some of the features that were present in the non-Microchip versions. They're slow to publish their source modifications (required by gpl license), and even slower at remaining current with the changes from FSF (Microchip avr-gcc is at 5.4, FSF avr-gcc is at 11.0)The choice of MIPS architecture (instead of ARM) for PIC32 is generally not well received.Microchip has been somewhat "greedy", corporate acquisition-wise. (I think they've done pretty well WRT continuing product lines/etc, but I'll bet there are some ZeroG and Roving customers that are less happy.)There are the usual bugs and sub-optimal behavior in hardware, software, library, and configuration tools. (Are there really any microcontroller vendors that are "well-liked" by everyone?)

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 22, 2021, 10:46:00 pm
content: Quote from: luiHS on July 22, 2021, 04:47:36 pmAre you serious? The CPU simply doesn't matter when you are writing C. It's ALL about the peripherals, and ARM manufacturers are as different from each other as they are with Microchip

author: jpanhalt
author_rank: Super Contributor
timestamp: July 22, 2021, 11:02:44 pm
content: Those who refer to RAM blocks have not used more recent 8-bit chips. All of the RAM is mapped to contiguous linear memory. If total ram is 4096 bytes, you can access all of it without changing Banks, if that is what you need (16-bit FSR is used). Ii addition, Common ram (usually at 0x070 to 0x7F (16 bytes)), which is accessible from any Bank, is still available. My current project uses that linear RAM for a FIFO cyclic buffer. Of course, you may also want to preserve Common RAM for other things, so you can still address user RAM in an appropriate Bank. For example, I use Bank 4 for some constants to refresh an SPI GLCD. That avoids Bank switching and does not use Common RAM.I code in Assembly, but I assume anything Assembly can do, C can also do.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 22, 2021, 11:28:13 pm
content: I think a lot of the anti-Microchip people are basing opinions on the older architectures and heresay.Everyone has different requirements. From my point of view, these are some of the reasons I like Microchip. I can't compare with others as I've yet to feel the need to look elsewhere.Availability - this has always been a strong point. While all the ST/NXP/whoever people are tearing their hair out right now trying to get parts, I can still get pretty much any PIC I need from Digikey. And if a particular part is thin on the ground, there's a very good chance there is either something pin-compatible that is available, or the same part in a different packageDevtools - maybe a bit controversial, and admittedly I don't do big projects, but the fact that I can use exactly the same IDEANDprogrammer , with the same ISP header, for everything from a 6-pin PIC10F to a 200MHz PIC32MZ part saves me a ton of learning time.The fact that the whole IDE and toolchain is well integrated means that where needed, I can give a customer my project directory, tell them to install MPLABX, buy a Pickit 3, and they can be up and running in 10 minutes.One instance I recall this being invaluable was when a customer with zero MCU knowledge wanted to be able to create different LED brightness curve lookup tables.Similarity of peripherals across the range - again, from an 8 bit to a 32 bit part, a lot of the peripherals (and peripheral register names) are either exactly the same, or similar enough that there is minimal learning curve. On the larger parts with more complex peripherals, they tend to default to working the same way as the lower-end ones until you explicitly configure them otherwise.Even stuff like self-programming for bootloaders is very similar across the whole range.Pin mapping flexibility - this varies across the range, but in most cases there is enough flexibility in mapping pins and/or choice of multiple peripherals (UART1 vs. UART2 etc) that PCB layout is greatly simplified.Package flexibility. Most parts from 8 bit to 32 but have a choice of 3 or 4 packages - DIP,SO,SSOP, DFN/QFB, QFP. Yes, 32 bit parts in DIP or a 20 pin SSOP or QFN20. In many cases a wide range of pin counts for the same basic part.Pre-programming - MicrochipDirect will preprogram , mark and re-reel PIC10s for about 4 cents, with about 1 week leadtime and negligible setup cost. PIC32s from memory about 30c. AFAIK no other manufacturer offers this, and third-party programming services can cost more then the chips. Digikey has a programming service but only for US customers. Pickit 3's programmer-to-go functionality is also extremely useful for production by subcontractors - just send them a pre-loaded programmer, and all they need to do is connect and press a button.Alternatively I can easily talk them through setting up a pickit 3 themselves.MIPs vs. ARM is simply not an issue when everything is in C.Yes the 8-bit architecture sucks, but C hides most of it well enough to rarely be a problem. I've done projects with application and a serial bootloader in the 512 words of a PIC10F, all in C.

author: AaronLee
author_rank: Regular Contributor
timestamp: July 23, 2021, 01:08:49 am
content: Quote from: SteveyG on July 22, 2021, 05:36:42 pmThe availability issue is the primary reason I (ie. my customers) keep using Microchip. I much prefer to develop for ARM MCUs, but with decades of experience with Microchip, I can bang out a project very quickly, the customer typically doesn't need to worry about part availability, and even though Microchip cost/performance ratio isn't very good, my customers know it'll work and be reliable, and they don't really want to change. Just last week I had a project where once again the customer wanted to use a Microchip, and a part number which I've done dozens of projects for. I just copied various sections of code from previous projects, added the appropriate new code, compiled right off without any errors and ran on the target without any bugs / need for debugging. Took all of 30 minutes to do. The customer was very impressed, and it made me feel very good that it was one of those rare occasions where everything just worked exactly right the very first time.

author: AaronLee
author_rank: Regular Contributor
timestamp: July 23, 2021, 01:14:48 am
content: Quote from: bd139 on July 22, 2021, 06:03:24 pmYup, the old I2C completely unusable issue. For most of my projects, speedy operation isn't necessary, so I just start out with using my bit-bang I2C library. Only if the bit-bang speed isn't sufficient do I change to hardware I2C, and of course in that case must select a part which has working I2c. With lots of I2C devices in some projects, and for various reasons we don't want to share the same I2C bus, often I don't have sufficient I2C ports anyways, so bit-banging is a must. The same for SPI.

author: AaronLee
author_rank: Regular Contributor
timestamp: July 23, 2021, 01:27:25 am
content: Quote from: jenniferkim on July 22, 2021, 08:44:13 pmHaving a MCU and environment that is "way too easy" is fine for some quick hobbyist project. But for most professional projects I do, it likely wouldn't work. Admittedly, I've only used an Arduino a few times for a quick and easy personal project where I based it off of an existing public domain design, so I don't have lots of experience. But in general, when it comes down to professional projects, there's very often some key issue that requires tweaking things in ways that standard libraries can't handle, and which takes time to get it right. That's not to say I want to waste time with poorly designed tools and libraries, which is a problem with Microchip. But I definitely don't want a MCU where I'm required to use "high level" "easy to use" stuff that ultimately never allows me to do exactly what I want to do. And Microchip Harmony is probably the worst offender of all. I hate that piece of turd Harmony. Other MCU vendors though are also gravitating towards similar approaches. I prefer to hand code definitions for each of the pins I'm using, manually initialize each pin/port, and just do everything at a low level, often with my own library of drivers, not even touching the vendor's libraries, other than sometimes for MCU initialization. If my goal though was just as a hobbyist or someone designing really basic/simple projects, I'd likely see things differently.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 23, 2021, 03:49:52 am
content: I like Microchip.MCUs are good. Periphery is good. Documentation is Ok - better than most. Microchipdirect is good. Compilers are fine.Of course, there are things I don't like, such as MPLAB X. I don't like that they bought Atmel. If they didn't, I believe the PIC line would progress more and everything would be less messy.

author: peter-h
author_rank: Super Contributor
timestamp: July 23, 2021, 11:13:32 am
content: Microchip bought the Hitech compiler, probably when Clyde Smith-Stubbs (who wrote all their compilers - Z80, H8/332, etc) retired.Isn't this the compiler they are selling?

author: JPortici
author_rank: Super Contributor
timestamp: July 23, 2021, 11:27:53 am
content: XC8 is the hitech compiler (their own was discontinued)XC16 and XC32 are C30 and C32 respectivelyQuote from: NorthGuy on July 23, 2021, 03:49:52 amsame. But i insist that MPLABX is not the worst of the free IDEs

author: bd139
author_rank: Super Contributor
timestamp: July 23, 2021, 11:34:40 am
content: MPLABX is based on netbeans which is basically someone trying to fix the sins of eclipse and only succeeding in creating another Cthulhu shaped monster to terrorise you.My only comment is at least it’s not visual studio.I prefer standalone tools than IDEs these days. Many times I’ve been let down by IDEs right in the middle of shit hitting the fan moments. My entire day job is high profile shit hitting the fan moments so I can’t afford the risk.

author: Warhawk
author_rank: Frequent Contributor
timestamp: July 23, 2021, 11:52:32 am
content: Microchip is OK. I miss a free and open-source compiler. I like 5-V support and packages that always fit the requirements.Every micro has its own quirks. I find people complaining about this or that MCU annoying. Professionals take what they are given, learn architecture and quirks and do the job. During my career, I've seen real issues just a few times. Most of the other problems were just lazy coders, bad habits, wrong MCU selection, or wrong software architecture.Yes, bugs are present. I am not aware of a single MCU without errata.

author: snarkysparky
author_rank: Frequent Contributor
timestamp: July 23, 2021, 12:18:25 pm
content: Why people bring up the old 8 bit pics is beyond me. The PIC24 series is awesome. Flat memory and hardware multiply. What's not to like.

author: Circlotron
author_rank: Super Contributor
timestamp: July 23, 2021, 12:40:02 pm
content: Quote from: westfw on July 22, 2021, 10:32:37 pmMy language of choice (and the only one I understand) is assembly, and trying to figure out PIC assembly is a deal breaker for me. Yeah, I know, I'm stuck in the 80s, but the only thing that makes sense to me is HC08 and S08 assembly and it does exactly what I need to make a living.

author: Bud
author_rank: Super Contributor
timestamp: July 23, 2021, 12:55:58 pm
content: Quote from: snarkysparky on July 23, 2021, 12:18:25 pmHorses for courses. There are a lot of small tasks 8 bit microcontrollers will do perfectly. I do not need hardware multiply to i initialize a DDS or scan a keypad.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 23, 2021, 12:57:42 pm
content: Quote from: snarkysparky on July 23, 2021, 12:18:25 pmYes, PIC24 is pretty nice, but higher cost, and no 5V operation.I like the 16F15xxx 8-bit parts - two UARTS,CLC, NCO, four PWMs, fully pin-mappable,plenty of RAM and cheap

author: bd139
author_rank: Super Contributor
timestamp: July 23, 2021, 01:22:06 pm
content: Regarding the old 8 bit PICs, as much as I bitch a lot, I rather like the PIC10F320. There's a lot of power in a SOT23! Saves pissing around with individual gates/logic ICs.

author: bhave
author_rank: Contributor
timestamp: July 23, 2021, 01:36:20 pm
content: I think people that complain have not used the newer stuff Microchip has developed in the last few years. The dsPIC C and CH series just flat out perform. The newer 8-bit PIC16 and PIC18 series have fixed quite a few of the old memory issues and offer some really nice peripherals. The way you can remap pins makes development so much easier and allows lots of flexibility when designing a board for future expansion.Ultimately, I jump between various brands and models of MCUs based on peripherals, packaging, price, and availability. The architecture is way down my list when choosing something. When I am working on something that requires expanded temperature ranges or certain certifications, my choice is more limited and Microchip almost always has an offering.

author: hans
author_rank: Super Contributor
timestamp: July 23, 2021, 02:56:28 pm
content: I like the 16-bit PICs as well. That architecture is C-compiler sanity proof, while still low level enough to work directly with the I/O space.I don't use the 8-bit PICs extensively anymore. Only if I need some simple if-this-then-that functionality that doesn't require processing lots of data.I don't really like MPLABX or the XC compilers. MPLABX feels so sluggish and buggy. XC compilers are based on GCC but also locked down and often out of date. But.. it does work, is easy to install on Windows/Linux/Mac, and a single cable to a PICKIT 3 has one up and running with hundreds of parts in 1 click.It's completely beyond me why a powerful architecture like the 16-bit PICs does not have a C++ compiler. You can even get dual-core 90-100MIPS 16-bit PICs right now with 64kB+ RAM. That's "more MCU" than you get with a jellybean STM32..I like the PIC32 scheme. The PIC32MX was my first step into 32-bit MCUs, and I like the simplicity of it's peripherals while still offering reasonable amount of horsepower at the same time. I've yet to try the PIC32MZ (I still need to order a mockup devboard to use the samples I've got laying around..), but it seems like a very capable part.I'm not really familiar with the Atmel 32-bit ARM parts. Their part catalog's naming scheme is completely beyond me. But I've seen some neat parts in there..So I'm as mixed on Microchip as I'm on any other MCU manufacturer. I jump around a lot between manufacturers, but I also like to reuse common code between my projects. That makes standardized/open tools like GCC a must, and I think that's something where Microchip can improve. I don't understand why Microchip wants to earn money in toolchain sales; for what overall benefit?

author: peter-h
author_rank: Super Contributor
timestamp: July 23, 2021, 04:09:05 pm
content: I have a production design using the old Atmel 90S1200. Bought a big load on the last time buy, £0.50 each. Still have some left, then will have to redesign. Did a redesign using the 2313 and Atmel dropped it by the time I finishedI see they still do the ATtiny2313A and maybe they will still make it by the time I get around to itThe price is in the right ballpark but only for the square-package one - ATTINY2313A-MU. The rest all cost a lot more and are sold out.The code just reads a dipswitch and loads a timer with a value based on that.There are loads of applications for these little micros, 50 pence in volume. The learning curve is not big either, and the assembler runs (or used to run; not looked at the 2313 setup) in a DOS box, out of a simple batch file.Never used any of the "real Microchip" stuff. But I do remember the original "PIC" from the 1970s, made by General Instrument, which was called AY-something and had a totally bizzare instruction set. They sold millions of masked ROM versions.

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 23, 2021, 04:32:49 pm
content: What do you mean by "like Microchip"?I use lots of Microchip products, and like them. (I do have both originally Atmel parts, as well as originally Microchip parts, that I like.)I dislike Microchip the company, because of their business practices. As a hobbyist, I don't like how they need to make profit on every single aspect. I know perfectly well why they do that, and how it makes sound business sense for them. I just don't like it personally; I have no interest in being that sort of a customer. (The situation would be different if I made commercial projects, of course.)I especially don't like how they used calculated legal subterfuge for years to keep their customers unaware of their rights with respect to their GPL-licensed compilers. Even today, some still insist –– incorrectly! –– that their customers do not have the right to remove the artificial limitations or license checks from the GCC-derived compiler. (They do have that right. Any license or agreement that forbids that between Microchip and the customer would void Microchips' own rights to redistribute the parts that they didn't own copyrights to.) GPL is a simple license, and having FUD spread about it is annoying.(Once again: No, I am not a GPL zealot. Tux is my mascot, not my idol. Licenses are just another tool, and I happily use both proprietary and copyleft licensing, whatever makes most sense in a given particular situation. My beef wrt. GPL is that it is a simple tool that is being twisted to look like something it is not. That affects things I've licensed under GPL, and I don't like that at all. Any kind of widespread license misunderstanding annoys me the same way.)I like the fact that Microchip is moving to LLVM/Clang, because now they don't need to spread FUD to bolster their bottom line. The license –– Apache License 2.0 with LLVM exceptions –– is much more suitable for their business model, and there is a good possibility both Microchip and their customers will benefit.Atmel was a company whounderstoodhow to leverage open source software properly. I was sad to see it bought by Microchip, because Microchip definitely does not.Companies like Atmel are relatively rare. I've been looking into Chinese Rockchip recently; they too seem to get it right, including pushing support directly upstream into the vanilla Linux kernel by actual paid engineers. Similarly for ARM (the company), although the Nvidia acquisition is likely to change that much more drastically than the Microchip acquisition of Atmel, because Nvidia is still actively hostile to anything open source, and is more likely to use their acquisition to restrict competition than bring anything useful or worthwhile to their customers, when considering Nvidia's past business practices.So, "not like Microchip" can have many different reasons, and it does not exclude liking their products. Moreover, Microchip having nice products does not mean you cannot dislike their business practices or the company as a whole due to their behaviour. My own opinions are subject to change if my own needs change. Finally, there is no reason to be extreme, and claim people dislike Microchip for the wrong reasons, because these are just opinions. The interesting bit, really, is thereasonsbehind those opinions.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 23, 2021, 04:56:56 pm
content: Quote from: bhave on July 23, 2021, 01:36:20 pmWith that sentence, you're like putting all points in the same basket, while there are various reasons that have been exposed. The dev tools are definitely one.Then, fitness of products for given applications is all really dependent on everyone's environment and projects. Myself, except for the temperature range which is mentioned below, Microchip MCUs in general just have not much to offer compared to other vendors I've picked lately. But that's just my own consideration.As to erratas, I confirmed the I2C issue on some PICs, but to be honest, apart from this, I have not been bothered that much by Microchip erratas compared to other vendors. They are not particularly worse in general.Quote from: bhave on July 23, 2021, 01:36:20 pmYes, that's one reason for using Microchip parts these days. I've used a PIC24F with 150°C operating temp in a project that would require working properly and over a long period of time at temperatures up to about 140°C. Not a lot of corresponding offers from competitors, or sometimes at unacceptable prices.

author: woofy
author_rank: Frequent Contributor
timestamp: July 23, 2021, 05:01:24 pm
content: Quote from: peter-h on July 23, 2021, 04:09:05 pmDo you have any more info on that?As far as I'm aware, the first PIC was the PIC1650 series which ranged from the 18 pin PIC1645 (256 bytes of ROM) to the 40 pin PIC1650 (512 bytes ROM).I know they made quite a few AY series chips from sound generators to pong games, but I've never heard of an AY series processor and a quick google didn't reveal anything.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 23, 2021, 05:08:10 pm
content: Quote from: Nominal Animal on July 23, 2021, 04:32:49 pmTo be honest, I've used Microchip MCUs in the past both in professional settings and as a hobbyist. I never really found Microchip was difficult to deal with as a hobbyist. Their MCUs were always fairly priced, the doc was good, and the dev tools could be had basically for free for hobbyist use. So nothing really problematic here.Quote from: Nominal Animal on July 23, 2021, 04:32:49 pmSure, what they did with GCC is pretty odd, and more than questionable. Not completely sure how they managed to get away with this from a legal POV, but I'm sure they have a bunch of lawyers.I'm not against the fact a given company charges for dev tools (that might be something that could drive me away if I'm using products as a hobbyist, but otherwise, it's fine.) Doing this licensing thing would have been "fine" if they had developed (or acquired) their own compilers. But doing this from a GPL compiler is, certainly, just plain wrong.Now in theory, they are not doing anything fully wrong either, I guess: they have released source code, and - already disscussed - even though their compilers are a bit annoying to build compared to vanilla GCC, that's still doable, and any company can charge money off open-source stuff. I agree the gray area here is that they were never clear regarding using compilers built from source, but nothing can prevent anyone from doing so. It IS open source! In the end, thinking about it, Microchip has a right to sell XC compilers even if it's open source. Crippling them with license checks is questionable though, but I guess this is the only way they found for enforcing buying them. The more reasonable approach, as any other company would do with open source software, would have been to distribute their compilers built from source without any license checking, and sell customers support for those willing to have support. That's usually how you deal with open source software as a commercial company.

author: oPossum
author_rank: Super Contributor
timestamp: July 23, 2021, 05:44:35 pm
content: Quote from: woofy on July 23, 2021, 05:01:24 pmThe first PIC (Programmable Intelligent Computer) was the PIC1650. The 16C54/55/56/57 where the next generation of PIC and featured OTP PROM rather than mask ROM of the the PIC1650.

author: woofy
author_rank: Frequent Contributor
timestamp: July 23, 2021, 06:21:26 pm
content: Quote from: oPossum on July 23, 2021, 05:44:35 pmThat's what I thought too. Peter-h may have been thinking of the CP1600 series, a 16-bit CPU used in the Intellivision games controller. That's the only other GI series I know of.

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 23, 2021, 08:19:06 pm
content: Quote from: SiliconWizard on July 23, 2021, 05:08:10 pmWell put. As a hobbyist, I don't like it. If I were doing commercial stuff, it would not bother me at all to pay for dev tools. (I have,lots, in the past, when I ran a software company. When doing business, it is not a good idea to be thrifty when it comes to tools.)With LLVM/Clang, the licensing is clear, and matches the business pattern well. It does not preclude Microchip from also pushing support to open-source toolchains (consider e.g. the Arduino/PlatformIO environment). Also, since they now really do control their own toolchain, they won't need to try and use the Hardware Abstraction Libraries for customer retention; those devs can concentrate on making the libraries better, instead of deliberately trying to keep things non-portable. Might affect documentation, too: some companies have drifted a bit towards documenting their hardware through their HAL, which I definitely don't like.Quote from: SiliconWizard on July 23, 2021, 05:08:10 pmYes, I agree. Selling GPL-licensed software is absolutely fine. You just cannot restrict the rights granted by GPL without violating the GPL license itself. (Selling custom software to an organization using the GPL license is often an excellent choice for both: the organization can develop it further with anyone they choose, but cannot really develop it into a product they'd sell as a commercial product, except under the GPL license itself. If you do customization and integration for a specific type of business, it is a pattern worth considering.)My objection was mainly how they let especially their user forums propagate the lie that removing the license restrictions would violate copyrights or Microchip EULA.At the core, I dislike companies conflating things theywishfrom their customers, and things they canrequirefrom their customers by law/statute/license.It can sound petty/useless since it is rather common nowadays, but it is my opinion, based on my personal experiences.

author: DavidAlfa
author_rank: Super Contributor
timestamp: July 23, 2021, 11:21:14 pm
content: When you went with low end models, you had a lot of drawbacks. But you get used to them.If you wanted power, the dspic33s were beasts. 40 MIPS, mostly single-cycle instructions, 48KB ram in a 28PDIP... crazy and expensive!The harward architecture has its benefits. ARM core can only access the work registers, so first it needs to load the address, fetch the data and then work with it, while pics usually can address anything, ignoring the bank selection thing.For example, toggling a GPIO:- PIC, clear/set/toggle RA3: bcf/bsf/btg LATA,3- ARM: Load address of GPIOA->ODR into the register (pointer)Get the valueModify the bit(I barely know any thumb/arm asm, but I guess it uses a OR/AND/XOR mask, so at least another 2 instructions)Write back the new modified data using the already set pointerBut also arm is pipelined, so the real behavior is different.The xc8 compiler works pretty well. Last time I checked the disassembly, the optized code was really good.But I also remember manually adding assembly instructions in a pic24 because mplabc c16 (Now xc16) didn't use the hw div instructions.About the peripherals... Some were really buggy. But also stm32 has some serious issues. Even the newest ones.So it seems there's crap everywhere. I'm starting to think there's no mcu on earth that works like in the papers.Lots will require reset and initialization when something goes wrong."Use the enable/disable bit to reset the spi peripheral"- Best joke of the last 20 years!I don't hate pics, but they got really old once the arm came into the game.Never understood why there isn't GCC for them. AVR is pretty similar and has been supported since long time ago.

author: bhave
author_rank: Contributor
timestamp: July 24, 2021, 12:59:55 am
content: Quote from: SiliconWizard on July 23, 2021, 04:56:56 pmI guess that was an unfair overgeneralization. The dev tools are what I consider about average. I find Mplab X no better or worse than the many other iterations of vendor supplied development studios over the years. I have certainly dealt with plenty of bugs in Code Composer Studio (before and after Eclipse), Keil, IAR Workbench, the ST program of the month, MCUXpresso, ... etc.The Microchip compilers are what they are and work fine. The fact they are functional safety qualified is nice and the pain of going through that is probably why they charge for premium versions of what is otherwise a free compiler.Ultimately, I have a collection of development tools and invariably choose the MCU that meets the needs of a project based on functionality rather than brand. I like having someone to call when something does not work properly and really just want to install tools, get the project working, and move on to the next.I originally commented on this because I find Microchip MCUs fine and never understand the hatred toward them. Like any other tool, there are suitable uses for them and uses that are not suitable.

author: JPortici
author_rank: Super Contributor
timestamp: July 24, 2021, 05:31:33 am
content: Quote from: bd139 on July 23, 2021, 11:34:40 amalways to the point

author: JPortici
author_rank: Super Contributor
timestamp: July 24, 2021, 05:52:06 am
content: I have to say i also don't agree with their business practises, but microchip is a company that MUST be profitable at every quarter. Good for current investors, good for parts availability, bad in the long run for innovationST for example on OTOH is more focused on innovation and long term returns, thats what enabled them to come up with just stupidly powerful automotive components, like their cortex R with hardware virtualization for high performance ECUsAnyway, AFAIU in the current state of things, here's what you get with the compiler license:- The Highest degree of optimization, as up to -O2 is free for every compiler (the engineering team fought like beasts to get -O2 from the beancounters. They are currently fighting for freeing all optimizations), i'm okay with this as O2 is already hard enough to debug/inspect. Sounds good to me- Support. Nobody can argue against paid support- The functional safety versions, which are the same as the current version but verified against whatever standard then you get the required documentation and support. Again, nobody can honestly argue about this- Propietary tools like code coverage or profiling tools, they are proprietary so they can do whatever they want.XC8 is not GCC because at the time HiTech made the best compiler for 8bit PIC (that produced the overall best code, even though it never supported the extended instruction set for PIC18) and the Hitech Compiler was not based on GCC. No point in throwing away decades of good product for the sake of open source.And please, nobody start with the bullshit about XC8 adding intentional bloat in free mode. That has been discussed to death. loading "1" and adding with carry instead of using the INC instruction for char++ is just the generic approach that was not optimized due to a bug, it was corrected. Unnecessary bank selection is also the generic approach that was not optimized due to a bug, it was corrected. Whenever something very very very stupid happens in a new update for the compilers is a bug. not a way to screw you free folk. report it and see that it's fixed in a hurry.

author: westfw
author_rank: Super Contributor
timestamp: July 24, 2021, 09:37:28 am
content: QuoteXC8 is not GCC because there is no gcc for 8bit PICs, and essentially CAN NOT be a gcc for 8 bit PICS because the PIC architecture is too far away from what GCC thinks a CPU should look like.

author: IDEngineer
author_rank: Super Contributor
timestamp: July 24, 2021, 04:50:52 pm
content: My $0.02....Long ago I stopped worrying about the ultra-fine details of compilers, linkers, IDE's, etc. While those are interesting mental exercises (and I AM very interested and those topics DO have a lot of merit) I am not paid to write and maintain the toolchain. I get paid when my designs and my products are delivered and meet spec.I like Microchip. A lot. While their parts aren't always bleeding edge, they do what they say in predictable ways. That means a lot in the real world of delivering solutions. Are there other choices? Sure. Better choices for a given design? Perhaps. But their parts are generally available and stocked by multiple distributors (today's nonsense notwithstanding) and Microchip Direct will sell them straight to you if desired. Their documentation is better than most, you can give your customers debuggers (PICkits) for free to help them help you remotely, and frankly the ICD3 has been bombproof for me (I've avoided the ICD4 since the ICD3 has no problems I'm need to fix).I've also never, EVER had any other company support me like Microchip. Two examples:1) A few years ago I was having problems with one of their on-MCU peripherals. I posted the question to their support forums, and next thing I knew their Engineering staff had scheduled a conference call with me. When they called, there was half a dozen Microchip staff on the call, everything from digital guys to analog guys to MCU guys. Oh yeah, and one sales guy who barely spoke. They spent a solid 30-45 minutes with me grinding through the issue. When it was all over I openly thanked them for the incredible support, especially since we're a rather small customer for them. They asked "how many devices do you buy from us annually?" and I estimated 10K. They responded "Our business is based on smaller customers, 10K is plenty of quantity, and emphasis on smaller customers comes straight from the top of our company". No other company has even hinted at such an attitude, let alone acted on it the way they have.2) Just a week ago I was helping one of our Contract Manufacturers (CM) search for parts in today's craziness. Turned out they had placed an order with Microchip Direct (MCD) for some PIC18's we use and after the order was accepted, it came back with a change saying the delivery date was pushed out almost a year (!!!). I found an compatible alternative on MCD (different temp range, but still a different part number so the CM wouldn't substitute without our approval) and started a chat session with MCD to make absolutely certain they wouldn't pull the same trick on this order. The MCD rep was surprised I would ask such a question, which led to me explaining how they'd pulled a bait-and-switch on our CM with the delivery date. It took a few hours but the representative not only guaranteed they'd ship the new order immediately, but also took the time to go back and fix the previous order so it would ship immediately too! In today's market you know they could just ship their parts to the next buyer... but she admitted this was a clerical error and took the time to correct a small order for a small customer (it was only one reel of parts). Again, no other vendor has ever stepped up like that for us.Nobody's parts nor tools are perfect, but Microchip is a pretty darned good mix of everything backed by great people with an awesome attitude. Speaking of that: I once ran into a guy at a local pizza place who was wearing a Microchip dress shirt. WTH, I live in a rather small town in North Idaho! So I approached him, and he turned out to be head of their Analog division in Arizona. Incredibly nice guy, and despite being there with his wife on vacation he sat and talked with me for quite a while on an array of topics. In other words, yet another example of the great people who work for that company.As I said, just my two cents. I felt I had to share when the title of the thread started with "Why do people not like Microchip?" Normally all you hear are complaints about companies and people, so I wanted to offset that with my own positive experiences. YMMV.EDIT: Two more thoughts occurred to me after I wrote this:1) I've personally found the PIC lineup to have a convenient mix of on-chip peripherals. There are still a couple of combinations they don't offer which would have made MY life a bit easier, but generally speaking for most designs I've been able to avoid implementing separate peripherals connected by SPI/I2C because what I need is already in the package.2) Their support of us when we were only buying ~10K pieces annually has resulted in us buying a LOT more than that these days. We're still small by most standards but if 10K is important enough to them to be noticed, we're probably in the "middle school" range now! That's the sort of "pay it forward" support that helps the small customers become larger. And we remember who helped us.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 24, 2021, 05:03:24 pm
content: Quote from: westfw on July 24, 2021, 09:37:28 amThere isn't a GCC for 8-bit targets AFAIK, except one: avr-gcc. It is GCC-based and officially supported by the GCC team.https://gcc.gnu.org/wiki/avr-gccSo I guess some people used to AVR are probably wondering why the hell Microchip didn't go the same route. Now, I admit not knowing much about avr-gcc, but I'm pretty sure this was hard work and hard to maintain, so I don't blame whoever wouldn't want to go through this same mess. As to architecture, I admit I don't know the AVR architecture enough to judge how much easier it was than with the PIC, but certainly all the oddities of the 8-bit PICs were much more severe.SDCC is a possible option as a compiler for 8-bit targets. It supports a range of processors, including Microchip PIC ones. Support is still not perfect though, as far as I've seen. I've used it for 8051-based MCUs, and it was fine. But people using 8-bit PICs and absolutely willing to use an open-source compiler can certainly have a look at SDCC.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 24, 2021, 05:13:42 pm
content: Quote from: bhave on July 24, 2021, 12:59:55 amOh, then I see your point. But as you asked for opinions, it was still interesting to see various points of view.You're right though. Not *all* people have had a perfectly rational reason for not willing to use Microchip MCUs, and for a fraction of them, there seems to be some kind of ideological disdain. I remember, almost 20 years ago (already!), one very experienced engineer in my team was always telling how PIC MCUs were just crap toys for hobbyists and how he would reject using them in any new design. Back then I eventually used one in a project that he was not involved in, and it turned out great. The guy stopped talking about Microchip after this.So from what I remember, many people tended to consider PIC MCUs like toyish MCUs back in the days, a couple decades ago. It's funny to see that now, many people consider PIC MCUs to be no good for hobbyists.

author: DavidAlfa
author_rank: Super Contributor
timestamp: July 24, 2021, 06:19:43 pm
content: Being easy to develop for has nothing to do with the real life performance or capabilities of a mcu. In fact, I wouldn't call it "for hobbists" or toy-like, like I'd do with arduino for example.To program a pic you had to completeley understand how the hardware worked, the memory mapping, registerss... Although that changed a little in the recent years with Harmony stuff.And there was no C until Hi-Tech came around. So if a amateur could program them and make useful stuff, an experienced enginner would squeeze them easily.I still remember a crazy guy who implemented a HID usb protocol in a 16F84, all bit-banged, slightly overclocking it to 24MHz. (Spanish)https://web.archive.org/web/20130320144542/http://www.telefonica.net/web2/hidlcdAlso this one did something similar with an AtTinyhttps://www.modding.kh.ua/a/IgorPlug-USB_(AVR)_eng.htmSo when someone says "8-bits are toys", it looks more like they lazy engineers. There are really smart projects out there.

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 24, 2021, 06:24:24 pm
content: Quote from: SiliconWizard on July 24, 2021, 05:03:24 pmThat's exactly why I wroteAtmelknew how to do open source right: itcontributed the support to gcc. There wereseveralAtmel employees contributing to GCC at the time.Of course, Microchip did buy Atmel in the end, so one could say itdid notwork out that well for them. Yet, we probably would not have Arduino without Atmel, as Arduino developers have said that the choice was due to Atmel providing free development tools.

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 24, 2021, 06:37:14 pm
content: Quote from: DavidAlfa on July 24, 2021, 06:19:43 pmI have a few DigiSpark clones, similar toAdafruit Trinkets. They have an 8-bit ATtiny85 that bit-bangs the USB 1.1, based on theV-USB(github) USB bit-banging library for AVRs.There are some USB 3 hosts that don't support USB 1.1 devices anymore, so my advice is to use an USB 2.0 wire hub (the kind with multiple connectors on one end) with these.

author: JOEBOBSICLE
author_rank: Regular Contributor
timestamp: July 24, 2021, 07:12:09 pm
content: I do hope they discontinue the MIPS products and switch over to cortex m for everything.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 24, 2021, 07:48:38 pm
content: Quote from: JOEBOBSICLE on July 24, 2021, 07:12:09 pmBoth are long-pipelined load-and-store architectures. What difference does it make?

author: nctnico
author_rank: Super Contributor
timestamp: July 24, 2021, 08:04:56 pm
content: Quote from: NorthGuy on July 24, 2021, 07:48:38 pmFor Cortex-M you can use the ARM supported GCC compiler or Clang/llvm and don't have to depend on a Microchip provided compiler. A lot more development is done on ARM compilers compared to MIPS anyway.

author: JOEBOBSICLE
author_rank: Regular Contributor
timestamp: July 24, 2021, 08:29:45 pm
content: Quote from: nctnico on July 24, 2021, 08:04:56 pmI have also found compiler bugs with xc32, I trust it a lot less than arm GCC which has a lot more engineers working on it. You can also use Rust very easily.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 24, 2021, 08:46:52 pm
content: Quote from: nctnico on July 24, 2021, 08:04:56 pmSo what? GCC had support for MIPS since last millenium. Not to mention GCC is hugely overdeveloped already. At any rate, it'll be all RISC-V soon, it's time to forget about ARM, isn't it?

author: DavidAlfa
author_rank: Super Contributor
timestamp: July 24, 2021, 09:17:35 pm
content: What? xc32 is based on gccUse any compiler, but definitely xc32 is more optimized for pic32.Same as gcc arm and "gnu tools for stm32" (st's patched and optimized gcc-based compiler). The latter produces more compact code using the same optimization.

author: JPortici
author_rank: Super Contributor
timestamp: July 24, 2021, 09:31:01 pm
content: Quote from: IDEngineer on July 24, 2021, 04:50:52 pmcare to give the link to the thread? just curious.in the past there were more MHCP engineers active on the forum. The last to leave was george, basically the guy in charge of the simulator (better than most i had to try i have to say) - or the guy resposible to the public for the simulator, which is to me the same thing -Quotewish i had the same response. the last few years i had a sales droid ask me that BEFORE receiving support. to hell i'm going to answer. i'm reporting issues that exist regardless of the amount of chips that i buy.QuoteThe only thing i know that remotely resembles microchip direct is TI's store, and they have a long way to climb

author: JPortici
author_rank: Super Contributor
timestamp: July 24, 2021, 09:33:50 pm
content: Quote from: SiliconWizard on July 24, 2021, 05:03:24 pmborrowing BD139's tone, I only have one finger to give to SDCC. Worst compiler i've ever ever have to deal with. I'd rather write assembly

author: JPortici
author_rank: Super Contributor
timestamp: July 24, 2021, 09:38:54 pm
content: Quote from: DavidAlfa on July 24, 2021, 06:19:43 pmwhat?long before MCC/Harmony we had PLIB for peripherals and MLA for USB/Ethernet stacks.Though "we" never really cared for those, datasheet has always been enough for anything that wasn't PIC32MZ/MK.

author: IDEngineer
author_rank: Super Contributor
timestamp: July 24, 2021, 09:46:13 pm
content: Quote from: JPortici on July 24, 2021, 09:31:01 pmThis was years ago, like perhaps 2016. Doubt I could find the question on the forums anymore. I'm sure things have changed since, but still... that's the best support I've ever received from any chip company except one time back in the 80's when National Semiconductor flew an Applications Engineer to our facility to help debug one of their early video opamps. That was a seriously fun time, our heads down over the breadboard, which was dead-bug style on copper clad laminate, him on the (wired landline!) phone arguing with the chip's designers back in Cupertino(?).Maybe things have changed with Microchip support since then, but still - credit where it's due. It can't be worse than Bosch Sensortec today, which a while back claimed they were changing their ticket system to "start a thread and we'll respond" to now just the accepted fact that nobody will ever contact you unless you say something disparaging about their company, in which case they accuse of you of "spreading lies" (nevermind the facts you're quoting are visible on the website for all to confirm independently).

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 24, 2021, 10:33:16 pm
content: Quote from: SiliconWizard on July 24, 2021, 05:03:24 pmAVR is, for the most part: 32 CPU registers, flat address space, memory-mapped IO registers, reasonably orthogonal load-store (RISC) architecture, hardware multiply, and most instructions single cycle. Stack is traditional (stack pointer into RAM, PUSH and POP instructions).Oddities include: Harvard architecture (Flash constants accessible by LPM instruction, using PROGMEM and related macros in C); some CPU registers in IO space (flags, stack pointer, some other things); paged memory when extended (effectively, CPU registers have an extra up-to-8 bits section located in IO space, e.g. X pointer (actually r27:r26) extended by RAMPX; this only matters on the larger Flash or RAM devices, or the A-series (fully loaded) devices with external bus interface); interrupts only push address and since flags are in IO there's a whole dance to PUSH it and other important registers (this isn't so unusual really, but different from some that do automatically like x86); and probably more things that aren't immediately coming to mind. Inorthogonal instructions are mainly the more extended instructions that therefore have fewer operands available, e.g. FMULS and stuff (fixed-point multiply, one for each combination of signs, plus the regular MULs). Some operands are implicit, e.g. MULs return output in r1:r0, or the DES crypto instruction using r0-r15; there is a 16-bit reg-reg move which only works on even alignments of course; and most immediate operands only work with r16-r31 destinations. Oh, and instructions are up to 2 arguments, Intel style.So, overall, pretty easy to compile for. Most of the quirks are handled by instruction assignment (a less efficient alternative may be used depending on register allocations) and linker scripts (memory spaces, because of course EEPROM, Flash and RAM all start at their own respective zeroes*).*On XMEGA and AVR0 (new ATmegas), EEPROM can be memory-mapped at a fixed offset. Though I don't know if the libraries make use of this, or the old method (through the NVM controller).The main downside is, generated code has gottenworsesince GCC 4 or so. The optimizer seems to be a bit neglected. I found about a 2x improvement going from -O3 functions to assembler functions on my reverb effect project (at least as of GCC 8.1.0), enough savings that the effect went from a barely usable 2 reverb taps and 1 biquad filter, to 6 taps and 2 filters with about two taps worth of CPU to spare.But as capability goes, that's a full software DSP effect at 25kS/s, using a simplified mechanism (single delay line with taps, not a proper all-pass), internal 12-bit ADC, external 12-bit DAC, and external RAM (bit-banged). Not bad for an 8-bit machine running at 32MHz.Tim

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 24, 2021, 10:36:15 pm
content: OK I see. Certainly a lot easier to deal with than the 8-bit PIC architecture, at least when porting an existing compiler.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 24, 2021, 10:51:11 pm
content: Quote from: JOEBOBSICLE on July 24, 2021, 08:29:45 pmXC32 now supports ARM for SAM parts which Microchip renamed to PIC32C. Do you think this makes it bug free?GCC had support for both ARM and MIPS long before first PIC32 was created. Microchip added very little of PIC32-specific stuff. Both ARM and MIPS appeared long time ago, were meant for PC, but failed. There's no reason to believe that ARM or MIPS implementation in somewhat inferior.

author: nctnico
author_rank: Super Contributor
timestamp: July 25, 2021, 08:45:11 am
content: Quote from: NorthGuy on July 24, 2021, 10:51:11 pmIt is not about when support was created, but what has happened in the mean time in terms of improvements & bug fixing.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 25, 2021, 03:08:29 pm
content: Quote from: nctnico on July 25, 2021, 08:45:11 amI used GCC for various platforms since long time ago. I haven't found any of them particularly buggy.The recent development may create more bugs than it fixes. Such are times.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 25, 2021, 03:58:11 pm
content: Quote from: NorthGuy on July 25, 2021, 03:08:29 pmWell, indeed.Sure a widely-used target (such as ARM) will generate a lot more traction. But that doesn't necessarily mean you'll get fewer bugs in the end. Because sure there are more chances bugs will be found and reported, but also a lot more chances target-specific modifications will be made and introduce new bugs. So...As for me, the last annoying bug I ran into with GCC was an optimization bug on ARM64.To get an idea, just take a look at the list of regression bugs for GCC for various targets. If you think most are with the least-used targets, you might be wrong.

author: Bassman59
author_rank: Super Contributor
timestamp: July 26, 2021, 04:57:25 am
content: Quote from: IDEngineer on July 24, 2021, 04:50:52 pmWhen Microchip bought Microsemi, my only thought was "I really hope they improve Microsemi's dreadful FPGA support." So far, no, but I have hope.

author: TomS_
author_rank: Frequent Contributor
timestamp: July 26, 2021, 07:15:29 am
content: Quote from: mikeselectricstuff on July 23, 2021, 12:57:42 pmPIC24FV are 5V.

author: eurofox
author_rank: Unknown
timestamp: July 26, 2021, 07:46:30 am
content: For "small" projects I used in the past Pic Basic Pro compiler from Melabs (https://melabs.com) and Microcode Studio Plus (https://www.mecanique.co.uk/shop/index.php?route=product/category&path=20)Just check it out, easy to learn, powerfull and well documented.

author: SteveyG
author_rank: Unknown
timestamp: July 26, 2021, 09:00:26 am
content: Quote from: TomS_ on July 26, 2021, 07:15:29 amThere's also the dsPIC30 with the wider voltage range, though it's an older design.

author: tszaboo
author_rank: Super Contributor
timestamp: July 26, 2021, 09:42:45 am
content: First microcontroller I ever programmed was Microchip. PIC16F84, programmed in assembly. This was before I went to university, in high school.It was the most accessible the tool cost was like 30 EUR, so I could pick it up with some pocket money and blink LEDs, do analog to digital converter stuff. It was before Arduino, before Cortex M3. The Mplab studio was self contained and it was relatively easy to start a project.Fast forward a few years, I was programming them for a living.ARM came, and indeed changed everything.So no, I don't dislike Microchip. I don't really use them nowadays. Well, Atmel is technically Microchip now.And yes they are expensive, somewhat oldschool, MplabX was quite bad in the beginning and I never bothered to check it out later.And the Errata is sometimes longer than the Datasheet.But I can still buy that 16F84 in DIP package today. I think it is OK to be different, we need diversity of strategies.

author: chickenHeadKnob
author_rank: Super Contributor
timestamp: July 26, 2021, 09:43:28 am
content: Quote from: SiliconWizard on July 24, 2021, 05:03:24 pmAtmel specifically designed the AVR for C.Quote from an Atmel research whitepaper:High level languages (HLLs) are rapidly becoming the standard programming methodology for embedded microcontrollers(MCUs), even for smaller 8-bit devices. The C language is probably the most widely used HLLin MCUs, but will in most applications give an increased code size compared to assembly programming. ATMEL identified the need of an architecture developed specially for the C language in order to reduce this overhead to a minimum. The result is the ATMEL AVR MCU,that in addition to the optimized code size, is a true single cycle RISC (Reduced Instruction Set Computer) machine with 32 general purpose registers (accumulators)http://www.compass-lab.com/pdf/AVR_RISC.pdfthere was another whitepaper comparing the AVR to the 8051 which Atmel also produced showing how the AVR was a better C target yet required the same or similar silicon area.You think I could find the originals on the MicroChip website but that defeated my search-fu patience. Internets bit rot.

author: JPortici
author_rank: Super Contributor
timestamp: July 26, 2021, 10:22:24 am
content: Quote from: SteveyG on July 26, 2021, 09:00:26 amAs is the PIC24FV. I would bet that both were deliberately omittedthe dsPIC33EV though..

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 26, 2021, 10:46:57 am
content: OK, "mostly no 5V" - according to Digikey 6.1% of PIC24s can do 5v

author: EEVblog
author_rank: Unknown
timestamp: July 26, 2021, 11:56:14 am
content: Quote from: Pineapple Dan on July 22, 2021, 01:33:22 pmOften depends on the era you were bought up in.If it's post Arduino then the majority will have been exposed to and used AVR, especially in the maker community.Before Arduino in the hobby realm it was mostly Microchip, as they were were one of the first really affordable hobbyist micro's, and the first IIRC to be electrically reprogrammble (EEPROM before Flash). PIC were shipping in the billions before AVR first came along.If you were exposed to micros in a work environment then you might have had the high priced development tools so might have used Motorola or TI or someone else.People take for granted sub $10 development boards and free software, but before PIC and reprogability came along, it cost an absolute fortune for a dev kit and parts were OTP so development was expensive.

author: IDEngineer
author_rank: Super Contributor
timestamp: July 26, 2021, 02:00:42 pm
content: Ah, the good old days of Intel ICE's ($20K+ back when that was real money!), UV erasers for EEPROM's, etc. Young players today have no idea how good they have it. They can get started with embedded work for well under $100 and the laptop they already have!

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 26, 2021, 03:24:38 pm
content: Quote from: EEVblog on July 26, 2021, 11:56:14 amThe thing that PIC really revolutionised was the use of OTP for small-volume production, with the 16C5x and 7x series, before the C84 reprogrammable devices. This enabled single-chip designs at much smaller volumes than masked parts, and coupled with their willingness to support small volume users meant that for a while they were pretty much the only option in that area.Prior to that, the only non-mask options were external EPROMs on an 8031 or very expensive onboard EPROMs on 8751 type parts, the latter being primarily aimed at prototyping before masking on the likes of the 8051. The only alternative I recall at the time was the Philips 87C751 EPROM and OTP parts.Another interesting product at the time was the Basic Stamp, which used an OTP PIC to interpred code stored i an external EEPROM - this was the Arduino of its time ( and is still available, neary 20 years later!).ISTR it took a good few years for Atmel to gain ground, and more years before C programming was common on either.

author: woofy
author_rank: Frequent Contributor
timestamp: July 26, 2021, 04:09:03 pm
content: There were ROMless and EPROM variants of those early PICs. The PIC1665 was ROMless and had address and data lines brought out.Also there were EPROM versions of the PIC16C54 and PIC16C55, I have some from an ancient devkit.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 26, 2021, 05:08:51 pm
content: Quote from: EEVblog on July 26, 2021, 11:56:14 amBut there was this interesting era around maybe 1998-2005, pre-Arduino, when AVR gained quite remarkable market share among hobbyists, and did thatquickly.Having born in 1985, I happened to get into microcontrollers just at the early stage of this era, maybe 1998-99 or so. AVR was "brand new" and clearly a competitor and alternative to the "old" classic PIC every hobbyist had been using for a decade or longer. But still it was already just mature enough for people to be able to recommend it, give advice and so on. It was some poster in a Finnish Usenet newsgroup (where I posted extremely stupid and embarrassing beginner questions, good times) who suggested the AVR for me, so I really never did touch a PIC. Maybe if I was just one year earlier to get into MCUs, it would have definitely been PICs.Around 2005-2006 when Arduino was just around the corner, everyone was using AVR controllers at the electronics club in Uni I attended.Clearly it was such AVR hobbyists that gave birth to the Arduino as well, less than a decade after the "AVR semi-revolution" started.And, the AVR CPU architecture is excellent, compared to PIC. C programmability is excellent, having GCC ported from the beginning was one of the key strong points.It's just that in the real world, peripherals and documentation matter much more than the core. PICs are completely fine in this regard, possibly better than AVRs when it comes to some specialized needs of peripherals. Professionals especially are used to accepting closed tools, and "crappy" CPU core is a non-issue for 99.9% of microcontroller use cases (peripherals do the heavy lifting anyway), besides, if raw CPU performance is needed, neither AVR nor PIC is the solution.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 26, 2021, 05:32:09 pm
content: I agree with Dave here, and @Siwastaja: it looks a bit like you're "embellishing" the whole AVR story a bit here.But one thing for sure - at least from my experience, and that corresponds to what Dave also said, is that 1/ it probably depends a bit on the part of the world you were at the time, and 2/ mostly, the exact time period!As Dave and I said, Microchip MCUs became extremely popular in the late 90's-early 2000's, particularly among hobbyists. I absolutely do remember that students started to come up with AVR-based designs (I remember interns and fresh engineers) around 2004-2005. It's think that's the approximate time period when AVR became popular in universities indeed. So for anyone older than this - but not as old as, as I mentioned earlier, sort of "despising" Microchip for the exact reason that it looked too hobbyish for serious work - you would have been exposed to, used and liked Microchip PICs.It's almost all a matter of date. Depending on what age you were between 2000 and 2005, it would with a high certainty imply whether you would be more in the "PIC" team or in the "AVR" team. I think Dave must be approx. the same age as I.As to Arduino and hobbyists, I don't know for sure the whole story, but I think you're over-emphasizing the "revolution" here. From the little I know, it's just a matter of a couple guys having this idea of a simple-to-use development environment, and they probably had the age and experience which matched what I said above: they were "AVR guys". I'm not sure they did this because AVR was so popular at the time. They did it because AVR was a decent architecture, the parts were cheap and easy to get, the dev tools were good (without GCC, and notably without a C++ compiler, Arduino wouild have not existed as it is.) Oh, and from what I remember, by the time Arduino became *really* popular, the AVR parts were already pretty old stuff.Just a few thoughts.

author: rcbuck
author_rank: Frequent Contributor
timestamp: July 26, 2021, 06:01:08 pm
content: The first reprogrammable part I remember using was the Motorola MC68HC705P3. I first used it in 1991. I don't know if the PICs had EEPROM parts at that time or not.The 705 was a strange animal and somewhat expensive. You had to first write the code and burn it to a 27256 EEPROM. You then built a programmer with a socket for the 27256 and the MC68HC705P3 and a couple of 74HC753 buffers. You plugged the 705 and 27256 into the sockets, powered the programmer up, and pressed the program button. There was a red and green LED on the programmer. After the programmer finished programming the 705 if the green LED came on you were good to go. If the red LED came on you had to figure out what went wrong. Red usually meant there was a problem with the timing. Even though the programmer was crystal controlled there was a warning in the data book that programming had to be done at room temperature.I'm glad those good old days are gone.

author: nctnico
author_rank: Super Contributor
timestamp: July 26, 2021, 06:06:32 pm
content: I'm wondering why people aren't bringing up Motorola's 68HC11. Also has internal EEPROM and was easy to program. AFAIK this one was also popular in the mid 90's. In the end there is a whole flurry of microcontrollers out there which where popular in some crowds. It is not just PIC or AVR.

author: rsjsouza
author_rank: Super Contributor
timestamp: July 26, 2021, 06:17:31 pm
content: Quote from: mikeselectricstuff on July 26, 2021, 03:24:38 pmI am not entirely surely what is the timeframe you are referring and that may depend on the place but, from my recollection, Brasil in late 80s and early 90s had 8051 reigning supreme, followed by HC05 and HC11 for more serious applications (HC08 was never much popular here) and a COP8 here and there (already with OTP variants). My internship in '93 had 80C51FA/FB/FC all around (all EPROM) and Atmel's 8051 variants were a distant second. Microchip was just showing up on the horizon and started becoming popular in mid 90's, together with the new AVR.Quote from: mikeselectricstuff on July 26, 2021, 03:24:38 pmBasic Stamp was becoming quite popular at the time as well, but import tariffs blocked many from purchasing cheap kits.

author: iMo
author_rank: Super Contributor
timestamp: July 26, 2021, 06:56:57 pm
content: I messed with re-programmable (on-chip eeprom) i8748 in mid eighties..Bought my Basic Stamp 1 (the smallest one) in 1997/8 (around 100Euro in today's money)Worked with pic12/16/18/24/dspic33/32mx/32mz and I do like MCHP. Around the end of millennia the best C I had handy for pic12/16 was the CC5x (still sold by Knudsen Data).Arduino movement gathered its momentum because they took atmega8 - with its architecture specifically designed for C compilers, a "single clock" at 20MHz and with 5V I/O - better suited for homebrewers, imho.At that time the pic16Fxxx and pic18Fxxx were slower, with small sram and not C optimized. The pic24F and dspic33 (ie. in DIL28 - 16bitters, 8/16kB sram, 12bit adc/dac, 128kB flash, 40-50mips) were way better than the atmegas deployed in arduinos, but they came a bit later and with 3.3V I/O and perhaps more expensive. Also not sure free C compilers were available for pic24/dspic33 at that time..

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 26, 2021, 07:29:04 pm
content: Quote from: imo on July 26, 2021, 06:56:57 pmThere were third-party C compilers for the 16F series, but I've never used them (just tried, but it wasn't worth it.) But those 16F parts had pretty small memory anyway (except for the bigger 16F877 AFAIR, but it was still pretty small), so using C didn't make a lot of sense anyway. I programmed them in assembly and it wasn't all that bad. The banks were annoying but just something you'd get used to (just required some planning), and the assembly was easy to master.Then the 18F series appeared, with a hardware multiplier, more memory and better performance. Microchip had their own compiler at this point, called MCC18. I only ever used C on the 18F series, and it worked absolutely great. I frankly couldn't care less whether the architecture was really adapted to C or not, it just worked.I can't tell if the AVR MCUs of the time were indeed more powerful than the PIC18F series or not. But the 18F were certainly pretty capable 8-bitters, with a nice set of peripherals.Quote from: imo on July 26, 2021, 06:56:57 pmAnd you're missing a major step. The dsPIC line started with the dsPIC30F series, which had a wide Vdd range of 2.5 V to 5.5 V (so perfectly usable in a pure 5 V system), and were a lot more powerful than ATMEGA stuff. The Microchip C compiler was MCC30. I don't quite remember if it was really available for free or not, but I can tell you for sure that you could use it 100% free with no nasty hack involved. (When Microchip introduced the XC line of compilers, there was a free version - with limited optimizations - available right from the start, but I don't remember their policy for MCC18 and MCC30.)As to this 5 V thing, this was largely completely idiotic, but out of habit, I remember that as a hobbyist, I was also a bit afraid of switching to the 3.3 V world for some reason. That was more than 20 years ago. It turned out there was absolutely no rational reason for this.But unless it's a specific requirement for some environment - which is almost never the case as a hobbyist, unless maybe you're designing vintage electronics, there's absolutely no reason to stick to 5 V logic these days. This fear of "lower than 5 V", that, as I said, I admit having as well at some point in the past, is hard to understand in hindsight even 20 years ago, but in 2021, hello? It's completely irrational.

author: bson
author_rank: Unknown
timestamp: July 26, 2021, 07:45:47 pm
content: I don't like architecture lock-in. I've worked on way too many large assembly projects in the 80s to ever make that mistake again - too much good code simply abandoned. If it doesn't come with or support a half decent C compiler, then I don't use it. If the architecture doesn't have a flat address space and isn't friendly to anything this side of Fortran, then I avoid it. And that's pretty much it. With MSP430 there's no reason to bother with PICs; they run the same code as ARM, which makes it very easy to reuse tried and true code. If you've already debugged say a ring buffer implementation, or freelisting, or bit field operations, or... many other useful things, and write even somewhat portable POSIX code, then it's a snap to reuse on a different processor - and it will work just as well there. On a PIC however, the code emitted will look like something the cat dragged in.

author: iMo
author_rank: Super Contributor
timestamp: July 26, 2021, 07:48:21 pm
content: Quote from: SiliconWizard on July 26, 2021, 07:29:04 pmYep, I skipped the dspic30 family, never worked with it, too power hungry afaik, I jumped over to dspic33..Btw, the CC5x compiler is still one of the best for pic16, imho, I think there is the pic16 version free now. As I can remember I did a lot of projects with it without a problem, switching the sram banks is done by the compiler, indeedIt includes 16/24/32bit floating point lib, afaik, with all usual transcendental functions.. And the complete 32bit fp math fits into a 16f88..

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: July 26, 2021, 11:29:58 pm
content: My MCU experience is divided between hobby and commercial use.For hobby purposes I only use 32-bit MCUs. All of my projects are one-offs, so there's no point in using an 8-bit or 16-bit micro just to save a few bucks. In many cases, a 32-bit MCU is complete overkill, but so what? I'm not one of those guys who enjoys making things work with the bare minimum of resources--quite the opposite in fact--I prefer to not have to worry about running out of RAM or FLASH, or any other resource.I use both ARM Cortex-M and PIC32 parts in projects and often alternate between them just for variety. I don't find one significantly better than the other in core features or peripherals. I think the ARM architecture is more modern than MIPS, but I have no particular beefs with the MIPS architecture either. In fact, MIPS is simpler and isn't constantly being enhanced with new stuff, like TrustZone, which I don't need anyway. My particular interest is in RTOS's, and I've written one for personal use that runs on either Cortex-M or PIC32 and I didn't find one architecture to be easier or harder than the other to implement an RTOS on (but 99% of any RTOS is written in C anyway). One area where PIC32 can't compete with ARM is CPU clock rate. PIC32MZ is stuck at 252 MHz, whereas Cortex-M7 parts are available at >500 MHz.PIC32 peripherals are generally simpler than those on most Cortex-M MCUs, but they get the job done. My only real beef with PIC32 MCU peripherals is that the built-in RTC doesn't have a battery-backed power domain and most of my PIC32 designs therefore require an external RTC part. ARM peripherals are all over the map with every manufacturer doing things differently.As far as tools go, I think both options are comparable. Eclipse (which is what most MCU manufacturers base their tools on) and MPLAB-X are similar enough that I rarely notice the difference. MPLAB-X performance has never been an issue on the development machine I use. I use workarounds to get around the XC32 optimization issue, but optimization is rarely an issue for my projects because I'm not right at the bleeding edge of performance anyway. I've never been a big fan of Eclipse, so for ARM I prefer to use either Rowley CrossWorks (or its free-for-non-commercial-use clone Segger Embedded Studio). I do prefer J-Links over the ICD3 or ICD4, but either works well enough for me. I consider the PICKit3 to be unusably slow, especially on PIC32s with lots of FLASH.Quality MCU documentation is very important to me, and I find Microchip documentation to be generally better than just about anyone else's.On the commercial side, it's strictly Cortex-M for me.

author: AaronLee
author_rank: Regular Contributor
timestamp: July 27, 2021, 12:15:27 am
content: Quote from: EEVblog on July 26, 2021, 11:56:14 amThe other thing was for mass market products, even with the flash MCUs, they were too expensive per part compared to masked parts. I was deep into developing products at that time, with the expensive development tools, plus the stress of needing to get the firmware 100% perfect. If not, you just trashed a huge amount of money for masking 10k or more parts which then just had to be thrown out. At the time I was using exclusively Japanese masked MCUs, due to the nature of the products being produced, and the Japanese MCUs having specific devices targeting that use. When I first saw them introduce flash devices, but at 10x the cost of the masked devices, I started dreaming of the day when they'd be equal or at least similar in price, and we could switch to the flash versions, and dramatically reduce the stresses of developing firmware that was 100% perfect the first time. I remember inheriting a project that another engineer did and got fired over having a bug in the masked MCU which wasn't discovered until after production was finished and the customer tested a unit. At the time the Microchip flash devices were new, I think, and we ended up making a small PCB with a tiny Microchip in between the the regular MCU and the rest of the board to patch the bug. We spent several days straight cutting the lines on the existing board and wiring in the patch board to fix the bug. While sometimes I reminisce about the old days, and how thrilling and exciting it was to be a part of the industry at that time, I certainly never miss the masked MCUs.

author: asmi
author_rank: Super Contributor
timestamp: July 27, 2021, 12:48:37 am
content: Quote from: DavidAlfa on July 23, 2021, 11:21:14 pmAll ARM MCUs I've ever used have dedicated set/reset/toggle registers for MMIO, so you can do either of those operations atomically and without a need of reading the value first - for example, if you want to set some bits high, you write a mask (it will have "1" in those bit positions which you want to set high) into "set" register, and HW will ensure those bits will be set. The same for reset and toggle.

author: AaronLee
author_rank: Regular Contributor
timestamp: July 27, 2021, 12:58:37 am
content: Quote from: Sal Ammoniac on July 26, 2021, 11:29:58 pmGlad to see someone else picked up on that. Yep, Rowley CrossWorks / Segger Embedded Studio with a Segger J-Link for ARM stuff. Designed by a real developer, and it totally shows.I really don't understand what the attraction is to Eclipse, other than it's free. In my opinion, the person who designed it was either an idiot or never used an IDE before. Coming from the Windows world, Alt-F then C has been the standard for ages to close the current file you're editing, but in Eclipse it closes the project. STUPID!!!! If you can't make your application conform to the standard it's running on, then don't design it, PERIOD! And for common tasks that are done repeatedly and constantly during development, there should be default keyboard shortcuts. All the building and standard debugging functions need keyboard shortcuts. Even if you can add them, the fact that they're absent by default to me indicates the designer knows nothing about development. And Eclipse is just way too slow. It seems to have improved recently, perhaps just due to running higher spec'd hardware, or maybe they've made some changes. But years ago I found it impossible to edit in the IDE at all, due to the slow speed.I've been using Visual Studio forever, and even the predecessor Visual C back in the DOS days. While it might not be the best, it's very speedy, and it's what I prefer. So still today, if I'm forced to use Eclipse due to it being what the MCU manufacturer chose for their development environment, I only use it for building/downloading/debugging, and use Visual Studio for editing.For me, an IDE is all about quickly getting through the editing, building, debugging cycle. Quick speedy operation and 100% keyboard usage only (no need to remove hands to use the mouse) where one cycle can be completed in a matter of seconds (for simple matters), not minutes. This cycle is repeated hundreds of times in a day for a developer like me, and really needs to be thoughtfully optimized, not just some horrible kludge that Eclipse is.Sorry for the Eclipse rant, but for the life of me I cannot understand how it ever got to the position it's in today.

author: all_repair
author_rank: Frequent Contributor
timestamp: July 27, 2021, 01:20:24 am
content: Trump-like banning their use.

author: AaronLee
author_rank: Regular Contributor
timestamp: July 27, 2021, 01:21:29 am
content: Quote from: Sal Ammoniac on July 26, 2021, 11:29:58 pmExcept that they still (last time I checked) give example code in assembly language. Ok, I'm very familiar with assembly language on lots of CPUs/MCUs, but if I'm not an expert on the particular Microchip device, how hard is it to give the example in C as well? And not just in C, but in C for bare metal use, C for PLIB use, C for Harmony use, to cover all the bases, because who has time to figure out how to convert from the documentation's usage to the environment being used? Sure, it's not difficult to do, but it would be SO much nicer to just be able to cut and paste the code, with confidence that it's already correct. When they're currently pushing Harmony, yet still giving examples in assembly language, something's not quite right. It's my one pet-peeve about Microchip documentation.Quote from: Sal Ammoniac on July 26, 2021, 11:29:58 pmWhile I use the Cortex-M, sometimes the Cortex-A in bare metal is a much better solution for some of my applications. Problem is that most Cortex-A manufacturers don't provide a bare metal solution, rather only Linux and maybe Android, both of which have unacceptable boot times, in my opinion. I cringe whenever I use test equipment or some other device where startup time is very important, yet it's obvious that they're using a Cortex-A or similar and running in Linux. I'm not a hater of Linux, as it has it's purposes, but for most embedded devices I design, it's really not practical due to startup speed. Yet you need to access all the peripherals (USB, Ethernet, Video, etc.) in an easy manner. I've ended up having to analyze Linux driver source code and datasheets in order to write my own bare metal library in order to use a Cortex-A the way it's meant to be used (in my opinion). I look forward to the day when (hopefully the day will come) chip manufacturers really realize the huge benefit for their customers to be able to design applications for their CPUs under bare metal. Though in actuality, the absence of such gives me a huge advantage, being all my customers realize their product is so much more impressive than their competitors due to the almost instant on feature, which I can give them, so it keeps my services always in demand.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 27, 2021, 01:36:58 am
content: Quote from: AaronLee on July 27, 2021, 01:21:29 amYes. I remember that as well. Sometimes annoying: for some features, you would need tose use builtin functions in C, and would have to dig for that in the compiler's manual, with absolutely no complete example in C indeed.Quote from: AaronLee on July 27, 2021, 01:21:29 amWell sure. But look at how that works out already for "small" MCUs. A good half of users find that vendors' libraries are ugly, buggy, awfully bloated, you name it. Given the complexity of a typical Cortex-A SoC, vendors' libraries for using them baremetal would be even bigger and more complex. And almost everyone would just bitch about them, with a good half coming up with their own libraries anyway. That's almost a guarantee here.

author: AaronLee
author_rank: Regular Contributor
timestamp: July 27, 2021, 02:18:48 am
content: Quote from: SiliconWizard on July 27, 2021, 01:36:58 amVery true. But at least if there was a library with source code, you could use it and modify it yourself, and have an internet forum where people could discuss the bugs in the library and how to fix them. For something like I2C, SPI, UART, etc., designing your own library from scratch isn't too difficult. But when you step up into Ethernet, USB, Graphics with 2D/3D accelerators, Video Encoding/Decoding, etc., then it becomes an almost overwhelming job if there's not a base library to start from. One of my gripes about Microchip's Harmony is that for PIC32MZ devices with graphics, you're forced to use it, but there's no source code. I fully realize that it cannot be expected that a graphics library will suit me 100%. I've never come across one yet that does. Which is why I want the source code so I can tweak it so it's optimized to my application. Or at least provide me with documentation of all the hardware registers. But I guess likely Microchip just added on a graphics processor to their MZ and don't have the right to publish the source code nor even the hardware register documentation. So I'm stuck with either having the application crippled by the inferior library, or going with a different company's CPU. My customer wants Microchip (due to good delivery and good past experience), but they don't like the performance. I've explained it to them, and for the next revision of their product we'll likely change to ST or another vendor.Anyways, I doubt many of the firmware engineers working on these more complex applications could even handle bare metal, especially being they need to add to it either a RTOS or do it themselves. Take, for example, the Siglent oscilloscopes. I recently purchased a SDS2104X, so I'm familiar with it, and watched the teardown videos, etc., and knew what it was before buying it. Inside is a Xilinx Zync CPU with dual Arm Cortex A-9's and a FPGA section. Xilinx is one of the few vendors who does provide a bare metal development environment. Yet when I turn on the scope, it's obvious they didn't use bare metal. That's further confirmed when I watch the teardown video and see when connected to the UART debug port the messages coming from U-Boot and then Linux. Why? If bare metal was available, why didn't they use it? I assume their firmware engineer simply wasn't capable of using the bare metal which is available. Not just me, but I've seen lots of comments on this forum and elsewhere from others about how long the boot time is for lots of test equipment these days. They add on a LCD screen, USB and Ethernet ports, and suddenly the firmware engineer has no idea how to design the product unless using Linux as a crutch. If I'm working on some project, and suddenly need to use the oscilloscope, DMM, power supply, etc., I don't want to wait for a minute just for the equipment to power on. If I leave my gear on all day, it's not such a big deal. But if the gear isn't something that's normally on my bench and powered on, the delays can be frustrating, especially if I'm in a hurry. Another example, but more critical, is the camera system in a car. Years ago, it was common for the systems to take 30 seconds or more to startup. When you start your car, and want to back out, you don't want to wait 30 seconds or a minute before being able to see the rear camera on the LCD display. You need it NOW. That's simply retarded to ever even consider designing such a product, yet countless times I saw such products in the past. Lately it seems the manufacturers have realized this, and either they've figured out how to optimize Linux to boot very quickly, or gone with an alternative that can provide that almost instant-on function.It's becoming more and more common to add LCD, USB, etc. functions to even basic devices that used to be without either. Yet the MCU/CPU chip manufacturers I feel are lagging in providing source libraries to access these functions. More and more it's becoming necessary for MCU engineers to be able to make their devices operate these interfaces in a professional way, but isn't possible using the legacy software development environment. Microchip Harmony (on the PIC32MZ) is not a professional graphics solution due to the inability to optimize the source code for professional/seamless screen transitions along with proper memory management. Standard Linux or Android are not a professional graphics solutions due to long boot times. I see this becoming more and more of an issue, and something the chip vendors need to seriously address. Especially for firmware engineers without experience with these interfaces, most chip manufacturers are really missing the boat because even though they have very capable hardware, they haven't taken the time to really inform and educate the engineers in how to properly use that hardware to develop truly professional products.

author: Bassman59
author_rank: Super Contributor
timestamp: July 27, 2021, 03:52:35 am
content: Quote from: AaronLee on July 27, 2021, 12:58:37 amMy guess is the extensibility. The MCU vendors add things like pin and other hardware configurators, which generate code, and while they all have different approaches, that they could do it within the IDE is a big win.A second reason is possibly that it's cross-platform.A third reason? "everyone else does Eclipse, so we have to do Eclipse, too."

author: JOEBOBSICLE
author_rank: Regular Contributor
timestamp: July 27, 2021, 05:51:12 am
content: Quote from: AaronLee on July 27, 2021, 02:18:48 amWith Linux you can have one firmware engineer and 15 software engineers. Bare metal you may need to have at least 10 firmware engineers because you're implementing everything.So I'd say it makes sense, there's no point reinventing the wheel / graphics library / TCP/IP stack etc. It's also worth pointing out that you can get Linux to boot quickly and from my experience nothing is quite as good as Linux for TCP/IP.

author: rcbuck
author_rank: Frequent Contributor
timestamp: July 27, 2021, 06:25:22 am
content: QuoteSal, are you saying Seeger Embedded Studio is the same thing as Rowley Crossworks? Does it have the Rowley libraries or just the IDE/compiler features?I've looked at the Rowley website a couple of times over the last year or so. But as a hobbyist I didn't see that it had a huge advantage over the STM32CubeIDE that I currently use.

author: nctnico
author_rank: Super Contributor
timestamp: July 27, 2021, 09:12:33 am
content: Quote from: Bassman59 on July 27, 2021, 03:52:35 amNot just that, Eclipse supports a wide variety of languages so you only need to learn one IDE to do all your coding in. And it works out of the box.

author: rsjsouza
author_rank: Super Contributor
timestamp: July 27, 2021, 10:41:32 am
content: Quote from: nctnico on July 27, 2021, 09:12:33 amWell, not only that but its interface has been more or less the same for well more than a decade.To me performance is the most significant factor that detracts from it.My favourite feature is the concept of perspectives, where the workbench switches over to a different and customizable set of views for each task at hand (code development, debugging, remote access, etc.). Whenever I have to go back to an IDE with a single view for everything, where starting a debug session crumples the disassembly, memory, registers view in the middle of source code navigation views is quite annoying. I also like the editor and its source code navigation capabilities, extensibility and automation (command line interface works well for code testing and building) as well as customizations (including keyboard shortcuts).It is not for everyone's taste, but it has upsides.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: July 27, 2021, 03:27:59 pm
content: Quote from: AaronLee on July 27, 2021, 01:21:29 amThat's never really bothered me. I'm usually very familiar with the assembly language of any MCU that I use, and I never use the example code in my projects--I just use it as an example of how to do something.I didn't mention this in my original post, but I never use vendor libraries like PLIB (or, horrors!, Harmony). I prefer to write my own code for CPU start-up and peripheral drivers. That's just me, however--most people these days completely rely on whatever canned libraries the vendor provides.QuoteI agree with your comment about bare metal and boot times. At my last company we needed a 10 msec boot time--good luck trying to achieve that with embedded Linux! Most vendors just don't support bare metal development on Cortex-A class CPUs--they assume everyone will be using Linux or similar. Sometimes writing your own bare metal implementation isn't even an option. Example: the CPU used on the Raspberry Pi--you just can't get the documentation needed to do so from Broadcom.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: July 27, 2021, 03:39:12 pm
content: Quote from: rcbuck on July 27, 2021, 06:25:22 amYes, Segger Embedded Studio is the same thing as Rowley CrossWorks. There's really only one difference. CrossWorks supports a number of debug probes, including J-Link, ST-LINK/V2, ST-LINK/V3, CMSIS-DAP, and about a dozen others. Embedded Studio only supports J-Link, which makes sense because Segger's primary business is selling J-Links.Embedded Studio is free for non-commercial use. Rowley has a "personal license" available for CrossWorks for non-commercial use that costs $150. I use both (and do have the Rowley personal license) for my hobby work.CrossWorks/Embedded Studio isn't based on Eclipse--it's a native C++ application--so it's much faster and responsive than Eclipse. Editing, building, and debugging are the same as in STM32CubeIDE, but they don't support the pin configuration and code generation stuff that STM32CubeIDE does.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 27, 2021, 04:03:14 pm
content: Quote from: AaronLee on July 27, 2021, 02:18:48 amThat's right.Now, that's where those "crossover" MCUs come in handy. (For instance, the NXP ones:https://www.futureelectronics.com/fr/npi/i-mx-rt1160-crossover-mcu-family)They're getting close in performance to Cortex-A CPUs, while still having the tools and libraries you'd expect for a classic MCU. Those NXP MCUs come with a full library with source code, and it's not even that bad! And, I'd expect this kind of MCUs to expand in the future.

author: AaronLee
author_rank: Regular Contributor
timestamp: July 27, 2021, 05:35:30 pm
content: Quote from: SiliconWizard on July 27, 2021, 04:03:14 pmYes, I've been eyeing NXP's crossover MCUs ever since they were first announced, but I haven't convinced any of our customers to accept them yet. Primary issue is the chips with a LCDIF only come in BGA packaging. My customers typically are very reluctant to go with BGA unless absolutely necessary, due to the additional cost/complexity related to the PCB. If they're going to go with a BGA device, then they'll just select the more powerful iMX6 series, which I already have bare metal running on, even though NXP doesn't officially support bare metal on the regular iMX6's. Both Microchip and ST have devices with RGB LCD interfaces and LQFP packaging. If NXP were to offer a LQFP package for the RT1160, it would be enough to convince me to spend the time to learn it and recommend it to my customers and have confidence they'd accept it.

author: AaronLee
author_rank: Regular Contributor
timestamp: July 27, 2021, 06:04:24 pm
content: Quote from: Sal Ammoniac on July 27, 2021, 03:27:59 pmI have so many different MCU/CPUs that I use that it's no longer practical for me to be very familiar with each device's assembly language. I've literally written well over a million lines of assembly code during my career, and absolutely love it. It was my primary language for a very long time. But quite a number of years ago I started transitioning to C, simply because the huge advantage assembly had in speed and size started to diminish as more powerful MCU/CPUs came out, with more memory, and compilers could optimize code better. I still revert to assembly language though for key sections when optimization is absolutely essential or sometimes for startup code, and such. Always switching between various MCU/CPUs, portability of code has become more important to me. Especially when suddenly the chip in a design isn't available, or the design needs to be expanded beyond the original chips ability, so we need to change to a totally different device, and I can often modify my code in just hours to adapt to the new chip, even if it's from a different manufacturer. Whenever practical, I choose to do as you, and not rely on the vendor's libraries.Quote from: Sal Ammoniac on July 27, 2021, 03:27:59 pmI did some research about Linux, and I saw one where they optimized it to boot in 500ms. But doing anything remotely close to that is probably outside the abilities of 90% of the Linux engineers, and still is highly dependent on which chip you're using, and lots of other factors. I hated how there isn't proper documentation for the Raspberry PI. I bought one when they first came out and was thrilled that they had video encoding/decoding built in, but soon lost all interest when I saw how closed Broadcom made the CPU, without proper documentation. Plus the fact that the CPU is only available as part of the Raspberry PI, or lately as an alternative in their Compute module. The only way it would work for my needs would be if the Raspberry PI was just an EVM, and the CPU was available to purchase on it's own, and full documentation was provided. But of course, Broadcom's customer base is completely different from Microchip, and aren't the least bit interested in customers who aren't looking to buy hundreds of thousands of chips.

author: Bassman59
author_rank: Super Contributor
timestamp: July 27, 2021, 06:57:44 pm
content: Quote from: rsjsouza on July 27, 2021, 10:41:32 amMy favorite feature of Eclipse, at least for microcontroller development, is "References," where you select something, right-click and choose References ... and then it shows you everywhere that thing is mentioned in the project. I also like "Open Declaration."I still use emacs for VHDL, because nothing else even comes close to its templates and auto-complete, but it doesn't have the find-references or find-declaration feature. I know about Sigasi, which is based on Eclipse and might have the references feature, but holy fuck they charge $1386 per year per seat for an editor and that's a complete non-starter.

author: rcbuck
author_rank: Frequent Contributor
timestamp: July 27, 2021, 07:06:56 pm
content: QuoteSal, thanks for the information. That confirms what I thought. Rowley/Segger Studio are really nothing more than another IDE.

author: nctnico
author_rank: Super Contributor
timestamp: July 27, 2021, 07:11:03 pm
content: Quote from: Bassman59 on July 27, 2021, 06:57:44 pmI'm using the Veditor plugin to deal with VHDL in Eclipse. Not perfect but lightyears better compared to a plain text editor. And I agree about Sigasi. I have tried it for a while and it is fantastic but recurring cost is a non-starter for me. If they charged 500 euro for a perpetual, non-node locked license I'd buy it in a heartbeat though.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 27, 2021, 07:21:18 pm
content: Quote from: Bassman59 on July 27, 2021, 06:57:44 pmI agree that's an important feature, but any decent programming editor has that. If not, I would ditch it in an instant. Eclipse is certainly far from being the only one having this.

author: Bassman59
author_rank: Super Contributor
timestamp: July 27, 2021, 07:46:44 pm
content: Quote from: SiliconWizard on July 27, 2021, 07:21:18 pmNow that I think about it, VScode and NetBeans (used by Microchip Harmony) have it too.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 27, 2021, 07:48:54 pm
content: Quote from: Bassman59 on July 27, 2021, 07:46:44 pmSpeaking of VSCode, for those liking the features but willing to avoid any nasty MS hidden code and telemetry, you have VSCodium:https://vscodium.com/

author: bd139
author_rank: Super Contributor
timestamp: July 27, 2021, 07:52:27 pm
content: Or just turn it off in the settings...

author: westfw
author_rank: Super Contributor
timestamp: July 27, 2021, 09:22:19 pm
content: QuoteSo they claim. They didn't do THAT great a job, especially in the early chips. The AT90S1200 was pretty crippled; I figure a "minimum cost" effort aimed directly at replacing low-end PICs.)It was a heady era of microcontroller development, and there were lots of marketing claims like "PDP11-like" and "designed for C", and there was quite an unpleasant battle between Microchip and Atmel, mostly marketing-speak (most engineers shrugged and used whatever was suitable and available. They weren't writing C anyway.)The PIC18 datasheets also claim "C Compiler Optimized RISC Architecture"...Usually that means "at least two index registers, and some stack instructions." The AVR was better than most, but has some "poor decisions" (why isn't the SP one (two) of the GP registers? Every time you want to build a stack frame, it's a PITA...)

author: westfw
author_rank: Super Contributor
timestamp: July 27, 2021, 09:25:43 pm
content: QuoteAre you not aware of TAGS ?Code:M-X tags-apropos$micros$$Click mouse-2 to follow tags.Tags matching regexp ‘micro’:[libraries/USBHost/src/hidusagestr.h]: const char pstrUsageMicrophone [] PROGMEM[libraries/USBHost/src/hidusagestr.h]: const char pstrUsageMicrophoneEnable [] PROGMEM[bootloaders/mzero/Bootloader_D21/src/ASF/sam0/drivers/usb/usb.h]: static inline uint16_t usb_device_get_micro_frame_number([bootloaders/mzero/Bootloader_D21/src/ASF/sam0/drivers/usb/stack_interface/usb_device_udd.c]: uint16_t udd_get_micro_frame_number([bootloaders/mzero/Bootloader_D21/src/ASF/common/services/usb/usb_atmel.h]: #define USB_PID_ATMEL_UC3_AUDIO_MICRO[bootloaders/mzero/Bootloader_D21/src/ASF/common/services/usb/usb_atmel.h]: #define USB_PID_ATMEL_UC3_AUDIO_SPEAKER_MICRO[bootloaders/sofia/Bootloader_D21_Sofia_V2.1/src/ASF/sam0/drivers/usb/usb.h]: static inline uint16_t usb_device_get_micro_frame_number([bootloaders/sofia/Bootloader_D21_Sofia_V2.1/src/ASF/sam0/drivers/usb/stack_interface/usb_device_udd.c]: uint16_t udd_get_micro_frame_number([bootloaders/sofia/Bootloader_D21_Sofia_V2.1/src/ASF/common/services/usb/usb_atmel.h]: #define USB_PID_ATMEL_UC3_AUDIO_MICRO[bootloaders/sofia/Bootloader_D21_Sofia_V2.1/src/ASF/common/services/usb/usb_atmel.h]: #define USB_PID_ATMEL_UC3_AUDIO_SPEAKER_MICRO[cores/arduino/delay.c]: unsigned long micros([cores/arduino/delay.c]: void delayMicroseconds([cores/arduino/Arduino.h]: #define clockCyclesPerMicrosecond([cores/arduino/Arduino.h]: #define clockCyclesToMicroseconds([cores/arduino/Arduino.h]: #define microsecondsToClockCycles((apparently there is also now an "xref" library, which may or may not use TAGS underneath...)

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: July 27, 2021, 10:10:54 pm
content: Quote from: rcbuck on July 27, 2021, 07:06:56 pmHow often do you use the pin config and code generation stuff? I do 2-3 projects a year and don't bother with that stuff at all. For pin config, I create a spreadsheet with the pin mappings. That takes about a day, but that's a tiny fraction of the overall time I spend on a project. I'd rather do that than use the automated pin config stuff in STM32CubeIDE but then be saddled with a sluggish IDE for the rest of the project.

author: AaronLee
author_rank: Regular Contributor
timestamp: July 27, 2021, 11:53:56 pm
content: Quote from: rcbuck on July 27, 2021, 07:06:56 pmRowley/Segger Studio is the only IDE I've ever used that I felt was designed/written/tested by someone who actually uses it, thus is the way I want to use it. It's not perfect, but it's way better than anything else out there. Just my own opinion, given my way of using an IDE.

author: AaronLee
author_rank: Regular Contributor
timestamp: July 27, 2021, 11:58:21 pm
content: Quote from: nctnico on July 27, 2021, 07:11:03 pmWhat chip are you developing for? I'm presently using Xilinx Vivado/Vitis and wish I could improve it. I tried downloading an extension for Vitis (Eclipse), but it failed to install. I'm guessing Xilinx tweaked something that makes their Eclipse implementation non-standard. I use VHDL some, but my preference is for Verilog.

author: AaronLee
author_rank: Regular Contributor
timestamp: July 28, 2021, 12:37:54 am
content: Quote from: Sal Ammoniac on July 27, 2021, 10:10:54 pmAgain, I'm in complete agreement with you, and I do a lot more projects per year than you. What I do is whenever I start to use a new MCU, I take the time to make a pin define file for that particular MCU/package type, along with macros and/or functions whereby I can access any pin by the pin number, rather than the chip manufacturer's designation. As an example, take the PIC16F877A 28-Pin PDIP, SOIC, SSOP, where Pin 2 is RA0/AN0. I would have a macro or enumeration of "PIN2". Then I'd have a header file for all pins on the MCU organized according to interfaces, and define the net name in terms of the pin number. So, let's say Pin 2 (RA0) is a system LED. I'd have a board header file where I define:#define SYSTEM_LED PIN2#define LED_ON 0#define LED_OFF 1Then when I initialize the pin, I call a function like this:gpioOutputInit (SYSTEM_LED, LED_ON, GPIO_ATTRIBUTE_NORMAL);And set the pin via:gpioOutputSet (SYSTEM_LED, LED_OFF);Or toggle the pin via:gpioOutputToggle (SYSTEM_LED);The function gpioOutputInit is defined such that it will initialize the pin as a GPIO output, with an initial setting high or low, and setting additional attributes that the particular pin might have, such as pull-up/pull-down, etc. Likewise gpioOutputSet and gpioOutputToggle work as you'd expect.So I always access all GPIO pins by the net name, not some port number or such. I totally cringe whenever I see Microchip code written like:TRISA = 0xac;LATAbits.LATA0 = 0;What if I suddenly want to swap the system LED from pin 2 to pin 28 (RB7)? I have to modify the TRIS initialization, and every point where I turn the LED on or off via the LAT statements. It's a totally ridiculous way of programming an MCU, in my opinion, other than as some learning experience, or for some very basic project that won't need many changes after the design is fixed. For my projects, there's an initial board, and almost always pins are changed around before the final board, and often numerous times in between. Plus using the net names makes the code much more self documenting. And if we decide to totally change the MCU to a different family or even different manufacturer, no problem. For at least all the GPIO pins, I only need to change one header file with the new pin numbers, not needing to know anything about which port that is on a particular MCU, etc. Or to change the LED from active low to active high, I just change in the board header file two definitions for LED_ON and LED_OFF, rather then hunting throughout the file for each occurrence of LATAbits.LAT0 and swap the value used. For simple peripherals, I also do something similar. So for SPI, I2C, UART, I can just define a port number, and then later if I want to change to use a different port, I make the change on place in the board header file. Of course there's a limitation to what can be done. There's certain things that are just so MCU specific, that they can't be generalized across all varieties of MCUs. But at least 90% or more of the code is portable.Anyways, Sal, as you do, I start out with a spreadsheet of my MCU pinout. Then from that, I create my board header file, and then do the code. Whenever I want to see which actual pin is a certain function, I just open the board header file, no matter what the MCU is, and all the pins related to a particular interface are right there organized in one grouping. I never need to deal with an automated pin configuration tool which is going to be different for each manufacturer, and just a step to slow me down whenever I need to change things around. Now if I'm on a brand new MCU family, and especially if there's a big hurry to do it, or if it's a one-off project using that MCU, I might use the manufacturer's automated pin configuration tool, and just be done with it, rather than spend the time to generate the necessary code and header files to deal with it in my standard format. But those cases are few and far between. Generally I use the same MCUs over and over again for project after project, and I find my method saves a ton of time and headaches.

author: DavidAlfa
author_rank: Super Contributor
timestamp: July 28, 2021, 01:27:24 am
content: Because you think on it like pins and not ports. If you connected an 8-bit bus to a port, would you read it bit by bit?No, you read the port register in a single read instruction.You have simple macros/defines to access and configure single pins. Your code can be easily reconfigurable by just using defines:Code:#define Toggle(x) x^=1;#define LED LATA1#define LED_TRIS TRISA1#define LED2 LATA2#define LED2_TRIS TRISA2#define BUTTON RA3#define BUTTON_TRIS TRISA3void init(void){LED_PIN=LOW;LED_TRIS=OUTPUT;LED2_PIN=LOW;LED2_TRIS=OUTPUT;BUTTON_TRIS=INPUT;}void main(void){init();while(1){LED=BUTTON;Toggle(LED2);if(BUTTON){button_detected();}}}

author: AaronLee
author_rank: Regular Contributor
timestamp: July 28, 2021, 02:56:34 am
content: Quote from: DavidAlfa on July 28, 2021, 01:27:24 amFor a parallel port, yes, you're correct, it would be stupid to access it as individual pins. That's one of the exception cases.For your style of defining pins, something similar was what I tried many decades ago. But there were three problems.First, the "=" operator works fine for Microchip, but isn't compatible across the board with all MCUs. Defining a simple macro to look like a function, but does the same thing, works as a good alternative.Second, initializing a pin, even if it's done in discrete steps, is often thought of in terms of one atomic operation. If you're setting a pin as an output pin, you'd better be setting the level at the same time (preferably right before setting it as an output). If not, you'll easily get unwanted results momentarily on the pins while it's being initialized. Making it as a function/macro init function for the pin allows this to be done without thinking about it. Of course, a good firmware engineer will code it in the correct order, as you did in your example, but sometimes we all make mistakes and forget things. A well designed macro can handle all of this while generating the same final code, but just making the sure the correct sequence is done, while also making the code more readable.Third, when I'm developing/debugging, and testing pins with a scope or other test equipment, I reference my code and the schematic to find where I need to probe. I find it easy if I just have my board header file open, see the net name and pin number, and can then also search for that net name to find all occurrences of where I'm using it, so that I can change code easily. I rarely need to know the port number. Pin number (for probing or referencing on the schematic) and net name (for searching my code or also for referencing the schematic) are what I need. If I happen to need to know the port number, I can also call that up using the header file I made for the MCU part number defines, or via the MCU datasheet.A board header file can easily be scanned to see all the interfaces organized, which pin numbers are being used for each pin of the interface, which levels are defined for those pins, etc. It just makes it all nicely organized from the firmware point-of-view. The more experienced I get as a firmware engineer, the more I realize how keeping things neat and organized like that really help with efficiency and also help greatly when returning to a project after not having worked on it for a number of years, or when a bunch of different projects are being done simultaneously and it's easy to forget details of one particular project. A quick glance at the board header file, and you easily see all the interfaces you're using, along with some brief comments in the header file about each interface, and the mind is instantly refreshed about the details of that project and ready to dig into doing whatever needs to be done. If I'm talking to a hardware, QC, PCB, or other engineer about our project, I always refer to pins by their pin number and/or net name. In general everyday use in firmware, I just don't see the need for using port numbers in the forefront, especially regarding GPIO pins.Having definitions such as "LED_TRIS" means you're limiting your thinking regarding names to just the Microchip (not even including Atmel) realm. If you're always going to use Microchip exclusively, it might be ok, but when your code is needed to be used across a broad spectrum of devices from various manufacturers, you may find that using functions/macros while define things in terms of functionality rather than specific vendor terminology makes the code much more portable and easier to understand. Even within Microchip, there's quirks in certain devices/families regarding initializing pins, as I recall. It's very easy to forget about those quirks, or fail to recall that those quirks are applicable to the part you're working on.I could go on and on about what I think is well-structured/organized MCU programming, but then in the end it's just my personal opinion, and I'm in no way want to force my opinion on anyone else. I do though think the MCU world is very lacking in teaching good techniques. There's countless books teaching good general programming techniques, but when it comes to MCU programming, and accessing hardware/peripherals, almost all the materials concentrate way too much on specific MCU coding for the one MCU they're teaching about, and very little on making the code portable and thinking beyond that particular MCU.

author: rcbuck
author_rank: Frequent Contributor
timestamp: July 28, 2021, 03:40:03 am
content: QuoteSal, sometimes I use it and sometimes I don't. My last two STM32 projects have used Lwip so I had to use the code generation tools for that. Since I was already in the CubeMX setup it was just easy to also do the pin configuration there. I haven't noticed STM32CubeIDE being slow. But then again I am a slow programmer.I always use #define for all pins. That is the only way to keep any hair on your head.Last week I did a small PIC project using the PIC16F18313. I only used 2 GPIO pins but I #defined them. I was using I2C so I used the Microchip XC8 built in library function for that. I only have the free version of XC8 and not the fully optimized version. Code size ended up being 385 bytes of flash and 9 bytes of RAM. I don't think you can beat the 75 cent cost of the micro with any other family. At least not in the U.S.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 28, 2021, 04:35:58 am
content: Yeah, I like doing that. In fact I take that process to its fullest; like here:https://github.com/T3sl4co1l/Reverb/blob/master/pindefs.hNote that avr/io.h defines rich macros and names for registers and bits already (give or take a few mistakes, the ones I know about are enumerated in a neighboring file), this just makes them application specific; and declares a few handy expressions/statements to further work with them. The bus-oriented registers are noted by comments, so the reader knows not to shuffle things around randomly; and yeah, the individual bits of them don't get used much. This file starts as an Excel sheet (also in the project), where you fill in names and roles, and copy code out for further cleanup and additions. It's sort-of generated, but not meant to be live generated due to the edits.Finally, Notes.txt logs/discusses some hardware/software design issues, but here mainly logs complete pin assignments as a crude netlist, describing the hardware (I didn't produce a schematic for this project, and kind of don't need to; also, this was a necessity as it was hand wired..). I usually put MCU pin defs at the top of main.c to help reference and motivate things.Most manufacturers have their own tools for stuff like this; it's handy, but beware the pile of definitions they create, and how much repetition they may do. For example, identical sections used in init and handler functions. I recall ST Cube being pretty baroque about this.Tim

author: apurvdate
author_rank: Contributor
timestamp: July 28, 2021, 11:59:18 am
content: There was no exposure to PIC or ARM during our college coursework. Only a slight mention by instructor as alternate family of controllers. 1st ever micro we used was atmel's variant of 8051 i.e. 89C51. Then it was AVR thing only. By the time we finished college and had any real experience with either PIC or ARM, arduino boom came. As we were already familiar with AVR, arduino was the thing for us.Only after working as trainee & few basic jobs, we had any interaction with either ARM or PIC (depending where you worked).I literally worked 1st time with a PIC last year during lockdown.So its not like we don't like PIC / microchip, its just the situational thing where we started with AVR and moved to ARM.

author: Howardlong
author_rank: Super Contributor
timestamp: July 28, 2021, 05:08:15 pm
content: Quote from: SiliconWizard on July 22, 2021, 06:16:53 pmSounds odd. I have two projects based on exactly this device, both with I2C, with no problems using my usual PIC boilerplate on it.That's not to say Microchip don't screw up I2C, much of the PIC32 range is an industry joke in this respect, and has been for a decade.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 28, 2021, 05:28:46 pm
content: Quote from: Howardlong on July 28, 2021, 05:08:15 pmI took a look at the project. There was a clear mention in the changelog that the I2C module was not functioning properly and that a software-based I2C had to be implemented. Unfortunately, there is no detail about what exactly was not working right, but AFAIR, it was not even clocking. It may have depended on silicon revision? I had extensive experience with Microchip MCUs at the time, so the probability of a misconfiguration explaining the issue was very low. And, that was the only PIC MCU I used that I couldn't use I2C with in the 16-bit line.I had kept the code for hardware I2C in this project, so I just took a look at it. I can't see anything wrong. I was using the I2C1 peripheral. All functions were the same as what I used for other PICs.Here is the init function, which was the only thing specific (configuration + rate):Code:void I2C_Init(void){// I2C 1.I2C1CON = 0x3200;// I2C1: Stop in idle modeI2C1BRG = 99;// SCL: 10 kHz @1MHzIFS1bits.MI2C1IF = 0;IFS1bits.SI2C1IF = 0;IEC1bits.MI2C1IE = 0;IEC1bits.SI2C1IE = 0;I2C1CONbits.I2CEN = 1;// Enable I2C module}

author: Howardlong
author_rank: Super Contributor
timestamp: July 29, 2021, 08:42:08 am
content: Quote from: SiliconWizard on July 28, 2021, 05:28:46 pmHmm, that's unfortunate! These are over a decade old, I'd have thought Microchip would've flagged up any I2C issue by now in the errata. I know it takes them a while sometimes...FWIW, I just put a little unit test together from scratch with my boilerplate I2C targeting an FRAM, and it does seem fine.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 29, 2021, 05:59:05 pm
content: Quote from: Howardlong on July 29, 2021, 08:42:08 amThis may have plagued the early silicon revisions, dunno. I possibly got ahold of the first silicon revision for the parts used on the prototypes, and once the project was completed, I never bothered to check with newer silicon revisions if the hardware I2C would work. But yes, I could not find any mention of this in the errata for this part. I can just assure you that it wasn't working whatsoever. Now looking back at my code, maybe the bug was related to the fact I set the "stop if Idle" flag? I can't remember if I ever tried clearing it.

author: radiolistener
author_rank: Super Contributor
timestamp: July 29, 2021, 09:39:01 pm
content: because they are expensive and have too small resources in comparison to other microcontrollers

author: NorthGuy
author_rank: Super Contributor
timestamp: July 30, 2021, 02:49:11 pm
content: Quote from: AaronLee on July 27, 2021, 02:18:48 amThat's a strange argument. Sure, you can replace PIC10F320 with a Zynq running Linux. Why not do it? They used it in the scope after all. Whether this would make things easier ... I doubt.

author: esepecesito
author_rank: Regular Contributor
timestamp: July 30, 2021, 04:26:35 pm
content: My story why I did not like it:1) I used a couple of controllers for a project, and they just stopped working, without apparent reason. MANY with similar problems, different controllers, buy in different providers. Never had a similar problem with Atmel 8051 or the MOT HC05 HC08 (at that time we were making lots of projects with all of them)2) Once I was searching for a CAN controller, and the one from Microchip had so many discrepancies with the CAN standard, that it seamed to me they didn't even read the standard.That being said, it was like 20 years ago... but I never got over it.

author: voltsandjolts
author_rank: Unknown
timestamp: August 02, 2021, 08:58:27 am
content: Quote from: esepecesito on July 30, 2021, 04:26:35 pmMy experience is the opposite, once you have a working system it just keeps on going. Once you get past the errata, I find the device silicon to be reliable and robust, to the extreme that a number of PICs I've used run at 200 Celcius for weeks. Perhaps you were experiencing software issues though.I can see (and mostly agree with) the issues that people have with Microchip, but IMO the positives often outweigh the negatives (depending on project);Good device availabilityPin compatability between devicesGCC based compilers are old but have all the features I need and are well testedI find the datasheets easy to follow and mostly correctPeripherals are generally easy to setupDMA in PIC24 and PIC32 is greatFamiliarity - once you know a lot of gotchas in one eco-system it becomes more comfortable. Better the devil you know(but that applies to any system of course)

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 02, 2021, 09:40:25 am
content: Quote from: voltsandjolts on August 02, 2021, 08:58:27 amYes, it applies to any system, but I believe Microchip is unique in having one "system" covering a very wide range of parts from tiny 8-bitters to big fat 32-bit devices.

author: NorthGuy
author_rank: Super Contributor
timestamp: August 02, 2021, 12:38:35 pm
content: Quote from: mikeselectricstuff on August 02, 2021, 09:40:25 amThat is changing now. The newer PIC32C devices are renamed Atmel SAM parts which have completely different flavours of periphery. Designers at Microchip think that Harmony provides enough abstraction to smooth the difference.

author: AaronLee
author_rank: Regular Contributor
timestamp: August 02, 2021, 01:00:25 pm
content: Quote from: NorthGuy on August 02, 2021, 12:38:35 pmHahaha, HUGE mistake. IMHO, too much emphasis on Harmony will be Microchip's downfall. Harmony is nothing but a complete piece of turd framework that should have been killed off long before they released it.

author: HB9EVI
author_rank: Frequent Contributor
timestamp: August 02, 2021, 04:02:01 pm
content: for my needs Microchip has some nice A/D and D/A converters, also the low power Opamps are useful.That I switched from PIC to AVR (before the time Microchip bought AVR), had one main reason: avr-gccif there was a well developed opensource compiler for PICs, I'd likely stay with them.yea I know there is SDCC, but its PIC14/PIC16 ports are still not out of beta stagenowadays I don't bug neither with ATXmega nor with PIC32; simple ARM mcu is all you need (if you get any from reliable sources due to the chip crisis)

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 02, 2021, 04:22:38 pm
content: Speaking of Harmony, which I've never used, is the whole source code provided by Microchip?

author: esepecesito
author_rank: Regular Contributor
timestamp: August 02, 2021, 06:03:40 pm
content: Quote from: voltsandjolts on August 02, 2021, 08:58:27 amNote I said it was looong time ago... maybe now they are in fact much better than others. At that time I really doubt it.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 02, 2021, 06:16:11 pm
content: I have hard time believing that Microchip MCUs have had such quality problems that they just "stop working".OTOH, it's normal to have very mysterious problems when working with MCUs because these are complex devices with many possible failure modes; not only limited to ESD, reset pin connections and power bypassing, but also some software issues seem to cause something like hardware failure while it really is a software problem! (I always refer to the case where a small bug in I2C initialization code made some 3-4 units out of batch of 30 fail in the init, others work perfectly, appearing like a soldering/ESD issue!)The number of such problems obviously goes down with experience. Just changing to different product family or manufacturer may seemingly solve the problem because the actual culprit just goes away without the need to do the (expensive) root cause analysis, but this doesn't mean there was something wrong with the original product, the designer was just a bit inexperienced, or even if very experienced, just unlucky to hit some strange hard to debug problem.

author: nctnico
author_rank: Super Contributor
timestamp: August 02, 2021, 07:53:27 pm
content: Quote from: Siwastaja on August 02, 2021, 06:16:11 pmBut you have to ask yourself if you want to use a microcontroller which is so finicky to use. In the end such bugs end up costing time. Time which costs money and delays product introduction which in turn reduces sales. For smaller volumes (*) you are better off using microcontrollers which have not been optimised down to the last transistor and which have proper I/O pads. If you look at the Attiny for example: the Vih level of 0.8V has no meaningfull noise margin. This can be problematic in noisy environments. Especially compared to a proper CMOS input which typically has a Vih of 0.7*VCC.* For high volume products it is quite normal to have a couple of hundred produced which are then tested for durability and component variations (and thrown into the shredder afterwards).

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 02, 2021, 08:40:42 pm
content: Quote from: SiliconWizard on August 02, 2021, 04:22:38 pmYep. It's here:https://github.com/Microchip-MPLAB-Harmony

author: Siwastaja
author_rank: Super Contributor
timestamp: August 03, 2021, 11:35:02 am
content: Yes I agree about the concept of avoiding finicky parts to save time, but I have never heard about PIC micros being "finicky" before. In fact I think their simplicity helps save time. Same can be said about AVR. Well early AVRs did have issues with their internal reset circuit but that got fixed. I didn't know about some specific AVR having such strange non-CMOS-like input voltages. All ATTinys I have used (that would be 2313, 25 and 85, mostly) have, AFAIK, normal CMOS inputs and in fact they have more noise margin than some logic gate ICs, ignoring of course proper schmitt trigger ICs which are the best when this is important.

author: NorthGuy
author_rank: Super Contributor
timestamp: August 03, 2021, 02:33:38 pm
content: Quote from: rcbuck on July 28, 2021, 03:40:03 amPIC16F15213 must be much cheaper than 75 cents even in single quantities.

author: rcbuck
author_rank: Frequent Contributor
timestamp: August 03, 2021, 04:53:33 pm
content: QuoteThat is true but I did not have the PIC16F15213 in my parts box. 75 cents plus $7.99 Mouser would have made it a $9 part.Better wording would have been "I don't think you can beat Microchip's low cost 8 pin micros with any other mainstream family." I know there are some 10 cent Chinese chips but they have no support tools.I have been using PICs since 1995 and have an overall positive view of the parts. However their support and documentation over the last 5 years or so has really gotten bad. One thing youABSOLUTELY MUST dobefore using any PIC part is read the errata. Otherwise you will get bitten in the ass. I have never seen any PIC part just "stop working for no reason". When they stop working it is something I have done wrong in my code.For the last 3 years I have been mainly using STM32 parts except for small 8 pin projects. I did a PIC32 project a couple of years ago but still prefer the STM32 parts for my larger projects.

author: nigelwright7557
author_rank: Frequent Contributor
timestamp: August 03, 2021, 05:33:29 pm
content: I have used PIC's since about 1985.I have managed hundreds of successful projects since then.However, MPLAB X is not easy to use.Harmony while helpful can go very wrong sometimes.I always keep a backup of my projects on another drive for when Harmony does fail as it quite often does.The PICKIT's dont work very well. My PICKIT 4 lasted a week ! so went back to PICKIT3 which while runs my code rarely debugs correctly.Do not buy Chinese PICKIT copies, the one I got was always going wrong.

author: Wilksey
author_rank: Super Contributor
timestamp: August 03, 2021, 10:24:38 pm
content: I have used PIC MCUs for years, they have so many options, and the part I used 10 years ago I can still get, I have used AVR but I guess the whole Microchip vs Atmel is dead in the water now as Microchip own them, I find them quite easy to interchange, just different registers and such.I use it in a commercial capacity and we have equipment all across the world that uses PIC controllers with a lot of different uses.If I had to pick one thing that I do find a tad frustrating is the new debugger and programmer tools (ICD/PICKIT 4), the 3 was much more reliable in my experience, I find it quite irritating that it has to download new firmware to the ICD before it will program a different chip, so I end up with an ICD3 for each project that has a different uC, we have used about 8 different PICs in our projects so not too bad.I have no reason not to continue using them they work, I am very familiar with them and their quirks, yes the errata can be a face palm moment. I have started using STM32 and ESP processors of late for more tasking things, but these are overkill for most of what we produce.PIC controllers were the go to IC when I was starting out, everything was PIC and a sprinkling of AVR and the "new kid" the Parallax Propeller, but 9 times out of 10 if I was an article (as is the case still) it almost always used a PIC.

author: rcbuck
author_rank: Frequent Contributor
timestamp: August 04, 2021, 02:24:42 am
content: I have an ICD3 but haven't used it in several years as I have a Real ICE programmer/debugger. It also has to download new firmware if I change chips. I don't see that as a problem since it only takes a minute or so to load the new firmware. The Real ICE is much faster than the ICD3 was. Unfortunately it is no longer available and it appears they did not release a follow-up product. Microchip does say to consider purchasing the ICD4 as a replacement.Their notice killing off the Real Ice said no new device support would be added after June 1, 2019. I haven't found a device yet that it doesn't support. I guess I haven't used any of their newer devices (whatever those are). If I find one it doesn't support I will just not be using that device. There are other MCU manufacturers out there.

author: Howardlong
author_rank: Super Contributor
timestamp: August 04, 2021, 11:58:10 am
content: Quote from: rcbuck on August 04, 2021, 02:24:42 amQuite a few of the newer devices aren't supported by third generation PICkit3, RealICE & ICD3, eg PIC16F152xx, PIC18FxxQ4x, PIC18FxxQ8x.I find the need to upload new firmware every time I switch a target device family to be inconvenient (and sometimes unreliable - more often than not you have to do one or more physical removal/reinsertion cycles) but not a show stopper.Worse thing about the ICD4 & PICkit4 are their propensity to either not work, or even worse, brick older devices with 12V Vpp due to overshoot in the boost regulator. This has been corrected in recent hardware revisions. To be safe, put a 100 ohm in series with the device's MCLR.As a result, I end up using both the third and fourth generation programmer/debuggers.I found I only very rarely used some of the features of the RealICE, although I do have some of the add-ons such as the Performance Pak high speed adapter (which isn't high speed, it just extends the distance between DUT and debugger), and the Power Monitor. The ICD3 and PICkit3, both having the ability to power the DUT, I found to be a more useful use case.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 04, 2021, 04:37:38 pm
content: Segger claims to support the PIC32 with their J-Link products. They claim a major speed improvement over the ICD3/4. I've never tried this, so I don't know how viable this is, but it might be worth a try for someone who has issues with the ICDs.https://www.segger.com/products/debug-probes/j-link/technology/cpus-and-devices/microchip-pic32-support/

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 04, 2021, 04:54:06 pm
content: Quote from: Sal Ammoniac on August 04, 2021, 04:37:38 pmInterestingly: from your link, Segger uses JTAG for the PIC32.The PIC32 MCUs have been supporting JTAG from the first PIC32 IIRC. But they also support Microchip ICSP. I admit I don't know much how ICSP is implemented on those, and how close it is to JTAG - it may also depend on which PIC32 line we're talking about.But, don't Microchip programmers only support ICSP? Do they actually support JTAG?Point is: isn't JTAG access on PIC32 just faster than ICSP? Which would be ironic.If you know more about this on PIC32 though, don't hesitate to correct me or add information.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 04, 2021, 05:44:46 pm
content: Here's the Microchip help page for using J-Links with MPLAB X:https://microchipdeveloper.com/mplabx:segger-jlink-pluginFrom the page: "As of MPLAB® X IDE v5.25, the plugin for SEGGER J-Link debug probe support will no longer be necessary. Native IDE support is available as of this release."

author: Rudolph Riedel
author_rank: Regular Contributor
timestamp: August 07, 2021, 01:12:03 pm
content: What I do not like is that Microchip made the new ATSAM includes for MPLAB-X incompatible to the existing ones for Atmel Studio.And I really like what they have with Harmony, I would have apreciated it more though without breaking the includes for no apparent reason.

author: westfw
author_rank: Super Contributor
timestamp: August 08, 2021, 09:25:55 am
content: QuoteThat was a bit of a shock, wasn't it?I guess the theory is that the new "style" yields more unity with other chip families?and it's not like the Atmel style was particularly compatible with CMSIS standards, or without its problems. the whole ".bits.xxx" vs ".reg" was ... not pretty.

author: Rudolph Riedel
author_rank: Regular Contributor
timestamp: August 09, 2021, 09:13:41 am
content: Quote from: westfw on August 08, 2021, 09:25:55 amMore of a showstopper, the last straw to prevent me from switching over to MPLAB-X.QuoteI just checked the PIC32M examples in harmony and the includes are totally different.There are not even structures defined per peripheral unit, every register is identified by name,like "IEC4CLR" or "TRISBCLR".So no, that is not it, if anything these need a major overhaul.QuoteWhile I never had an issue with this .bits stuff I accept that issues might be a reason to change already established includes.But in this case we went from for example this:SERCOM6->SPI.DATA.regto this:SERCOM6_REGS->SPIM.SERCOM_DATAWhile a fix would have been this:SERCOM6->SPI.DATATo me this looks like an attempt to maximise the damage from changing the includes, active sabotage.And guess what, it works, I am looking into switching over to a controller family from a different manufacturer.

author: Microdoser
author_rank: Frequent Contributor
timestamp: August 09, 2021, 11:31:53 am
content: Personally, I tried a couple of chip types before deciding on the chips to use in my project. I bought 4 of each type, and the corresponding kit needed to program them. These days, there is hardly any difference in speed, reliability, features etc (at least ones relevant to my project), so I would be choosing on which was easiest and most reliable to flash, as that is where most of my time would be spent after the project was finalized and production started and so ease and reliability of flashing is where I would make the most long term gains.I then downloaded example code from well known sources to use as a test and tried to flash the chips.The PIC chips (using MPlab and PicKit 4 direct from the company, no chinese ripoff) failed at the first hurdle as none of them would flash. They claimed to have flashed, but the most simple test showed they had not, also there was no error message letting me know what had, or had not happened.I don't want to have to dive deep into technical manuals simply to flash a chip, arguably the most common process, and what should just work 'out of the box' even when attempted by the most novice user. I will be avoiding PIC chips wherever possible in the future unless I have the time and energy to find workarounds for issues that should have been addressed at the factory.The other chips worked straight away with no issues and I have now selected a suitable chip which I luckily bought a years worth of stock of just before ChipaGeddon. I only hope that in a year, we may see stock levels return slightly to normal.

author: Howardlong
author_rank: Super Contributor
timestamp: August 09, 2021, 05:25:30 pm
content: Quote from: Microdoser on August 09, 2021, 11:31:53 amI do agree that Microchip's interface between its MPLAB X IDE and the debuggers themselves isn't improving, if anything it's getting worse, and I use them on a daily basis.I also agree that having to debug the debuggers is a terrible introduction.I'm not sure that Microchip is alone in this, I have seen similar issues with both NXP andr Atmel (before Microchip) for example, but Microchip has had increasing difficulties in its toolchain QA for many years now, releasing half-finished products that aren't completed before they throw in the towel and start again with another half finished solution.

author: DavidAlfa
author_rank: Super Contributor
timestamp: August 13, 2021, 07:30:06 am
content: Wasn't hating them so much, but now I'm starting to do so!If I remove the Pickit3 while MPLABX is opened, on reconnect it will hang for 10-20 seconds and drop a power error message, having nothing connected to it, or just freeze forever.Hadn't this isue las time I heavily used it, maybe 1 year ago. I have to restart the IDE everytime !

author: Rudolph Riedel
author_rank: Regular Contributor
timestamp: August 13, 2021, 01:36:28 pm
content: This reminds me of an issue I had with MPLAB-X 5.15 and an Atmel ICE as well as a C21 xplained.As soon as I connected either the Atmel ICE or the C21 xplained MPLAB-X IDE or IPE would just terminatewith no error message. Just connect -> gone.And neither MPLAB-X IDE or IPE would start with an Atmel ICE or C21 xplained connected.I am not sure why this happened or if this still is happening but I found a way around this:Do not connect the Atmel ICE or C21 xplained using a hub, plug it directly in the computer.And of course this was with the USB driver Microchip provided with MPLAB-X.Also there was no issue with Atmel Studio.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 13, 2021, 02:16:09 pm
content: Pretty much every devtool I've used, Microchip & others, has had issues with flakiness when the target connection, or power is interrupted unexpectedly.I find pickit 3 (which I only use on 8 bit devices) to be reasonably OK most of the time, but ICD4 always falls over if target power is shorted, requiring an exit/restart of MPLABX

author: DavidAlfa
author_rank: Super Contributor
timestamp: August 13, 2021, 03:09:56 pm
content: Well, it might have been some gremlins inside the pickit.Changed to other pic model, mplabx updated the fw and completely bricked it.Flashing it with another pickit slightly worked, but neither mplab, mplabX or pickit 3 utility was able to connect to it. They saw it, but they freezed forever trying to connect.After a lot of fiddling around I found a workaround: Inmediately after flashing, I had to inmediately connect it to pickit3 utility and switch to mplab mode.If any other program connected to it before switching to mplab mode, it would brick it again.After that, I could ran the firmware update in MplabX. No issues with power, hanging, crashing, everythign like it should be.

author: AaronD
author_rank: Frequent Contributor
timestamp: August 13, 2021, 03:25:58 pm
content: Long thread that I didn't read entirely, but here's my experience:PIC has always had the best hardware features for the cost, but an awful CPU architecture as far as a C compiler is concerned. C was not the original design goal, and it seems like they're stuck with what they already had and won't change. So to use it well requires a proprietary compiler that is quite expensive for the full version. There is a free one, but it produces assembly so bad that it's been accused of purposely sandbagging to make the paid versions look even better. (actually, if you really know how a compiler works, you'll understand that the free version really is just the translation stage as-is with nothing after it, and that the optimizer really is that good) There are also community-supported compilers, but they don't get a lot of attention, and so they're still not as good as the proprietary one. It's too far different from a "standard" architecture for GCC to be modified to work.So PIC is excellent in value for hardware, but bad for development. Not really a problem if you develop once and then dump the same binary into millions of chips.AVR (both before and after MCP bought it) is exactly what GCC expects, so there's no reason to use MCP's version of it. Just get the free AVR-GCC and move on. It also runs 1 instruction per clock instead of PIC's 1 instruction per 4 clocks, but it requires more instructions to do some common things, so the benefit isn't quite as much as you might think. Most of the practical benefit is a boatload of RAM, and a NOP is 1/4 the time on AVR as it is on a PIC, so you can busy-wait more precisely. But it doesn't have as much on-chip hardware as a similarly-priced PIC. I see no reason why they can't put a PIC's peripherals around an AVR core for the best of both worlds...except that they wouldn't be able to sell their expensive compiler anymore.So AVR has a better CPU, which makes it easier to use as your first microcontroller, but so far isn't paired with as much hardware for the price.---Ultimately, Microchip is out to make a profit. They can't operate as a charity, or they'd go bankrupt and cease to exist. Can they make all of their profit on hardware and let hobbyists use their full-version software for free? Perhaps, but I don't think they're focused so much on hobbyists. Hobbyists are too low-volume to be profitable to a chip manufacturer, and if you offer something to them for free, then the large corporate customers can get it for free too. (a "non-commercial" clause in the license isn't as effective as you might think)It'll be interesting to see what the next generation does. The idea that those who learn on a given system will later decide to use it in production is very real, and those who are just starting to learn will choose the one that's most accessible to zero knowledge and almost zero budget in single quantities. So a manufacturer can't just ignore those people. Sure they're not profitable now, but they certainly will be if they're not driven away!---One more note:I see people complaining about the PicKit. I have one, and haven't had any issues so far, but I also found a free programmer that uses the GPIO pins of a Raspberry Pi:https://wiki.kewl.org/dokuwiki/projects:pickleI've only used that for one project so far, which is a permanent connection between a Pi and a fairly new PIC, but it works perfectly! Together with SDCC in Code::Blocks, I have a completely free toolchain that runs entirely on the Pi. Nothing at all from MCP except the chip itself. (SDCC still has some significant shortcomings, but it's a lot better than MCP's free thing!)

author: DavidAlfa
author_rank: Super Contributor
timestamp: August 13, 2021, 03:52:47 pm
content: I think they'll always have their place.They won't be super powerful, but they're so damn easy to configure and run, you can make a small project in less than 10 minutes... Reseting peripherals is a childs game, everything is so damn simple!For example, I made an astable timer for the reverse camera of a friend's car, the rear bulb signal has nasty pulses from the detection circuitry, messing with the camera power.It took me less than 10 lines to configure a 18F1330: INTOSC, x4 PLL, ADC, Timer0 and GPIO.Another 40 lines of code to read the potentiometer with the adc, adjusting the timer and making the state machine.It's just like a toy, a digital lego you can play with and get results in no time.Stuff gets extremely complex really fast when you with a modern arm cores and such.

author: Feynman
author_rank: Regular Contributor
timestamp: August 14, 2021, 06:35:30 am
content: The only thing I don't like about Microchip are the shitty dev-tools for their micros.

author: Howardlong
author_rank: Super Contributor
timestamp: August 14, 2021, 08:57:43 am
content: Quote from: AaronD on August 13, 2021, 03:25:58 pmThat's a fairly reasonable take, if discussing the 8 bit architecture, although functionally it's very well hidden from the end user in XC8, particularly the RAM banking: some other PIC 8 bit compilers it's a lot more obvious. You have to accept the the 4x clock is just that, and read through the marketing blurb with that in mind. The peripherals they cram in are impressive, some of which can relieve the CPU from tasks. In my line of work the low power aspects often come into play also, particularly sleep and MIPS/MHz performance.The 16 bit architecture is far more attuned to C, with a proper stack and frame pointer for example. It's far less prone to banking, on many of the lower end devices no banking's needed at all.One thing Microchip have taken their eye off the ball recently is power consumption across the range: older devices were much better in this regard. This is particularly since they have introduced the PIC18FxxQ and PIC16F152xx series, which no longer have specific low power 'LF' variants.One other thing that's taken a turn for the worse over the past couple of years is the datasheet format, where they've switched to a single column format from their traditional two column format. As a result the information is presented in a far less efficient way for both on screen and printed reading. One thing I always liked was that I could find the pinouts after scrolling past the first couple of pages, usually it starts by page 4, sometimes it's page 2 or 3. Now there's several extra pages of cruft, due to single column presentation, a couple of pages of double spaced ToC, and a frankly almost useless block diagram. The most common part of a datasheet anyone will refer to during development is the pinout.

author: AaronD
author_rank: Frequent Contributor
timestamp: August 14, 2021, 10:08:41 am
content: Quote from: Howardlong on August 14, 2021, 08:57:43 amI had a project at work with a PIC16F1454. (the smallest and cheapest I believe with a USB peripheral) By the time the application code was done, it was significantly over 1/2 of the code space. And it still needed a USB bootloader for field updates. So I had to be creative in how I did that, including the ability to bootload a new bootloader, while absolutely minimizing the chance of bricking it from the end-user's perspective without a programmer. (requiring a second attempt to download is okay, as long as that's always possible at *every* step of the process) That's where I learned that the XC8 linker is absolutely awful, even in the full pro version. It eventually worked like I wanted, and passed all the tests, but it was not fun at all.Our 8051 toolchain was much better at that...or maybe it was explained better. The on-site support guy that we got from Microchip left some to be desired as well; older guy that didn't really seem to know much more than we did, but that might have been a fluke. Nice guy, but technically useless.If you don't care where anything goes as long as it works, then you won't see any of that. But you probably *will* need to use the external programmer interface for any updates. (depending on what you're doing, that requirement might be a feature) Even a pre-fab bootloader needs to not be overwritten, which requires at least a little bit of linker code to not try to put stuff there, even if that bit of flash is protected otherwise. (hardware fuses, and the bootloader itself checking addresses)Quote from: Howardlong on August 14, 2021, 08:57:43 amMaybe they're relying on the flexible configuration to make the pinout mostly irrelevant??? That's not a very strong argument though, because that configuration has defaults, and you can't really move the power pins.

author: DavidAlfa
author_rank: Super Contributor
timestamp: August 14, 2021, 01:45:18 pm
content: What I can't understand is the PIC18 extended instruction set. It's meant for high level languages like C.The old mplab C18 did support it, but HiTech's PICC never did.Microchip bought HiTech, renamed it to XC8, and abandoned C18.Since then, Microchip gave zero f*** to improve that.So, the situation is that their own compiler can't use all the capabilities of their own devices. It's like a bad joke!I've read it was a try to compete against PICC. Since PICC was more efficient that C18 without using extended instructions they just remainded there, unused.Anyways, modern mid-range (Like 16F18323) have a better, new architecture that mixes a bit of everything. I guess these pic18 are just old.The new ones are impressive, the available peripherals is crazy. The 16F18323 packs a lot of them, costing barely 1€.

author: nctnico
author_rank: Super Contributor
timestamp: August 14, 2021, 01:54:08 pm
content: Quote from: AaronD on August 14, 2021, 10:08:41 amThis is where many LPC series microncontrollers from NXP really shine; most of them have well designed serial port bootloaders so you don't need any fancy programming hardware to do field updates.

author: Davor
author_rank: Contributor
timestamp: August 14, 2021, 03:59:12 pm
content: Quote from: DavidAlfa on August 14, 2021, 01:45:18 pmThere are new PIC18 series (Q40, Q41, Q43...).Price of 18F04Q40 is similar to 16F18323, but with 4x more RAM and flash, 2x speed and EEProm, 8x more stack, 12-bit ADC, 8-bit DAC, +-1% RC oscillator. Even errata is OK.

author: DavidAlfa
author_rank: Super Contributor
timestamp: August 14, 2021, 04:09:02 pm
content: They must be very new. Last time I searched for 14-pin tssop pics (few months ago) they didn't show up!Only the PIC18F06Q41 appears in RS Spain. 0.90€ +VAT.That's Microchip getting serious, DMA in a pic18!If they make a single-cycle instruction core like pic24/dspics... ouch!

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 14, 2021, 05:06:09 pm
content: Quote from: DavidAlfa on August 14, 2021, 01:45:18 pmI have used mcc18 with PIC18 MCUs, and it was fine AFAIR, but never used XC8. (Have used XC16 and XC32 on other PICs since then.)Are you sure XC8 never got updated by Microchip for better support of the PIC18? I admit I've never bothered to check.Why did they abandon mcc18? No clue. They probably wanted to redirect resources to XC16 instead. Maintaining a compiler is always costly. Dunno.

author: AaronD
author_rank: Frequent Contributor
timestamp: August 14, 2021, 06:46:23 pm
content: Quote from: nctnico on August 14, 2021, 01:54:08 pmI think you misunderstood me, but you still make a good point. There are some good pre-fab bootloaders for PIC and AVR too. But the problem with any bootloader is that it requires some non-zero amount of code space, and the compiler/linker for the main project can't be allowed to put anything there.Maybe other toolchains have an easy way to tell them that you're using a specific bootloader, and that's all it takes to reserve that space? (and maybe even include it in the initial binary that gets programmed the first time?) I haven't seen *that* from Microchip.---At any rate, that wouldn't have worked for the project that I mentioned above. Most projects can get away with a completely independent bootloader that:1. Has its own PC support app2. Takes complete control of the entire chip, and then3. Releases all of that control to the application codeBut this project had a rather small amount of code space for what it was trying to do, and a large part of that was for our USB stack. So I ended up sharing the same USB stack between the bootloader and the application code. Not a complete separation as is usually done. (for good reason!)Or depending on how you think of it, this "bootloader" never released control, and the "app code" was more of an "add your code here" function that was called just before the "bootloader's" main loop, another one that was called each time around the main loop, another one for USB communications that the "bootloader" didn't intercept, and a goto for the ISR since the "bootloader" and its USB stack were entirely polled. There were also some callback functions from the "app code" to the "bootloader" for USB communication back to the PC.So because I had multiple function calls in both directions (and a goto), all of them of variable size, I had to have both the "app code" and the "bootloader" in the same project (if you can even make that distinction anymore), and download both at effectively the same time to keep the linker happy. AND minimize the chance of bricking it in the field because the user unplugged it prematurely or whatever.I ended up with a 2-part download that always overwrote the "app code" section, a small amount of non-erasable assembly to copy that to the "bootloader" section at the top of flash if needed (this was the only chance to brick it), and a "bootloader" that checked to see if the fixed ISR target (immediately after that protected assembly) had a valid ISR in it based on its first instruction. If not, then don't call any of the "app code" functions! (Since that location could also be the start of a freshly downloaded "bootloader", I conveniently put some USB strings there. No chance of an ISR starting with a RETLW!) There were checksums too, so both the first instruction and the checksum of the entire section had to be good before it would be called "valid". The boundary between "app" and "bootloader" was flexible and could be communicated to the relocation assembly code, so we wouldn't be stuck with an unworkable boundary at some point in the future.From the PC's perspective, the sequence was:1. Download the new "bootloader" section (actually overwriting the old "application" section)2. Let it reboot, drop off of USB, and eventually reappear (during this time, it's being copied to the "bootloader" section)3. Download the new "application" section4. Let it reboot again, drop off of USB, and eventually reappearThe custom PC app was automated to do that, starting at any point in that process as needed. The state machine was driven by the reported version number from the "bootloader" and whether it reported having valid "app code" or not:Code:if (reported_version != current_version){download_current_bootloader();}else if (!has_valid_application){download_current_application();}else{use_with_current_firmware();}Maybe now you can see where the complexity came from.

author: nctnico
author_rank: Super Contributor
timestamp: August 14, 2021, 06:58:24 pm
content: Quote from: AaronD on August 14, 2021, 06:46:23 pmNo, the bootloaders in microcontrollers from NXP reside in a dedicated piece of ROM memory which (on newer devices) may also have an API to control peripherals as well. This bootloader is programmed at the factory and doesn't take any space from the regular flash. The big advantage is that you don't need JTAG or SWD to program the controller; just hook it up to a USB to serial converter and off you go.

author: AaronD
author_rank: Frequent Contributor
timestamp: August 14, 2021, 07:42:31 pm
content: Quote from: nctnico on August 14, 2021, 06:58:24 pmAh! I wasn't aware of that architecture. That's a really good idea!

author: Howardlong
author_rank: Super Contributor
timestamp: August 14, 2021, 08:21:52 pm
content: Quote from: SiliconWizard on August 14, 2021, 05:06:09 pmXC8 has always supported PIC18 as well as all the other 8 bit PICs. My XC8 licence was originally grandfathered in from my old C18 licence, but now I pay an annual maintenance fee... or at least I pay it when I need to (eg, new part support).Maybe the OP was referring to PIC18's extended instruction set (XINST)? I can't ever remember using that in recent years.

author: DavidAlfa
author_rank: Super Contributor
timestamp: August 15, 2021, 02:54:58 am
content: I was refering to the extended instruction set (XINST config bit) which was one of the major enhancements coming from PIC16, actually not supported by any compiler.Sure, the compiler works fine. But it's not using the full mcu potential.

author: Microdoser
author_rank: Frequent Contributor
timestamp: August 15, 2021, 09:00:03 am
content: It just struck me that the thread is titled "Why do people not like Microchip?" as opposed to "What do people think of Microchip?".It's like we all know we don't like them, but why?

author: Siwastaja
author_rank: Super Contributor
timestamp: August 15, 2021, 11:54:47 am
content: Quote from: Microdoser on August 15, 2021, 09:00:03 amThis is weird, like the "have you stopped beating your wife" question. I don't hate Microchip and never heard of anyone who really did. Some prefer other microcontollers, or ICs from other manufacturers.Sure, there always is someone who doesn't like some company, but in general, Microchip's been mostly fine and mostly "accepted" by nearly everyone, no? Same cannot be said about Maxim for example due to unavailability of their parts.I took the title of the thread as an exaggerated clickbait title which is OK to me, I never considered someone seriously thinks Microchip is generally disliked.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 15, 2021, 04:52:39 pm
content: Quote from: Siwastaja on August 15, 2021, 11:54:47 amYes, this was an exxagerated generalization. Still, many of us have indeed witnessed there was kind of two categories of people regarding Microchip MCUs, those that have used them, often a lot, and see the strong points, and those that have hardly (with bad experience) used them, or even never at all, based on prejudice. So it was still interesting to discuss why this would be so, and I think we managed to figure out a few points, some related to objective issues, and some mostly related to prejudice.Oh, and this said, all points "against" Microchip that were really considered here were about their MCUs. But Microchip makes a lot of other stuff, and even for those that don't want to or don't like their MCUs, they may still be using (and if not, they should at least have a look) other parts from them. One strong point of Microchip as mentioned above is the availability in general, and that of the high-temperature parts in particular, at reasonable prices.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 15, 2021, 05:36:52 pm
content: Quote from: SiliconWizard on August 15, 2021, 04:52:39 pmMy pointsapparently don't count.It is an attitude I have with several companies: I like their products, but dislike the company for reasons related to how they do business.Like I said there, it matters a lot what one means by "like Microchip"; and it seems many (most?) members here have brushed all that aside, instead speculating on why some other people have different opinions than themselves. Just silly chatter, that, in my opinion.

author: HB9EVI
author_rank: Frequent Contributor
timestamp: August 15, 2021, 08:52:57 pm
content: there's always something to like (and/or dislike) about almost every companylike I said, I dislike Microchips PIC compiler policy; but from my point of view they do harm to themselves with it. on the other hand they offer the same (old) chips over decades, which makes Microchip one of the more reliable supplier of semiconductors on the market.

author: spostma
author_rank: Regular Contributor
timestamp: August 16, 2021, 08:51:46 am
content: I read on another forum a post of a personal experience of the developer of the Proton development system(an early Arduino-like system for PICs) banging his head on the arrogant non-cooperative managers of Microchip:http://protoncompilers.com/index.php/topic,169.msg946.html#msg946

author: DavidAlfa
author_rank: Super Contributor
timestamp: August 16, 2021, 09:00:16 am
content: C'mon, The only really hateable companies are nVidia and Allwinner. The rest do ok-ish

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 16, 2021, 12:01:45 pm
content: Do consider how useful thereasonslisted for liking/disliking Microchip the company or the products in some of the messages in this thread are.Not only with respect to Microchip and its products, but overall, by comparison to other companies.Nvidia has cornered most of the asymmetric HPC domain (i.e., high-performance computing using CPU + another processor type, here graphics processors via CUDA; AIUI OpenCL is not nearly as widely used yet). Because almost all of that is done on Linux, it means sysadmins cannot really do any debugging/fixing of the issues themselves (unless they can duplicate the bug on a Linux machine with all open source components), and need to report the bug upstream to Nvidia devs, and hope they can do something about it – and the mean time, try to work around the issue. If you want to use CUDA, this is what you do; no "hate" involved.I won't ever use Nvidia cards on my Linux dev machines, but I wouldn't mind having a powerful rack-mounted HPC unit with a couple of Nvidia cards to do CUDA.Does that mean I hate Nvidia, or that I love Nvidia? No, it means I choose rationally.As to Allwinner, their business model is odd. They ignore copyright laws with gay abandon, which makes no sense –– unless they know they'll never expand outside China. And they are utter shit when it comes to the software side. Comparing their operations to e.g. RockChip (which is a very similar company), especially their software efforts, means I will definitely focus on RockChip-based SBCs instead of Allwinner-based ones, for my tinkering/development devices. (The other companies that I like for Linux SBCs are Amlogic and Samsung, since I can use fully open source upstream vanilla Linux kernels for these.)For tablets running vendor-provided software anyway, who cares? Not I; I choose my Android tablets mainly based on their display properties anyway.See? No hate. Butbackground information –– experiences, history, typical behaviour wrt. products –– to base ones own opinion on, means one can make a rational choice, knowing what to expect, what the likely problems and benefits are, instead of anemotiveone(which the "not like" in the thread title kinda implies to me).

author: AaronD
author_rank: Frequent Contributor
timestamp: August 16, 2021, 04:32:12 pm
content: Quote from: Nominal Animal on August 16, 2021, 12:01:45 pmHmm. I like a Linux box with Nvidia graphics. All free software, including the closed-source driver, but closed-source is fine with me as long as it's still free and it works. And both Linux and Nvidia can do *anything*, as opposed to Windoze/Mac and AMD graphics, that each have a specific use in mind and can do that REALLY WELL, but anything else is a barely-functional hack.Quote from: Nominal Animal on August 16, 2021, 12:01:45 pmBefore the Raspberry Pi 4 came out, I used a Banana Pi in a couple of projects because the hardware was (nominally) better than the Raspberries at the time. It had an Allwinner chip on it, and used its own derivative of Debian to make it work. After a lot ofwith far worse support than the RPi community, I was able to work around enough hardware issues to make it reliable, and those projects are still running today. Now that the RPi 4 is widely available though, I don't use Bananas anymore.I was in a Facebook group for a while for the Raspberry Pi, and every couple of months or so, a user post (not an ad) would come up (in the Raspberry Pi group) to promote a Banana Pi variant. It would get slammed down pretty quickly and reliably, sometimes for a laundry list of genuine basic technical problems with the product itself (onboard WiFi is the absolute dirt-cheapest speck of sand they could get their hands on, for one example, and it shows badly), but usually for the audacity to post *that*, *there*. It's like the Chinese don't understand Western culture at all, but keep trying anyway in hopes that something they still don't understand will stick.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 16, 2021, 05:26:45 pm
content: Quote from: AaronD on August 16, 2021, 04:32:12 pmYou mean "free" as in "no cost"; my definition is different ("libre"). There is also an open-source driver, noveau, which may or may not work for given Nvidia hardware, but does not provide CUDA compatibility (I believe).Quote from: AaronD on August 16, 2021, 04:32:12 pmNo; for typical web-browsing and video-watching needs, built-in Intel graphics in Linux work just fine too. Yes, video playback is properly accelerated nowadays, with Nvidia/Noveau/AMD/Intel drivers in Linux.For ARMs, Mali-400 and Mali-450 are supported by theLimaMesa drivers for Utgard-based hardware; some other Mali versions are supported by thePanfrostMesa drivers, if one wants to run an accelerated Linux desktop on ARM. Exact support, and whether a binary blob is needed or provides better video performance, depends on the exact hardware; but Samsung, Amlogic, and RockChip at least seem to be trying to get fully open source support for their System-on-Chip implementations in Linux. (Which makes very much long-term sense, maintenance and support-wise, if you make your money by making and selling those SOCs, and not charge for SDKs and dev support too, like e.g. Microchip is trying to.)(Although only business success will really tell which approach actually made most sense, of course! If it makes business sense, it makes business sense; no way to argue around that.)Quote from: AaronD on August 16, 2021, 04:32:12 pmI'm not sure these companies areinterestedin understanding. RockChip seems to understand it pretty well, pushing support for their hardware upstream to Linux kernels, although some of their devs still do seem to prefer to push binary blobs out via their GitHub account instead of doing development in the open, so perhaps there indeed is a cultural aspect. Then again, many Western companies have the exact same attitude (just look at Linux-based routers and WiFi Access Points), so maybe not.I blame the middle management for keeping it up, and upper management not caring about the long-term effect it has on the brand and their products. Same for all other embedded appliances.(Then again, sometimes the software support is deliberately time-limited, to ensure customers will shift to the next hardware version; hopefully from the same vendor. Problem is, the risk of customers choosing a different vendor is unknown, and ifanyvendor decides to provide much longer support for the same cost and successfully communicates this to their customers, they're likely to grab significant market share from the "augh; I have to get yet another router/AP" customers, which are an increasing portion of the entire customer base.)What really surprises me every time I look at provided Linux-based firmware images for all sorts of appliances, is the utterly shitty quality of the systems integration (i.e., the filesystem images, the open source components used to provide the necessary services in the Linux userspace, and so on). It isn't difficult to do better, so who the hell are they hiring to do this stuff? First timers? High-school kids? I dunno.

author: AaronD
author_rank: Frequent Contributor
timestamp: August 16, 2021, 06:29:27 pm
content: Quote from: Nominal Animal on August 16, 2021, 05:26:45 pmI meant that the commercial paid platforms each have a specific use in mind, and to try and use those platforms for anything other than their intended use is a barely-functional hack. There are lots of other platforms that are far more capable as true general-purpose machines, and you've only mentioned some of them.Quote from: Nominal Animal on August 16, 2021, 05:26:45 pmI think you're right. And I think it's a big hindrance to their progress in taking over the world, if they keep getting rejected for not understanding.Or maybe they want to change our culture instead??? If the average consumer gets stupid enough, that might actually happen, as the cheap stuff encourages that culture or even requires it to make it work...(yay, conspiracy theories!)Quote from: Nominal Animal on August 16, 2021, 05:26:45 pmYeah, everything's geared towards making a bucknow. Run that through several layers of ramifications, and you're not really buying a product at all; you're buying the marketing. The product is simply a prompt for the marketeers to go nuts with, and it shows.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 16, 2021, 08:51:29 pm
content: Quote from: AaronD on August 16, 2021, 06:29:27 pmOh; right.Quote from: AaronD on August 16, 2021, 06:29:27 pmYup. For the masses, thebrandas marketed is indeed everything; the actual properties seem to be secondary, if that.What I'd like to know, is how much Microchip marketing efforts have affected those who use their parts for commercial purposes. Including freebies and directed marketing, or lack of (for those who decided tonotuse Microchip parts).That's a difficult question to answer, though, because humans extrapolate, and brands are the marketing tool that targets that human behaviour precisely: "if you likedthatthing, here is another thing from the same brand that you'll like too!". It is very difficult to analyze oneself and even accept that some decisions are based on emotive reasons like good marketing, instead of objective comparisons or such. Mainly, this means it is difficult to separate what one considers "good experience" and what is the result of marketing and not finding any faultyetto bring one down from the high of having a yet another tool one feels one likes. Myself very much included.(Those we like to call "fanboys" are the ones who reject the concept of "fault" in their preferred "brand" altogether. I've only noticed one or two in this thread, early on, speculating that anyone having a negative opinion must be inexperienced or misinformed.)

author: nctnico
author_rank: Super Contributor
timestamp: August 16, 2021, 10:24:41 pm
content: Quote from: Nominal Animal on August 16, 2021, 08:51:29 pmDoes marketing actually work on engineers? In the end it is about the numbers and a good workflow. Isn't marketing mostly targeted at technically inept managers that might be tricked into thinking a product suddenly cuts development time in half or cut component costs?A long time ago I gave a Freescale 'Coldfire' microcontroller a try because the sales rep kept nagging my boss about it touting the Coldfire microcontrollers are cheaper. So we got a devboard and I wrote some simple code for it. Much to my surprise the devkit didn't include a way to get firmware into the controller.For that you needed to spend another several k euro for a special JTAG interface. That just didn't make sense. The NXP LPC series ARM controllers we where already using have a factory programmed serial port bootloader and a simple USB to UART board + software tool allowed to do field updates as well (life can't be easier). So the Coldfire devboard went back for a refund.

author: DavidAlfa
author_rank: Super Contributor
timestamp: August 16, 2021, 10:39:21 pm
content: That's crazy. These companies smoke serious stuff.For sure, you want these expensive, huge, ultrafast programmers for production.But you should also make a los cost device for the everyday thing.Otherwise, 10 programmers developing different firmware sections, each one with a $1000 programmer in their desk just for debugging simple stuff?No need to be a genius here, after showing the middle finger several times, the company proceeds to buy microchip/atmel/st $20-50 programmers, end of story, goodbye Freescale!I remember Maxim 8051-based mcus from ages ago already embedding uart bootloader.Microchip, meh, there are cheap tools available. Although they're getting more expensive every time.I remember the pickit 2 was $25, the pickit 3 was $40, and now the pickit 4 is $70!

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 16, 2021, 11:16:48 pm
content: Quote from: nctnico on August 16, 2021, 10:24:41 pmMarketing that is appropriately directed at engineers, yes. Things like samples, journals/articles by their engineers and hardware designers, access to higher-tier support, and so on.My point is that even people who are thing-oriented rather than people-oriented, (specific types of) marketing still works. When it is done effectively, thing-oriented people don't even notice it; they just find that "I've somehow always had a suitable device at hand".Note that I am including everything that is done to increase sales that does not modify/affect the product sold, as marketing; not just advertisements.Do you really believe you are immune toeverythingcompanies do to increase sales (excluding actual modifications to their products)?I know I am not (immune).Quote from: nctnico on August 16, 2021, 10:24:41 pmMostly, yes, because it is those inept managers that make the most purchase decisions across the industry.

author: AaronLee
author_rank: Regular Contributor
timestamp: August 17, 2021, 02:13:51 am
content: Quote from: Nominal Animal on August 16, 2021, 12:01:45 pmAllwinner pricing is great for the features you get. Unfortunately they're only willing to provide tech support to customers ordering huge quantities. I suspect that a person's view of the company would depend a lot on if they're just a hobbyist or a small quantity customer vs a huge quantity customer. Regardless though, their ignoring copyright laws is still an issue.RockChip is much better, though in my case it was due to having an inside track in order to get proper documentation that I couldn't for Allwinner. Price-wise, I think Allwinner is better though.For Samsung, I've had terrible luck. Their documentation has been very poor, and their product life cycle is very short. Though it's been over 10 years now since I last touched their CPUs, so things might have changed, but I'm definitely not willing to risk spending months of my time ever again on developing for a Samsung CPU only to trash that time and need to switch to a different CPU with proper documentation. For Samsung memory chips though, I have no issues.My comments are based on my experience with using the bare chips inside a design, not with SBC's designed by the chip maker or a third party. So comments about pricing is for CPU pricing, not SBC pricing.

author: hulk69
author_rank: Contributor
timestamp: August 17, 2021, 07:32:28 am
content: I have used most of the brand out there ST, Ti, Atmel, Renessas, NXP...And to be honnest the C drivers library offered by Microchip were the worst one maybe with the exeption of NXP.From my experience PIC programing tools are shockingling bad (PICKit 3/4 or watever they call it nowdays). Where I worked there used to be around 10 of those dead units in a basket.Other than that their prices in europe are good but ST microcontrollers (which are better in almost every way) are cheaper. So for me Microchip micros are used for maintening old projects never on new one.My rating of Microchip 8 bits microcontrollers is as follow:Price: 9/10Availibility: 10/10Ultra Low Power: 7/10Functionalities: 2/10Programing tools: 1/10Free IDE: 1/10Drivers: 0.5/10

author: nctnico
author_rank: Super Contributor
timestamp: August 17, 2021, 07:38:48 am
content: Quote from: Nominal Animal on August 16, 2021, 11:16:48 pmIf a product really is better and/or cheaper then I like to know about it OTOH if it is just a load of BS then I discard it. It is all about the numbers.For example: where is comes to connectors and inductors I use quite a bit from Wurth. But that is because they are competitively priced, their quality is OK and they usually have a lot of stuff in stock locally. I do enough volume for Wurth to send a sales rep to me once a year. Still that doesn't prevent me from looking somewhere else; Wurth parts are not always the best fit.

author: MIS42N
author_rank: Frequent Contributor
timestamp: October 06, 2021, 11:33:41 am
content: I am in a love/hate relationship with Microchip. I am a hobbyist and program 8 bit PICs in Assembler. I think MPASM is great and now they have stopped supporting it. So now if I send code to someone I have to explain download MPLAB X 5.35 to compile it. Then there is the problem of programming. My latest effort I decided I would make a bootloader that worked with Tera Term Xmodem. Then the program can update itself. Not quite there yet - Xmodem protocol works OK, reading and decoding the hex formats works OK, now have to do some defensive stuff to stop the bootloader overwriting itself.As an aside, There's a lot of reading hex characters and converting two characters into one byte. I came up with a bizarre way of doing it, I haven't seen it anywhere else. It doesn't check the data and alpha hex (A-F) has to be in upper case. It reads the hex output of MPLAB just fine:Code:SWAPFCHAR1,WADDLW0x55BTFSSCHAR1,6 ; test if letterADDLW0x71; 2nd hex charADDWFCHAR2,WBTFSSCHAR2,6 ; test if letterADDLW0x07

author: Jan Audio
author_rank: Frequent Contributor
timestamp: October 06, 2021, 02:31:26 pm
content: Microchip offers all the DIP.I cant imagine starting this hobby with STM32 and a microscope.Yes the software sucks, could have been much better if i was the boss of microchip.They was thinking we could integrate online so we can have microtransactions also.Just add java depency because everybody have the latest computer and the latest windows and a good internet-connection.Next step : like everybody does, sell your personal info.They start asking for your email already if you want to download the latest compiler.They denie, i see right trough, why else they ask info for something free ?Info-data is the new gold, dont forget.

author: woofy
author_rank: Frequent Contributor
timestamp: October 06, 2021, 05:24:23 pm
content: Quote from: Jan Audio on October 06, 2021, 02:31:26 pmMicrochip compilers are free to download, you do not have to give them an email address.https://www.microchip.com/en-us/development-tools-tools-and-software/mplab-xc-compilers#Downloads

author: Jan Audio
author_rank: Frequent Contributor
timestamp: October 07, 2021, 01:37:00 pm
content: Ah better, they removed it.I was getting suspicious.Gotto be hard about these things, people dont care normally.

author: AaronD
author_rank: Frequent Contributor
timestamp: October 07, 2021, 02:35:56 pm
content: Quote from: MIS42N on October 06, 2021, 11:33:41 amI'll...just take your word that that works. I tried to prove it to myself before I left yesterday morning; I could see a little bit of a pattern emerging, but not the whole thing.You assembler guys are something else. You might be the best bit-twiddlers on the planet, and you produce the most compact and obfuscated code that I've seen, even compared to an optimizing compiler. That's great, as long as the rest of us just take it as a black box that "just works" and don't try to wrap our minds around how.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: October 07, 2021, 03:58:00 pm
content: I mean it doesn't look too bad to me, even though I'm not familiar with PIC ASM; but that is the catch, you have to know what things mean, and step through it and reason it out -- I know a few instruction sets, so it's not too alien to me. If you don't know ASM at all, it's just a bunch of cryptic incantation; you sure as hell aren't going to know where to plop it into a project!The constants 0x55, 0x71 and 0x07 look like offsets related to ASCII code, namely the ranges of letters, or the lack thereof. Although I'm not sure how exactly they relate ('A' == 0x41 is a long way from 0x55?), I'd have to read the instruction set to see what exactly is being done.So, that is to say: even for experts in related fields like myself, it may not exactly be useful, or even intelligible; your sarcasm is understandable!A relevant example in C (if not an equivalent; but given the above is only 7 instructions, I don't think it does nearly the full thing either, just a snippet from the middle of such) might look like the two functions here,https://github.com/T3sl4co1l/Reverb/blob/master/console.c#L275Whereas in my linked C example, the constants are explicitly readable -- single-quoted letters are parsed as numeric constants, so you get precisely the range of letters converted as is written. (Does use the assumption that ASCII is well-ordered, which, fortunately it is; this might not always be the case, like in the bad old days of EBCDIC!) Note it also checks range more carefully, which might not be needed, and will take more instructions (to be exact, the whole function is 40 instructions on avr-gcc 8.1.0 -Os; that includes the helper function, which gets inlined; for a complete function that operates on a string, and even with GCC 8's very poor AVR optimizing, that's quite reasonable).Tim

author: NorthGuy
author_rank: Super Contributor
timestamp: October 07, 2021, 09:52:00 pm
content: Quote from: T3sl4co1l on October 07, 2021, 03:58:00 pmThat's quite straightforward actually. Letters 'A' to 'F' are encoded with codes 0x41 - 0x46, while numbers are encoded 0x30 to 0x31. Like symbol = number + 0x30. It would be nice if 'A' was encoded as 0x3a, 'B' as 0x3b etc, but the creators of ASCII were dumb and didn't do it this way. But we can fix it:Code:uint8_t get_byte(char ch, char cl) {if (ch & 0x40) ch -= 7; // 'A' is changed from 0x41 to 0x3a, 'B' from 0x42 to 0x3b etcch -= 0x30; // convert to a numberif (cl & 0x40) cl -= 7; // same for the next charactercl -= 0x30;return (ch << 4) + cl;}Now, we can re-write this in assembler. It'll be a little bit dumb at first, as a non-optimized compiler:Code:movf ch,w ; load chbtfsc ch,6 ; the next command is executed only if ch is a letteraddlw 0xf9 ; subtract 7addlw 0xd0 ; subtract 0x30movwf ch ; store the resultmovf cl,w ; load clbtfsc cl,6 ; the next command is executed only if cl is a letteraddlw 0xf9 ; subtract 7addlw 0xd0 ; subtract 0x30movwf cl ; store the resultswapf ch,w ; shift (no barrel shifter, so swap instead)addwf cl,w ; and add to get the resultNow we can optimize it a bit. First, the cl calculation only used additions. Therefore, instead of storing the ch value and adding it at the end, we can simply keep it and add everything to it. This saves 3 instructions:Code:movf ch,w ; load chbtfsc ch,6 ; the next command is executed only if ch is a letteraddlw 0xf9 ; subtract 7addlw 0xd0 ; subtract 0x30swapf WREG,w ; shift the resultaddwf cl,w ; add cl to the resultbtfsc cl,6 ; the next command is executed only if cl is a letteraddlw 0xf9 ; subtract 7addlw 0xd0 ; subtract 0x30Then, we can join the loading of ch with the swap. This will requite some intelligence in tweaking the constants to make sure the effect is the same, but will save one more instruction:Code:swapf ch,w ; load and shift chbtfsc ch,6 ; the next command is executed only if ch is a letteraddlw 0x8f ; subtract 1 from lower nibble, add 9 to upper nibbleaddlw 0xfd ; subtract 0x30, which is 0x03 after the shiftaddwf cl,w ; add cl to the resultbtfsc cl,6 ; the next command is executed only if cl is a letteraddlw 0xf9 ; subtract 7addlw 0xd0 ; subtract 0x30Finally, there are two unconditional additions, which can be united into oneCode:swapf ch,w ; load and shift chbtfsc ch,6 ; the next command is executed only if ch is a letteraddlw 0x8f ; subtract 1 from lower nibble, add 9 to upper nibbleaddwf cl,w ; add cl to the resultbtfsc cl,6 ; the next command is executed only if cl is a letteraddlw 0xf9 ; subtract 7addlw 0xcd ; united additionNow, the only thing left is to remove comments. Lo and behold:Code:swapf ch,wbtfsc ch,6addlw 0x8faddwf cl,wbtfsc cl,6addlw 0xf9addlw 0xcdYou can re-write it in C as well, only C won't have a swap:Code:uint8_t swap(uint8_t r) {return (r << 4) | (r >> 4);}uint8_t get_byte(char ch, char cl) {uint8_t x = swap(ch) + cl;if (ch & 0x40) x += 0x8f;if (cl & 0x40) x += 0xf9;return (x + 0xcd);}

author: MIS42N
author_rank: Frequent Contributor
timestamp: October 07, 2021, 10:55:45 pm
content: Northguy has the same solution as piclisthttp://www.piclist.com/techref/microchip/math/radix/a2b-2h8b-pf.htmwhich, if I had found it earlier would have saved a bit of time. It is a more logical approach using twos complement addition to do subtraction (PIC doesn't have a subtract literal from register, so the equivalent is add a twos complement). In essence, it converts the ascii 4k to ascii 3k+9, then removes the 3s in the last line. I was not so smart. Knowing the ascii 4k had to have 9 added, I added it to every character (the combination of 0x55 and the 4 in 4k) I then adjusted the 3k numbers which now were 3k+9 TO 4k by adding another 7. The end result is the same, the cycles are the same, the execution time is the same.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: October 07, 2021, 11:47:02 pm
content: Speaking from experience with avr-gcc at least, the compiler can recognize a swap -- even with optimization sadly, GCC will still mask the result if you do e.g.(x >> 4) & 0x0f, even if you don't use the high nibble in subsequent operations; however, usingx >> 4 | x << 4or something like that, will properly elucidate the SWAP instruction. So it's sometimes worthwhile to add both terms to the expression, even if you aren't using one of the results.Possibly the same is true of PIC compilers.Tim

author: NorthGuy
author_rank: Super Contributor
timestamp: October 08, 2021, 12:57:34 am
content: Quote from: MIS42N on October 07, 2021, 10:55:45 pmThat's the same method as yours. I actually tried to explain how your method can be derived, but it came out with reverse coefficients.0xcd + 0x8f + 0xfd = 0x55 - here's your 0x55 for the case where both chars are letters0x55 + 0x71 + 0x07 = 0xcd - here's 0xcd from my post for the case where both chars are digits

author: AaronD
author_rank: Frequent Contributor
timestamp: October 08, 2021, 03:27:13 pm
content: Quote from: NorthGuy on October 07, 2021, 09:52:00 pmI wouldn't quite say that. They were just optimizing string functions. See how capitals and lowercase line up nicely with each other? It took some padding to do that, so they used the punctuation characters for the padding, and followed some patterns for those too. And it still doesn't take much effort at all to convert two ASCII hex characters to a byte, as shown in the previous few posts.I think it would only add one instruction to handle both upper and lower case: When you know it's a letter, force one bit to make it known which case it is, then add the appropriate offset for that known case. For comparison, bounds-checking everything would probably double the code size.Also interesting are the control characters that were used originally to control a teletype, or "remote-controlled dumb typewriter". We hardly use any of them now:carriage ("print head") returnline (paper) feedhorizontal tab (there's a now-barely-used v-tab too; both of these together make tables somewhat easier)escapebackspacedeletebut it's interesting to see that the rest of them are still part of the modern standard.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: October 08, 2021, 04:14:38 pm
content: Don't forget bell!Indeed, outside of specific applications (various types of terminal emulators, or original equipment of historical interest) you're pretty free to use 0-31 however you like, minus the most conventional exceptions; often some in-band coding is needed, and they were originally assigned precisely this task.Tim

author: MIS42N
author_rank: Frequent Contributor
timestamp: October 08, 2021, 10:50:22 pm
content: Quote from: T3sl4co1l on October 08, 2021, 04:14:38 pmXmodem protocol still uses SOH ACK NAK and EOT. It neatly gets around the problem of control characters in data by always sending 128 bytes of data. For something cooked up for a specific purpose decades ago it's nice to work with. I chose to use it because it is half duplex, the code can disable interrupts and run entirely with polling which means the bootloader can overwrite the interrupt vector. And Tera Term supports it and is freeware.

author: westfw
author_rank: Super Contributor
timestamp: October 08, 2021, 11:57:11 pm
content: QuoteASCII (1961) somewhat pre-dates the current usage of "hexadecimal" (which first showed up on IBM machines that didn't use ASCII in 1964)Hexadecimal has a more interesting history than I would have thought. Apparently letters other than A-F, or even entirely new symbols, we used before IBM...https://en.wikipedia.org/wiki/Hexadecimal

author: nigelwright7557
author_rank: Frequent Contributor
timestamp: October 31, 2021, 10:49:57 pm
content: I have used PIC's for 35 years.Its a case of matching the right PIC to the job.Sometimes an 8 pin PIC will do the job.Other times I need a lot more power and lots of peripherals so use PIC32MX series.Not everyone gets on with MPLAB X. Its a bit of a mess but things can be found if you dig deep enough.The pickit can be a bit flaky at times.I found the snap programmer works better.

author: brichards42
author_rank: Contributor
timestamp: November 07, 2021, 02:17:44 pm
content: I decided to have a look at MPLABX so downloaded, installed, unchecked provide anonymous data, unchecked check for updates.I then turned on my firewall and disabled all output with logging, and found it took over 4 minutes for the ide to start, all the while in the background it repeatedly tried to connect to:13.226.204.19184.51.39.36224.0.0.25152.218.216.23452.92.162.17172.247.206.9Maybe all the other major players do this to but but seems like we just want to give the impression you have the option to run without 'pinging' various cloud services (for whatever purpose).

author: poorchava
author_rank: Super Contributor
timestamp: November 08, 2021, 12:15:52 am
content: I started looking at Microchip again, since I can't buy any STM32 nowadays, and C2000 are just a too much of a pain to use for a general purpose microcontroller.I've used them until like 7...8 years ago. Stuff that used to throw me off:-all 8 bit PICs (10, 12, 16, 18) are SHIT. Much slower than AVR, non-vectored interrupts, memory banking, etc. The only reason I'd fathom to use them would be either some ultra low power application, or something that would use some of their weird (but admittedly - interesting) peripherals like CTMU.-dsPIC30s were total CRAP. I recall one of those drawing so much current it was actually very warm. And this wasn't some shorted GPIO.-all parts had frequent read/modify/write problems-silicon bugs. My favorite was some PIC24H which was advertised as 'USB OTG OMG WTF' and the first paragraph in the errata was 'USB doesn't work'.- I recall that onc upon a time they were aggressively marketing paid compiler versions that resulted in almost 50% smaller code... That's when I looked at the disassembly and found out that the free version was deliberately adding dummy instructions to blat the code and slow it down.... Great... Maybe it's different now, I don't know.

author: westfw
author_rank: Super Contributor
timestamp: November 08, 2021, 01:38:59 am
content: QuoteThat's not entirely true. The PICs take 4 clock cycles per instruction (vs 1 on the AVR), but they also frequently allowed clock speeds about 4x faster than similar AVRs.QuoteThere was a lot of debate on whether it was adding dummy instructions, or whether their "no optimization" code was REALLY dumb. (avr-gcc-O0code is also really horrible.) If you assume that the unoptimized code was aimed at some abstract VMish thing that put a C-like architecture on top of the PIC decidedly un-C-friendly CPU, it was almost within the realm of believability. It was pretty awful, though.QuoteIt is in fact much better now. Notgreat, but no longer in the "this is completely horrible" range.

author: AaronD
author_rank: Frequent Contributor
timestamp: November 08, 2021, 01:50:11 am
content: Quote from: poorchava on November 08, 2021, 12:15:52 amI wouldn't go quite that far. Yes, the CPU is awful compared to AVR, and the almost-requirement to use a proprietary compiler that is focused more on commercial profit than on hobbyist accessibility (it never was GCC-compatible and probably never will be), makes it even worse. But they seem to have a lot more peripherals for the price than AVR, even for the bog-standard stuff. So if I can make the peripherals do all the work and keep the CPU as just a supervisor with only a small amount of less-critical "glue logic", then that makes a PIC the better choice.But for data-processing kinda stuff, AVR wins by a mile in the 8-bit world! It was wonderful, having learned on PIC, to use an AVR for the first time to make a DMX lighting controller. A little bit of peripheral work just to move data in and out, and TONS of memory and number-crunching. Just to declare a single, 2-dimensional array (scenes x channels) to occupy several kB would be a tall order on a PIC, but the AVR was like, "Yeah, sure! What else ya want?" Not to mention working through all of that data within one refresh cycle.(PIC's do tend to have higher maximum clock rates, but not *that* much higher. 32MHz/4=8MIPS for PIC, vs 20MHz=20MIPS for AVR. Plus, AVR likes to include a single-cycle multiplier more than PIC does.)Quote from: poorchava on November 08, 2021, 12:15:52 amGood to know that. I've been casually looking for a good DSP chip myself, that supports 8-ch bidirectional audio + HID as a USB device, plus some audio ADC's and DAC's, and can use my own code to get the latency way down for the analog-to-analog signal path. (most libraries use a block size of 64 samples or so, but I need single samples) I'm guessing that's not it.Quote from: poorchava on November 08, 2021, 12:15:52 amNever had a problem with that myself. Maybe because I learned on them and treated that oddity and its workaround as "normal"? I'm not even sure what it is.Quote from: poorchava on November 08, 2021, 12:15:52 amThat's good! I wouldn't put it past them though. Too much marketing pressure to get it out NOW!???Quote from: poorchava on November 08, 2021, 12:15:52 amThe official explanation is that all versions initially output the "free" assembly by concatenating prefab entries from a lookup table that each have enough wrapper code around them to guarantee that they all work in every context as-is, and then the paid versions go back and clean that mess up according to how much you paid for it. In that sense, it's not artificially stuffing the output with dummy instructions, but yeah, the completely uncleaned code that you get from the free version is pretty bad.But the chip does end up doing what the source tells it to do. In that sense, it's a "good" compiler, but ONLY in that sense.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 08, 2021, 02:53:31 am
content: Quote from: AaronD on November 08, 2021, 01:50:11 amWell, the dsPIC33 series is much better, more recent and more powerful. If you were interested in the dsPIC series.The dsPIC30 series was really not that bad. It was ALOT more powerful, and easier to use than anything Microchip had released before. But yes they were power hungry and would heat up quite a bit. Absolutely no reason to go for them these days, unless the extended VDD range up to 5.5V could do something for you. Otherwise, dsPIC33 is the way to go. Of course if you want a 16-bit Microchip dsPIC. There are certainly many other and more powerful options these days.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: November 08, 2021, 03:20:39 am
content: Quote from: westfw on November 08, 2021, 01:38:59 amWhich IS, AFAIK, the explanation with GCC -- the IL is particularly ill-suited to AVR so makes rather boneheaded decisions, and performs little optimization once it's there [which, I think you're already keenly aware of!]. And that kind of makes sense, for all the machines GCC targets. It seems to have improved a bit since GCC 10 or so; 8 was actually doing worse on a number of cases than 4 or 5. (I've personally more than doubled the speed of some DSP routines with asm, versus avr-gcc 8.1.0.) It would be... surprising? If a PIC-exclusive tool weren't optimized towards that family, but yeah, who knows.Tim

author: MIS42N
author_rank: Frequent Contributor
timestamp: November 08, 2021, 09:11:17 am
content: Quote from: poorchava on November 08, 2021, 12:15:52 amI like the PIC16F1455. I wished I could use the USB interface but the design requires a 10MHz clock and that is incompatible with the USB module (it likes 48MHz sub multiples). The processor has a PLL clock multiplier so internally runs at 40MHz. I use the 40MHz clocked 10 bit PWM, and capture events to 25ns accuracy in firmware using Timer 1 running at 40MHz gated by a comparator at 1.9V derived from the internal voltage reference (which allows an interface with a low voltage part without a level translator). I also switch between the external and internal oscillator on the fly. Write to flash memory. Use one read only pin as a software 9600 baud input, because I use the UART to run a user interface. There are 7 interrupt handlers handling around 50,000 interrupts a second. All that in a part that draws 5mA and costs less than $2.I avoid dealing with the vagaries of the C compilers by writing assembler. Plenty of spare memory so I added a bootloader that allows direct reprogramming by hex files using Tera Term's Xmodem transfer.Yes, the banked program and data memory model can get in the way, but it is not hard to get used to it. The 1455 has some useful enhancements compared to previous 8 bit PICs. Interrupts automatically save and restore many registers, which allows IRCs to be quite short. The stack is exposed and can be programmatically manipulated. Fixed data can be stored in program memory and the full 14 bits retrieved. Index registers can be used in linear memory mode to address data memory as banked or linear, and also program memory. Finally introduced an ADDWFC - add with carry - which was missing from older PICs (which made for some arcane arithmetic). And indexing can have pre/post increment/decrement or use an offset.

author: Rudolph Riedel
author_rank: Regular Contributor
timestamp: November 08, 2021, 10:20:53 pm
content: As it was mentioned I took a peek at the datasheet for the PIC16F1455.And as expected this thing has an accumulator architecture with only 1 working register.AVRs have 32 8 bit registers and a couple of these work as pairs for 16 bit operations.This is why AVRs are quite a lot faster even when a 8-bit PIC runs at four times the clock, there are less cycleswasted to shuffle data around and a C-compiler has a lot to work with.Well, I went with ATSAMC21 and ATSAME51 a while ago.I just installed MPLAB-X 5.50 to give it a try - and MPLAB-X still can not even generate an empty project for ATSAMC21 that compiles.Still no, I rather swith the manufacturer than going MPLAB-X.My recent impression is that Microchip stopped releasing anything new that I would actually find interesting.Like an upgraded ATSAMx5x with Cortex-M33 or an upgraded ATSAMC21 with Cortex-M23.

author: commie
author_rank: Frequent Contributor
timestamp: November 08, 2021, 10:47:59 pm
content: Quote from: Rudolph Riedel on November 08, 2021, 10:20:53 pmNot entirely true, AVR runs 1 clock cycle per instruction, whilst PIC complete 4 cycles per instruction but AVR's run at 2 to 4 times slower than the PIC's, so you might find there's not much in it between the two.

author: MIS42N
author_rank: Frequent Contributor
timestamp: November 09, 2021, 02:08:03 am
content: The trouble with comparing 8-bit AVR and PIC is they are completely different, difficult to make real world comparisons. I have programmed both in assembler so have a bit of a grasp of what goes on. The 32 registers (AVR) versus one register (PIC) seems like a big win for AVR until you notice the only instruction to move data in and out of the AVR registers is load and store. AVR direct load and store take two cycles (at say 16MHz) versus PIC one instruction of 4 cycles at say 40MHz. PIC wins by a small margin. But use indirect addressing and AVR wins. PIC allows some instructions to work on memory directly (DECFSZ location,f) not using the working register at all. Or combine two operations into one (ASLF location,w - shift left and load). PIC has indexing like the AVR, the 1455 has two index registers very similar to the AVR X,Y registers but with the advantage they are saved during an interrupt and restored on return. And so it goes...I think AVR would have an advantage using C language, compilers are better at juggling multiple registers than people. But I think there is no clear winner, it depends on the application. I wanted to use an AVR for my application but it didn't have the right abilities. So I chose a PIC instead. A while back I wrote a Top Octave Generator using an AVR, there is no way a PIC would do it. Horses for courses.

author: Rudolph Riedel
author_rank: Regular Contributor
timestamp: November 10, 2021, 04:58:37 pm
content: Quote from: commie on November 08, 2021, 10:47:59 pmYou left out the important part when quoting me:>And as expected this thing has an accumulator architecture with only 1 working register.>AVRs have 32 8 bit registers and a couple of these work as pairs for 16 bit operations.So even if an AVR and a PIC need the same amount of time for a single operation that does the same thing,the AVR still will end up running faster since it can run calculations with 32 registers instead of only one register.With an accumulator architecture the program spends a significant amount of time pushing data in out of thisone working register while a more modern architecture with more registers can just hold values in these registers.And less instructions to do the same thing is not only faster, but shorter as well.When I found the datasheet for a PIC16F84 over twenty years ago in a binder,I just put back the binder, did not want annother accumulator architecture back then, still would not use any.I did enough 6502 assembly way back and had to use 8085.

author: mfro
author_rank: Regular Contributor
timestamp: November 10, 2021, 05:21:32 pm
content: Quote from: AaronLee on July 23, 2021, 01:08:49 amIf something appears too good to be true ...

author: commie
author_rank: Frequent Contributor
timestamp: November 10, 2021, 09:03:57 pm
content: Well, I see typical Microchip marketing strategies with the latest AVR's, that is to make AVR's slightly faster and offer them at ultra low prices and start to increase prices for mature AVR's. Replace the programming protocol from isp to updi, so now we all need to dig into our pockets yet again. I'm sure third party prog. pod manufactures pay dividends towards Microchip for changing to a slower prog. protocol.This makes electronics, in general, a joke.

author: Simon
author_rank: Unknown
timestamp: November 21, 2021, 06:02:04 pm
content: If you are refering to the latest incarnation of the mega 0 series (original X-mega) I think they have done well there. Now at last an AVR that OK can do 24MHz, maybe no one asked for that but they will work down to 3V at full speed unlike the older AVR stuff and even the mega-0 they introduced which while based of a 3.3V osly xmega had the traditional speed limitations at anything but 5V. I now see why they were having A and B type peripherals as now C and D types have emerged. I've not used any but they look like a worthy replacement to the mega 0 serieos and they won't require code rip up's for the new stuff.Were x-mega SPI? I think there may be a number of false claims out there about microchip as haters like to hate. One user here told me that the XC8 compiler is just a rip off of the AVR-libC and GCC, well no not really, it was atmel that originally forked the compiler and libraries and when you install atmel (now microchip) studio you were just installing a commercially provided for free version. Sure they are probably not all nice but I don't think they are as bad as people make out.The programmer on the new devices is the very same ICE introduced by atmel, they just put the price up although at the moment if you can buy one at all just shut up and be happy you can buy something

author: AaronD
author_rank: Frequent Contributor
timestamp: November 21, 2021, 08:41:52 pm
content: I have a complete development environment on a Raspberry Pi that supports both PIC and AVR, with all-free software. Code::Blocks IDE for both, and the process splits from there: PIC's get the SDCC compiler, and AVR's get the public version of AVR-GCC. Each also has its own open-source programmer (PICkleandAVRdude) that I've set up to use different GPIO pins, so they can coexist on the same Pi. LVP-only for my version, but the configurations also appear to support a separate transistor circuit to control a +13V Vpp rail if you want to do that. Add some scripts into Code::Blocks to fire the appropriate terminal commands, and you can control the entire process from inside the IDE.What I have is not a debugger, only a programmer, so you have to do your debugging the old-fashioned way, but for those like me that learned that way anyway, that's fine.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: November 21, 2021, 09:21:09 pm
content: Quote from: Simon on November 21, 2021, 06:02:04 pmSPI, as in PDI or ISP? Yes. My ancient AVRISPMKII handles XMEGA.UPDI is just async serial, bidirectional on a single pin. It doesn't require a programmer, just a UART, and a resistor to resolve direction. The comment above yours, I think is either assuming too much about the new protocol, or trolling. (Personally, I've tested it with a new AVR-DA chip, and was pleasantly surprised to use a MAX232 of all things, as a "programmer".)To clarify, XMEGA is 1.6-3.6V, with frequency derated down to 12MHz at 1.6-1.8V, up to 32MHz at 2.7V. The onboard PLL can multiply up to 128MHz (derated to 48MHz at LV, over the same voltage range), and is used at that rate for timers and some other peripherals, while the CPU is limited of course (I haven't tried overclocking it).AVR-DA is 24MHz (48MHz PLL for TCD only) over the full 1.8-5.5V range, at least, as near as I can tell. Interesting that it isn't dependent, or at least I've just not been able to spot the curve; it's a big datasheet.QuoteIt's also integrating with PICkit and various onboard (demo board) things. The tool is open and in active development:https://github.com/microchip-pic-avr-tools/pymcuprogIt was a bit of hair-pulling figuring out which tool to use (conclusion: pyupdi shows up first in searches, but it was more of a demo, with pymcuprog being the integrated and well maintained package; well, the documentation wasn't the best, but it's improving).Tim

author: Simon
author_rank: Unknown
timestamp: November 21, 2021, 09:35:58 pm
content: Quote from: T3sl4co1l on November 21, 2021, 09:21:09 pmI think full speed is down to 3V not 1.8V, there are two variants although for the life of me I don't get it, one proclaims to be for analogue integration yet both seem quite similar. One is more explicit about 24MHz at 3-5V, the other is just vague but I assume the same as they are out of the "same bag".

author: rpiloverbd
author_rank: Regular Contributor
timestamp: December 05, 2021, 11:41:16 am
content: I have no such utter disliking . But I find arduino boards and AVR Microcontrollers (Despite the fact that microchip has taken over Atmel) more user friendly.

author: Simon
author_rank: Unknown
timestamp: December 05, 2021, 03:19:37 pm
content: Atmel set out with the AVR to appeal to the smallest entity by being the first to make the tools easy, accessible and cheap if not free in the case of the IDE. Microchip are still flogging the dead horse of selling code optimization licences in an age where one just buys a bigger chip or does not use their shit free compiler that is so lame and finds something else.Different companies do give different vibes. STM for example seem to make a point of trumping everyone on price but hen having read some of their lawyer authored "data sheets" that seek to not tell more than they tell I would not touch anything of theirs unless my volumes where so high that the added hours were worth it. Then I wonder why the subcontractor that produced a design for my employer before I joined used a 72MHz MCU and 2 external ADC's despite the MCU containing an ADC. Granted that for the intended volume lots of time spent on it would have been a waste of money but you would think that it would be natural to use the ADC built into the STM, or maybe they came with so many caveats that it was not worth spending 10x the time picking through the detail to find out what you were dealing with.

author: nctnico
author_rank: Super Contributor
timestamp: December 05, 2021, 03:22:24 pm
content: Probably the reason is much more simple: the performance of the integrated ADC likely wasn't good enough for the application. x bits of resolution doesn't always mean getting x bits resolution and / or accuracy.

author: Simon
author_rank: Unknown
timestamp: December 05, 2021, 03:26:25 pm
content: Quote from: nctnico on December 05, 2021, 03:22:24 pmreading a potentiometer in 1% steps is something the AVR ADC could do. So 2 potentiometers - 2 external ADC's at £1 each.

author: glenenglish
author_rank: Frequent Contributor
timestamp: December 06, 2021, 05:06:15 am
content: PICs are old microarchitecture crap from the 70s. they are junk.dsPIC33 are excellent (and nothing like PICs). they are a REAL DSP. excellentAVR are probably the finest 8 bits micros ever madeAVR-DA is pretty much the same, refreshed architecture with some refreshed peripherals and memory options. The LUT block is curious.Use Codevision for writing for AVR.I went to STM32 in 2012, after 12 years with AVR. I've been hopping around again now with microcontroller shortages, back using AVR-DA, refreshing price for simple jobs compared to the smallest STM. The LPC800 series from NXP are a useful basic CPU, c heap and peripgeral rich option , also.Started writing Z80 in 1979..

author: woofy
author_rank: Frequent Contributor
timestamp: December 06, 2021, 09:04:09 am
content: Quote from: glenenglish on December 06, 2021, 05:06:15 amA lot of cpu's and controllers from the 70's have gone the way of the Dodo. PIC's are not only still with us they are flourishing, made and sold in huge numbers.Maybe there is a reason for that, one that goes beyond an architecture that does not matter when programming in C.

author: Simon
author_rank: Unknown
timestamp: December 06, 2021, 12:58:04 pm
content: Quote from: woofy on December 06, 2021, 09:04:09 amPIC's are still used because they have been used before. It's easy for one decision made in the past for one reason to haunt a project, person, company, whatever for decade's to come. People will use what they think everyone else is, guess why atmel were so liberal when they started, they needed to gain mass adoption. If people already have code for a PIC they will not necessarily move to another device to start all over unless there is a good reason to as it's effort and reward. The simple answer is PIC got there first, but it was overtaken to such an extent or at least microchip were that they bought atmel which meant they had the power to unleash the AVR architecture or bury it forever, the choice they made is very telling and of course it got them into ARM devices.

author: Codemonkey
author_rank: Regular Contributor
timestamp: January 07, 2022, 04:18:41 pm
content: Quote from: Simon on December 05, 2021, 03:19:37 pmI remember attending one of the first AVR seminars in the 90's when the AVR line was launched. They gave you a free eval board (STK200 with an AT90S1200) included in the price of the seminar. If you wanted to use C, you were expected to pay £££ for the IAR compiler.I recall the seminar costing about the same as the ST eval board I had already been using for ST62T10 parts which was less than £100 from RS components, so at the time it wasn't really any more accessible or cheaper than the competition.Things only got better for hobbyists when WinAVR got released with its port of gcc in the early 2000's, and i'm not even sure that was anything to do with any Atmel staff. The Arduino stuff all came later still.Their biggest selling feature (and the reason they took off so well) was that they were totally FLASH based at a time when most competitors like PIC etc were either EPROM or OTP so development was much faster.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 07, 2022, 06:30:24 pm
content: Good lord.The PIC line of MCUs is one of the largest with a lot of configurations, packages and whatnot, while having reasonably good documentation and performance (when they meet your requirements).And "PIC" doesn't mean anything. There are hundreds of references of PIC MCUs with several completely different architectures, from 8- to 32-bit. As we said before, another plus is that they have a large number of parts that can operate up to 150°C, which is not that common with other vendors. So, still a number of reasons for using them.And for those who have missed what has happened at Microchip over the last 25 or 30 years, maybe they should have a look. Just saying. So why does it have to turn into a PIC vs AVR war? This "war", if there was ever any, is long over. While the AVR parts are still used a lot in the "hobbyist community", I see them very rarely used in commercial products these days, while the PIC (in all forms again from 8- to 32-bit) are.Oh, and the PIC MCUs have been flashed-based for over 25 years now, and, as I said, over the years, with various architectures. You'd need to go back to 25+ years to make all this discussion relevant. It is of no relevance in 2022.

author: Siwastaja
author_rank: Super Contributor
timestamp: January 07, 2022, 07:14:13 pm
content: Quote from: SiliconWizard on January 07, 2022, 06:30:24 pmI think AVRs werenevereven remotely popular in commercial or industrial products. The market share just never was there. Thanks to the hobbyist and university appeal, maybe there was a short period of time of these hobbyists/students graduating, getting professional, and designing in an AVR, but this became an eyeblink (maybe around 2006-2007) in books of history, because said professionals then went on to more affordable and capable ARM MCUs. Arduino really saved the day for AVR, continuing that hobbyist appeal for the next generation of hobbyists. But the difference is, Arduino hobbyists either stay Arduino hobbyists, or become professionals who design in an ARM. They won't magically change into AVR-loving professionals, it makes no sense. So commercially, it was game over. For PIC product families OTOH, the "traditional" professional use that have lasted for decades, is still here to some extent.QuoteYes, but now it's an interesting historical curiosity, which is also easier to discuss because fanboyism in long over, and former fanboys of either camp can come together and laugh at their past selves.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 07, 2022, 07:22:57 pm
content: Quote from: Siwastaja on January 07, 2022, 07:14:13 pmYou really think it's over? I'm not completely sure, reading discussions about this on various forums. =)

author: AaronD
author_rank: Frequent Contributor
timestamp: January 07, 2022, 07:47:39 pm
content: Quote from: SiliconWizard on January 07, 2022, 07:22:57 pmI would LOVE to see the AVR's GCC-friendly architecture and loads of memory, paired with the PIC's vast array of flexible peripherals! If we can just get that, I think we'll be set...(oh, but of course then they couldn't sell their expensive compiler...)

author: Simon
author_rank: Unknown
timestamp: January 07, 2022, 08:21:26 pm
content: Quote from: Codemonkey on January 07, 2022, 04:18:41 pmYou got the seminar and the board, how was the board not cheaper? seminars cost money you know.

author: Simon
author_rank: Unknown
timestamp: January 07, 2022, 08:52:43 pm
content: Quote from: SiliconWizard on January 07, 2022, 06:30:24 pmi think by PIC most people mean the 8 bit range when comparing to AVR that is only 8 bit. There are AVR's that will do 150C, most in fact. i have used an automotive 150C rated atmega168 which is the same as the arduino uno part, I'm sure the 328 was also available in automotive. For some reason the automotive were always a section of their own never mentioned in polite company but when you find them it's like "why the hell didn't they just list the 150C rated parts as part of the 0-70, 20-85 and -40-125"But then Atmel were not terrific at marketing, yes the arduino saved the AVR, another happy accident along with someone choosing to port a free compiler, I doubt it had much to do with atmel but the gcc compiler that comes with atmel is the atmel tool chain, NOT the one you will download as avr-gcc, they did make changes themselves.As for the PIC/AVR war, meh, I'm not one for spending hours fretting over arguing about one versus the other. I'm just pointing out why one is not dying out. Microchip bought Atmel, and has made very clear they don't want to kill the AVR, quite the opposite. 3 new lines of AVR have been released.At first microchip made the same pathetic ballsup they made with PIC and started to call it all one name even though the parts were quite different so the atmega 0 series just get confused in google with all other atmega's that are completely different beats as the 0 series is if anythintg the xmega.They seem to have finally learnt with the new AVR DA and DB series although not quite.

author: NorthGuy
author_rank: Super Contributor
timestamp: January 07, 2022, 10:16:43 pm
content: Quote from: Simon on January 07, 2022, 08:52:43 pmThey also renamed new variants of Atmel's ATSAM chips to PIC32CM

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: January 07, 2022, 10:43:06 pm
content: Quote from: glenenglish on December 06, 2021, 05:06:15 amThere's also the PIC32, which isn't based on the 8-bit PIC either, but rather on the MIPS architecture. They're capable parts, if mostly overshadowed by the juggernaut of ARM Cortex-M parts.

author: Simon
author_rank: Unknown
timestamp: January 08, 2022, 08:12:34 am
content: basically both microchip and atmel are shit at marketing, atmel gave the same thing too many names and microchip call different things the same name. No I would never go looking for an ARM based part called PIC, what a bunch of useless tossers!

author: T3sl4co1l
author_rank: Super Contributor
timestamp: January 08, 2022, 10:24:18 am
content: Quote from: AaronD on January 07, 2022, 07:47:39 pmMega-0 and AVR-DA are absolutely bristling with peripherals. I'm not too familiar with what special things PICs have, but they may be on par now, give it a look.Tim

author: Kleinstein
author_rank: Super Contributor
timestamp: January 08, 2022, 11:59:32 am
content: Quote from: Simon on January 07, 2022, 08:52:43 pmAtmega 0 series and AVR DA, DB are essentially slightly newer version of the Xmega. So the principle part was already there before they were bought by Microchip. The CPU is only slightly improved. The main difference is in the periphery including the event system.Quote from: AaronD on January 07, 2022, 07:47:39 pmWith the AVR CPU the memory access beyound 128 kB is tricky and no longer easy for the compiler. If you want lot's of memory, this aera is already lost the ARM based µCs. The 8 bit µCs are made for the small jobs - like those 90% that get away with 16 kB or less.

author: Howardlong
author_rank: Super Contributor
timestamp: January 08, 2022, 08:15:56 pm
content: A bit of a Microchip boi myself, but this seems more than a little out of step.A 2022 hardware debugger at 1980s prices. $1799.https://www.microchip.com/en-us/development-tool/DV244140Admittedly it has plenty of corner case functionality, but for 95%+ of debugging scenarios I just don’t get it.If you need it, you need it, I guess.

author: westfw
author_rank: Super Contributor
timestamp: January 08, 2022, 11:25:19 pm
content: QuotePeople keep saying stuff like this, but in 2015 (the last year before the Microchip acquisition) Atmel had over $330M of revenue from their microcontrollers.Not to be sneezed at, and quite unlikely if they served "mostly hobbyists."

author: AaronD
author_rank: Frequent Contributor
timestamp: January 09, 2022, 03:01:09 am
content: Quote from: T3sl4co1l on January 08, 2022, 10:24:18 amJust googled the datasheets. Only got one of them. Google really goes off in the weeds with the Mega-0! The AVR-DA is distantly approaching the PIC in terms of hardware peripherals, and it has some interesting features that the PIC doesn't directly, like an event system that gets its own chapter instead of a bunch of direct connections between everything, but probably nothing that I couldn't "Erector-set" a modern PIC to do in hardware too. They're really flexible! Especially if you do treat it like an Erector set, and not strictly like it might have been envisioned. If you manage all of that well, you can almost have it do everything in hardware; and so the famously-awful free compiler running at 1/4-speed anyway, doesn't seem all that bad anymore because it hardly does anything anyway beyond the initial setup.The PIC's gated timer, for example, doesn't appear at all on an AVR, to my knowledge, and it can be used separately as a free-running timer and a flexible-sourced interrupt trigger. Or you can use them together to measure a pulse width in hardware, and present it to the ISR as the stopped timer value. Or you can use them to add a delay to an event trigger, by connecting the source to the gate and the destination to the timer overflow, and setting the timer to overflow "soon". Etc. And that's just one peripheral!A general-purpose DMA would be a big game-changer, but the closest that either of them comes to that is dedicated to the USB peripheral alone, and it can only talk to a user-configured block of memory, not to another peripheral.One of my recent projects deliberately has both a PIC and an AVR in it, talking to each other. The PIC manages a digitally-controlled analog signal path that has some precise timing involved to switch things in and out of circuit, relative to an external clock, so all of that timing is done in hardware with the CPU just "playing housekeeper" around it. The AVR uses its fast instruction rate to semi-bit-bang a fast pulse-width-based serial protocol. It uses the PWM module to create the exact timing in hardware, but the protocol is so fast that about all it can do (with GCC fully optimized for speed at the expense of size and still refactored until it worked) is get the next bit, choose one of two constants, busy-wait a few cycles for the PWM interrupt flag (less than the interrupt latency), set the new duty-cycle, and repeat. Once it's done sending a frame, it can let the main loop catch up. Everything else is set to be slow enough that it can be ignored for an entire frame of this without clobbering a hardware buffer.I might have been able to do that with the PIC's modulation peripheral instead, which is essentially a 2:1 MUX with some extra flair, but I only thought of it just now. It's meant to take a bit stream as the selection input, and switch between two other signals, like DC and a defined frequency for On/Off Keying, or two different frequencies, or whatever. In this case, I would give it two fixed-duty PWM signals, both clocked in reference to the bit stream so that each bit gets exactly one period.(Maybe both PWM's use the same timer, and one is also fed to the SPI's clock pin in slave mode, then the SPI's data goes to the modulator selection? Then I'd only have to keep up with bytes and not bits! If it also had a DMA, then this entire software driver would be obsolete! Just set it up and let it run, with a static array as its input.)That capability in peripherals is what I was looking to see paired with a boatload of RAM and a fast, capable, and open-source-supported 8-bit CPU. Like I said above, they seem to be getting there, but it's definitely not complete yet.Quote from: Kleinstein on January 08, 2022, 11:59:32 amI guess "small" depends on where you're coming from. I learned on PIC16's that had just over 300 bytes of RAM and maybe 1k of Flash. Then for the same price (before MCP bought them), I could get an ATmega with 4x the instruction rate for the same external clock (no PLL either way), 4k of RAM, and more Flash than I could ever want! That was in exchange for less variety in peripherals, but it still had the SPI that I needed to run a bunch of shift registers for things like buttons and LED's, and it had *two* UART's so I could dedicate one to a DMX transceiver and still have my terminal-spew debugging. Wow!Then I filled up the RAM with a giant 2-dimensional array of scenes and channel-structs, and used the hardware multiplier (another wow!) to scale each channel's value to its scene master and then the final output to the grand master. The other data in the channel-struct was to facilitate some "cheater functions" for when you didn't want the standard "highest takes priority" mixing scheme. And the main loop would actually get through all of that, in the time it took to send an interrupt-driven DMX packet! (no DMA) Wow again! Plus mapping the small physical control panel to different parts of the array like the layers/pages of a digital audio mixing desk, etc. I could never have even dreamed of doing that on the PIC's that I knew.So to me, that AVR was huge! Big chip for a big job! It felt more like a PC than the cramped PIC's that I was used to...but the PIC's still had more capable peripherals, and from what I've seen somewhat recently, they still do.Quote from: Kleinstein on January 08, 2022, 11:59:32 amAbsolutely yes! But the massive problem there is a quantum leap in complexity, so that a reasonably-skilled 8-bit guy is still completely lost in that world. I gather that the 32-bit world is much more library-driven than the 8-bit world is, but the old habit of rolling your own everything so that you know exactly how it works and why it's failing at the moment, dies hard.This might be a case of me thinking differently from the rest of the industry, but I have also yet to see a decently-documented library. The alternative is understanding multiple 1,000+ page datasheets, some of which are hard to find because you're supposed to use the library instead...

author: Kleinstein
author_rank: Super Contributor
timestamp: January 09, 2022, 09:04:39 am
content: Going from a 8 bit µC to a 32 bit one is not that bad. I just did that step with not much trouble.It still takes some time, with a new IDE and new peripherials. I don't think the step from AVR to PIC (or the other way around) would be much easier.Using libraries for the HW interface can add a bit to this, but one is not forced to use them. It may still be a good idea with USB or similar more complex parts and the initialization.Things may get more troublesome if you want to program in ASM - the 8 bit µCs are usually still very predictable in the execution time, something that is often lost with caches and buffers with the 32 bit µCs.The main point I missed was a good simulator to check out the HW details in a simulation instead of debugging the real HW, which can be a bit more tricky. Maybe here I was spoiled from the really good simulator in AVR studio.

author: Siwastaja
author_rank: Super Contributor
timestamp: January 09, 2022, 11:32:12 am
content: Quote from: AaronD on January 09, 2022, 03:01:09 amI absolutely see what you did here, but you could consider going to modern microcontrollers. Because many in STM32 series for example come with as many and as advanced peripherals as the PICs, butadditionallyhave enough oomph in the core - that would have been a single-chip solution. And as nctnico would definitely agree with, single-MCU project is easier to manage than dual-MCU project.Recently I had to implement a stupid legacy 1970's IBM protocol with quite high bitrate, for which there is no special peripheral available onanynormal microcontroller on market - some old 8-bitters from early 1990's, which are neither PIC nor AVR is the only thing on the market. So had to bitbang it. And because the stupid protocol has details like bit stuffing to handle, the amount of code to handle that is more than 1 or 2 lines. So what are the options? If I had to do it 10 years ago, I'd have a separate AVR or PIC there, for which I would write the code in assembly bitbanging the clock and data signals exactly,andcommunicate to another MCU with more relaxed timing. Today? Just use Cortex M7 and run the stupid protocol in interrupts, written in plain "high level" C. 555kHz interrupt rate sounds impossible from the viewpoint of 20 years ago. Today you can just do it. Best thing - everything else works as usual. Data processing, logging, SPIs, CAN communication, etc. It's just one more interrupt source, eating some % of CPU time and increasing worst-case jitter of lower priority operation by some µs.Similarly, I have built a software defined switch mode converter where I couldnotget the hardware to do "everything" despite the good set of peripherals, but had to resort to ISR running for every cycle - and do that at high switching frequency (maybe 300kHz). Again, enter Cortex M7 and let the brute force handle it. No need for separate chip; the same chip did handle communication, image sensor access and processing, two three-phase BLDC controllers, accessing six inertial measurement units, doing navigation and whatnot.So CPU processing power is not only for processing audio or images or whatever like that. It is helpful in low-level IO. It allows you to replace a tight ASM implementation (which is a lot of work to implement; AND totally blocks the CPU from doing anything else, driving into dual-MCU design) with interrupt-based FSM, leaving enough CPU time for everything else. After all, 12 cycles of interrupt latency at 400MHz equalshalfa clock cycle at 16MHz. (Threading model, using a multitasking operating system, is another alternative to that interrupt-based FSM, but I prefer the bare metal way, unless I need fully implemented communication and filesystem stacks from the OS.)

author: Simon
author_rank: Unknown
timestamp: January 09, 2022, 01:01:51 pm
content: The CPU is of little importance, apart from the fact that AVR is 4 times faster at executing code compared to the PIC - the 8 bit PIC that is I could not care less what the CPU is as long as I know how many bits it is and have a compiler for it. This is what I never get about the fuss of one versus the other. AVR executes faster at the same clock rate end of. Then it's just a case of the peripherals. Clearly given that microchip are releasing entire new ranges of AVR based micro's means that they do think it's a worthy CPU and I suspect that if people stop buying the 8 bit PIC's they will happily stop waking them the same as the "legacy" AVR stuff that had the same peripherals but not identical. For example if you look at the tiny and the mega ADC it's all the same, but the bit settings in the register of the same name on both are different for the same voltage referencethese day manufacturers are standardizing these peripherals which is why we now have counter types A, B, C and D. It means very clearly that if you have code that works for one of those counters, it will work for one of those counters, no matter which AVR it is on.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: January 09, 2022, 01:04:25 pm
content: Quote from: AaronD on January 09, 2022, 03:01:09 amHuh, go figure...Example part is a '3208, here's the mfg page,https://www.microchip.com/en-us/product/ATmega3208or see the rest of the family from there.QuoteDA's timer D has some pretty interesting features, including generating and accepting events; I'm not sure about something like masked clocks, but there are duty cycle capture modes (you still have to do the division in software, but the period and width are measured in hardware anyway).QuoteXMEGA A-series have DMA (and some of the larger ones in lower-letter series?). I haven't used it, but it looks pretty rich, pages of registers. So, you can probably pull tricks like one channel driving the others for rich scripting behavior, or maybe even Turing completeness, I have no idea. Not sure about DA and family; at least not the 64DAxx I was looking at.There's also the CCL (configurable custom logic), which a lot of PICs have I think; and, integrating with the event system, you can get a lot of logic and sequential functionality that way.Something kind of unique that I've seen on a few PICs, SMPS control -- you can build a peak current mode control for example, almost trivially; similar functionality I think is constructible with timers and events. Probably at greater expense to hardware resources -- that is, you're tying up a whole timer and a couple event channels to do it, and maybe that limits what else you can do -- but it's also not too common I would guess, that you need to make use of even a fraction of the available resources.QuoteAh... interesting to note that, whereas MPLAB intentionally cripples its output; avr-gcc is just not very good at it. I've clocked it at about half the speed of hand-optimized assembly, at least for DSP (YMMV for other activities). GCC is good at optimizing, but it's done entirely on the internal representation (GIMPLE), and the target architecture is simply translated from that with little postprocessing (AFAIK?). It does very well for ARM and x86 -- of course, these are the most highly developed branches, or at least, I would guess -- but AVR and such, differ pretty significantly from the IR, and so there's a lot of wasted busywork, like, shifting around register allocations, extending sign into registers that aren't ultimately read, etc. And it only inlines 8x8 MULs; anything larger is sign-extended and called out to library (e.g. __mulhisi3). So any kind of arithmetic can be a challenge to optimize, short of assembling it yourself.On the upside, the ISA is pretty reasonable, the main inorthogonality being some instructions limited to upper sets of registers (i.e. r16-r31, etc.). As a load-store architecture, it's rather verbose, so maybe not all that pleasant to purely assemble in.I think the same is kind of true of PIC as well, just in different ways; everything has to pull through the W register, but you have fast page access and that. Dunno how adaptable it is, putting ASM with PIC-C. (What even is the compiler's ABI, how does it deal with hardware stack and page access? I haven't read any on it. Not that I care to; just that, this is critical information to be able to do that.) Instructions are "slower" too (~4 clocks/ins), but the clock is typically much higher so they're comparable in that respect. (Heck, same is true of competing ARMs -- those lacking pipelining and cache!)QuoteSounds like something that should perhaps be expanded out into SPI frames or something instead? -- but obviously this isn't enough info to tell. Especially tricky if it needs perfect timing; these devices rarely(?) have buffered SPI so there will inevitably be dead time between frames, while the loop/interrupt latency cranks through. DMA can help, but may still suffer from latency due to bus contention. (In which case, a bus matrix may pay off -- which most of these have, I think, but you're still limited by priority access to SRAM or the like, as both DMA and CPU will be needing that from time to time.)Siwastaja's example of bit-stuffed protocols would be the kind of example that, while you could transmit it via SPI (I mean, given plenty of other assumptions, too), the amount of cranking required to prepare the next frame is nontrivial. And might not be easily tamed with lookup tables -- do mind, you can easily pack in a 64kB table into these devices, as AVR's PGM space is 16-bit address and width, so supports 128kB without fumbling with extended addresses* (up to 384k are available).*Except you'll still be fumbling for that extra bit because LPM (load from program memory) fetches a byte at a time. But if you place the table entirely in "high" memory, you probably don't have to touch the extended address register (RAMPZ).Heck... y'know, they could've easily made that a load-word instruction instead, and loaded adjacent registers (e.g.LPM r16:r17, Z+), or even removed the choice and make it implicit (say r0:r1, like the destination of MUL). Or put in byte and word variants. Shrug, it is what it is. I digress...QuoteThe problem that occurs here, is that, no one wants to deal with the complexity, of course -- so you have a cornucopia of options to choose from, none of which is especially better than the others. If you stick to the mfg tools (e.g. ST's CubeIDE stuff), they'll handle all this for you with a few switches allocating the hardware resources and such, and zoop -- code generation, there you go, add user code and you're off. Oh, and don't mind that 50kB bloat that you've just linked into your "blinky" application. I mean, they give 128kB+ of Flash on these things, but they also seem to do a damn good job using it up for you, as well.And as I recall, not a lot of that bloat even drops off with -flto, it's not just superfluous crap, it's getting called from somewhere, somehow.So, if you want to pare down the bloat, or speed up init, or just do things slightly differently from the official ways -- you're on your own.One would hope for a sort of resource compiler, that doesn't just generate code snippets, but actually writes just the functions and initializers you need. But that would be a tremendous amount more work, to construct and test and debug and support, on top of the hardware selector, on top of the IDE, on top of whatever libraries and compiler support you need to get your new chips into mainline projects (GCC, libc, CMSIS, whatever). And it's only to support... people like us? Just so we can save a few bucks avoiding the upscale MCU that's more profitable for the manufacturer anyway? It feels intentional, but it's really just the coincidence that we're on the exact opposite end of mainstream development.Speaking of profits -- these fancier AVRs tend to be rather expensive besides. Like, ATXMEGA64D3 is a bit over $4. ATMEGA3208, $1.25. AVR64DA64, $2. Ye olde ATMEGA328P is $1.50, and ATTINY402 from $0.50. They're making some improvements in the newer lines, and, I don't know offhand if XMEGAs were ever cheaper, if they're being phased out by raising prices or something; but the older classics clearly have staying power, like the MEGA and TINY. Clearly, XMEGA's been priced well above competing ARMs (e.g., ATSAME, STM32F0, etc.), and that's one of the smaller parts in the family even.And, however that compares with PICs, you'll know better than me offhand, heh.Tim

author: AaronD
author_rank: Frequent Contributor
timestamp: January 09, 2022, 07:38:57 pm
content: Wow! Thanks Siwastaja and T3sl4co1l! Just goes to show how much I need to get into the 32-bit world. Now if I can just wrap my head around the config...

author: Siwastaja
author_rank: Super Contributor
timestamp: January 09, 2022, 07:54:19 pm
content: Quote from: AaronD on January 09, 2022, 07:38:57 pmI went STM32 directly from AVR and didn't change my workflow or mindset in any way. No libraries, no IDE, no code generation - also no problems, after the initial shock and lack of proper tutorials at the time.It's still the same. Look up registers in the reference manual, think, write code. It's almost a decade now, and the "cool kid" way of the internet forums has changedat leasttwice during that time. The fact I'm doing it "wrong" doesn't change, but how to supposedly do it "right" is a moving target. Make your conclusion and choose between what you already are familiar with, or a new strategy / toolset you need to relearn every 5 years.Sure, higher end controllers offer more possibilities, and with more possibilities, there is more complexity, but that doesn't fundamentally change the workflow in any way. Ignore people who say that full paradigm change or using libraries isrequired. That is an acceptable way to work, of course as evidenced by many doing that, but it isn't the only one.Documentation of a modern M7 device might be 5000 pages where an AVR is 500 pages, but that is only because it has many peripherals you never use anyway. Given the project complexity isn't increased, the added mental weight from some STM32H7 device, compared to an AVR, is maybe 3-4x, not many orders of magnitude.This extra "mental weight" consists of small things like having to write a correct value into FLASH waitstate control register, set up PLL clock dividers and multipliers and voltage scaling values, configuring memory regions in linker script however you wish to use the various separate memories available to you... and so on. But it's still within a screenful or two of code, it doesn't take forever to learn. Fundamental process itself is the same. It's like if you learned to drive in a town with population of 10000, going to a bigger city of 100000 might be a bit demanding, but you can make it, one intersection at a time.Actually I could say the biggest surprise to me was to learn what "linker script" is, despite the concept being half a century old. It's just that avrgcc had always generated (or used the right one) for me. With more advanced controllers, there are reasons why "one size fits all" linker script is not supplied automatically by the compiler. When I started with STM32, I simply didn't find a proper example linker script, and instead found a broken one which "kind of" worked, causing me a massive headache. Now I think you can pretty easily find example linker scripts from the examples by the MCU vendors, no need to trust random hobbyist websites.ataradov (https://github.com/ataradov/) has a good set of simple no-bullshit MCU starter projects. I haven't used them but at a quick glance, I can confirm his approach is sane; a good reference resource.

author: NorthGuy
author_rank: Super Contributor
timestamp: January 09, 2022, 08:55:41 pm
content: Quote from: AaronD on January 09, 2022, 07:38:57 pmThis is a myth than different worlds exist. All MCUs are roughly the same. If you can work with MCU A, you can work with MCU B using the same principles. All is very similar - how to arrange things in time, how to divide work between CPU and peripherals, how to think and plan before writing code. If something looks complex to you, 99% of the time this is because you don't know how it works. Once you figure this out, it will not look so complex any more.Choosing an MCU is not a matter of getting into a particular "world", but rather reconciling your requirements against a particular MCU. Often, important characteristics have nothing to do with the MCU internals at all, like you may want a very small MCU, an MCU which is easy to route, an MCU which consumes very low power, or whatever. Most of the time, you envision how you would do things then you select the MCU which can do what you have envisioned.

author: AaronD
author_rank: Frequent Contributor
timestamp: January 09, 2022, 09:34:24 pm
content: Quote from: Siwastaja on January 09, 2022, 07:54:19 pmHaha! I do things "wrong" all the time. I've heard it called the "hacker mentality", where most people look at a device and think, "What does this do?", but a hacker looks at it and thinks, "What can I make this do?" Of course, it's "all wrong" compared to the original intent, but I got something cool out of it and it actually works pretty well!Quote from: Siwastaja on January 09, 2022, 07:54:19 pmInterestingly, I spent several weeks beating my head against the wall about an 8-bit linker script. My company was making a clone of its own gadget, not really a port because both the chip and the circuit were so different, from an 8051 with USB to a PIC16F1454. Using the pro compiler for the PIC, the final project was still over half of the Flash size, and we wanted to update ALL of it over USB using our existing tool and its protocol. Not that hard to implement the protocol, but how to update ALL of Flash when we were using over half of it, while keeping it "brick proof" through a random power loss? (the user might have to re-load the firmware to make it useful at all again, but at least it should still have enough to do that)I ended up with a custom bootloader of sorts that contained the USB stack and main loop and never released control. Instead, it had a bunch of application functions - a "main" function that gets called inside the main loop, the single ISR, and the USB comms that the bootloader didn't grab for itself - and it would only call them if it knew it had a valid application section. It could download a new copy of itself, run the checksum, then jump to a protected bit of assembly to copy that to where it's supposed to be and then jump to it, and then the new "quasi-bootloader" could download the new app section and run the checksum again.Both sections were part of the same project so that the function calls would "just work" as usual, and some explicit directives in the source code and some explicit linking got it all placed in memory like it needed to be. Then one more post-processing step split the hex file into two files, and a slight modification to the PC app gave it a state machine to make it download twice, expecting it to drop off the bus and reconnect in between.It worked!Quote from: Siwastaja on January 09, 2022, 07:54:19 pmHmm... At the bottom of his supported devices list is the new(ish) Raspberry Pi Pico. Dual-core M0+ with pretty much standard peripherals, and the RPi's famous support. I had forgotten about that. It could be interesting to play with...Quote from: NorthGuy on January 09, 2022, 08:55:41 pmAbsolutely! But if all you have is a hammer, then everything looks like a nail. It's hard to think differently unless you've already been there. Once you have the right generalization, *then* you can have different but equally-valid tools. The larger, more capable architectures feel to me like power screwdrivers or maybe an air wrench. (No, you don't beat the screws in!!!)

author: NorthGuy
author_rank: Super Contributor
timestamp: January 09, 2022, 10:47:33 pm
content: Quote from: AaronD on January 09, 2022, 09:34:24 pmI would rather think of MCUs as toolboxes. You get a big toolbox with screwdrivers, hammers, drills, saws, various drill bits, blades, wrenches, but also some exotic tools you don't know how to use and what they're for. You get a task, such as building a table, and you need to make sure that you select a box which have all the tools that you need. If you miss something you'll have to improvise - such as beat nails with a wrench, or drill pilot holes and push nails in with pliers. Same with MCUs - they must have everything you need for your task.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: January 10, 2022, 01:06:55 am
content: Yeah, they're often well enough documented to do it by raw registers. What you get from libraries -- of varying sorts, from headers (like the workflow with most AVRs) to CMSIS to mfg HAL stuff or others -- is portability: some ease in switching between devices. Which might be between different sizes of a family, to other families (like, between flavors of AVR), to whole different cores (maybe AVR vs. ATSAM?) or even other manufacturers (not sure there's any embedded examples of this, but PCs and phones are a good example of multi-platform support, at least by higher-level means: the drivers may vary, but they all run Android or Linux or whatever, and from there, the same ARM binaries).The most basic thing you can do is use raw register offsets and settings, just magic numbers everywhere; that's obviously just very poorly documented, besides being utterly brittle in portability; if anything on the underlying hardware changes, it's a complete wash.Put those numbers into device-specific headers, and you have something like what AVR has. They go with avr-libc, which provides platform-specific implementations of standard (and some nonstandard/extended) C functions. You may not have to change program code between sibling MCUs, but likely will between sub-families or higher.Some of those differences can be abstracted away with a driver layer, which is what CMSIS is for AFAIK. More of a thin driver layer over the available devices; a standardized interface so you input the options/actions and get compile or runtime errors if something isn't supported.And HAL stuff might range from device to family to manufacturer level support, of course stuff that compiles on all platforms is also going to be very bloated. At least give or take how it's structured; a fair amount of portability can be afforded by C++ templates and stuff, but that's not available in plain C and pretty much has to be written to do anything.Along with that, presumably the higher level stuff has been tested, at least to some degree -- you might overlook the errata reading the datasheet, or stumble on a bug that hasn't been reported yet, and pull out much hair in the process. Whereas in a HAL you have some hope that they've actually written it in already. Or, I mean, who knows -- again, the fundamental problem with ever-higher level software is, it's made for whatever purpose, and whether it was at all very much documented, for that purpose or other, or how well it's been tested, period, or on other platforms; it can be all over the place.And I mean, look at Arduino; it's cheesy and slow, but it's accessible as hell, and supported ondiverseembedded platforms.And it's not like the problem is unique to software, plenty of hardware is full of crappy design (PIC errata, anyone?). It's a bit harder to change that software so tends to be a bit better tested, but it's all a matter of degree, nothing is perfect.Tim

author: Siwastaja
author_rank: Super Contributor
timestamp: January 10, 2022, 08:42:20 am
content: Quote from: NorthGuy on January 09, 2022, 10:47:33 pmYeah, and some prefer to wrap all their tools inside of paper printed with pictures of hammers, because on a CS class, it was told that the more wrapping the better, and besides, hammer is always good. Then they try to use the tools through that hammer paper and wonder why this is all so difficult, but get the job finally done by accepting whatever table comes out as a result. Then they go to the interwebz to brag how nice and well detailed the hammer picture is, and wonder how difficult itmustbe if you remove those wrappings. After all, that means you have to draw all the hammer pictures from scratch every time you do anything, how insane waste of time.And after 5 years, hammers go out of fashion, and are replaced with drills.Boy I love tool analogies!

author: Codemonkey
author_rank: Regular Contributor
timestamp: January 10, 2022, 09:03:40 am
content: Quote from: Simon on January 07, 2022, 08:21:26 pmThe cost to the company was about the same regardless. You could also buy the board without the seminar (which was actually run by the distributers, not Atmel) but the cost was still about the same.

author: Kleinstein
author_rank: Super Contributor
timestamp: January 10, 2022, 09:32:13 am
content: The linraries may provide better portablity, but they also add more manuals to read and understand and an additional layer of bugs. At least for the STM32 HAL part the protabilty has it's limites - if the HW is different the way to use HAL can also be different different. Including more advanced features, not supported on all chips to the HAL functions can also be very confusing and make things more complicated than actually needed.I like the HAL part for the initialization, but that is about it.The erratas are a big thing and some of the PICs were pretty bad in that respect (e.g. the early PIC18 with non working interrupt priorities - the only work around was not using this feature as it could lead to stack corruption). Erratas were also a big thing with the early Xmegas, severely crippling the ADC. It is a shame that the normal datasheets (epsecially the electronic form ) does not have at least hints, which parts may be effected by erratas. Not a severe one, but odd were the internal caps for a 32 kHz crystal in the AVRs. The DS list them, but AFAIK they never worked and still come up in new datasheets - they could have just skipped that from the mega8 on. In this case I think this is broken by design - switchable caps just can't work well, as the caps need to be low ESR.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 10, 2022, 05:30:19 pm
content: Quote from: Kleinstein on January 10, 2022, 09:32:13 amI agree with that. It's usually fine for initializing peripherals / MCU features. But in all other cases, it's often pretty inefficient. (I'm thinking, in particular, about all the functions for transmitting data from/to a peripheral using DMA. They reconfigure the DMA channel at every call. That makes it easy to use when you're just testing stuff, but for real work, you usually need to rewrite them anyway.)

author: Siwastaja
author_rank: Super Contributor
timestamp: January 10, 2022, 05:37:02 pm
content: But, all DMA controllers I've worked with are trivially simple. Maybe there is some beast out there which requires manufacturer to chime in with driver code?I follow the practice of being explicit to the point, and no more. So if I want to tell the DMA controller in STM32 that the transfer length of the next transfer is 123, but everything else is like before, I do this by writing:DMA1_Channel2->NDTR = 123;instead ofconfig_struct.irrelevant_parameter = 0;config_struct.some_fixed_but_important_parameter = CONSTANT_TO_A_FIXED_VALUE;(copypaste 10 more unrelated lines, one of them accidentally wrong to add an interesting hidden bug)DoStupidHALThing(DMA1_handle_thing, &config_struct);Performance difference is obvious and undisputed (and yes, it'sverycommon requirement to reconfigure DMA in interrupts at high interrupt rate), but I claim that the first one is also easier to understand.As treez would put it, would you agree...?

author: Rudolph Riedel
author_rank: Regular Contributor
timestamp: January 10, 2022, 08:09:07 pm
content: Quote from: Siwastaja on January 07, 2022, 07:14:13 pmHow many commercial products did you take apart?I have an AVR in my dryer, discovered this a couple of years ago when the supply chip broke.Whirpool AWZ 61225, still works after the repair.I had a dishwasher, I believe it was a Beko, when it broke I found at least three AVR in it, one for example controlling the sump pump.Having a working dishwasher was too important though to not immedialy buy a new one.It's not like manufacturers of white goods advertise which controllers they are using.And who takes apart a dishwasher, a drayer or a washing machine just for kicks?

author: westfw
author_rank: Super Contributor
timestamp: January 10, 2022, 11:22:11 pm
content: QuoteIs there an 8bit cpu compiler that does a good job on such math? My impression is some things are pretty much crippled by standards rules (and that "mixed precision math" is just one of those things that you don't want to use C for.)Quote.The current compiler inlines 16*16bit multiplies as well, and is even smart enough to inline a 32x32 multiply when the result is only 16bits:https://godbolt.org/z/Yqsaz9PfW

author: Nominal Animal
author_rank: Super Contributor
timestamp: January 11, 2022, 12:16:05 am
content: (For what its worth, I do quite a bit of SIMD stuff, especially on x86-64; and using theintrinsicsand GCC/ICC/Clangvector extensions(which work for e.g. ARM NEON too), I can easily get 2× to 4× the speed of compiler-vectorized code; sometimes even more. ICC is the best of them, but even it cannot do it as well as a human, yet; and possibly never in C or C++, exactly because of the rules of the standard abstract machine. The difference to hand-written assembly is so small that I almost never bother anymore, especially since the vector extensions are rather portable across hardware architectures. In other words, it is no surprise to me at all that math is hard for C compilers to optimize.)

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 11, 2022, 12:34:02 am
content: Quote from: Nominal Animal on January 11, 2022, 12:16:05 amSure thing. And one should also consider whether they are using integers or floating point. On top of good optimizations being hard in general, some "optimizations" that may look obvious to the programmer may actually lead to precision problems when using FP, thus compilers avoiding some of them. Even when using the -ffast-math option.

author: Nominal Animal
author_rank: Super Contributor
timestamp: January 11, 2022, 01:54:10 am
content: One of the expressions that I wish C compilers could handle better is simple((int64_t)x * (int64_t)y) >> 31withint32_t x, y, on 32-bit architectures.Even GCC 11.2 on x86-64 with-m32 -Ogcompiles this to code that uses two separate imul instructions, with the minimal one (generated with-m32 -O2) being simplymov eax, xmov edx, yimul edxshrd eax, edx, 31althoughmov eax, xmov edx, yimul edxshld edx, 1is even better/shorter, although then the result is in theedxregister (instead ofeax). Both versions are best interleaved with other code (not usingeaxoredxregisters).The reason this is difficult for compilers to optimize, is the nature of the casts. Either the internal representation of variables in the compiler needs to be able to describe a variable as "32-bit signed value as a 64-bit quantity", or it internally needs different multiplication operations depending on the parameter and result widths and signednesses, and do a preliminary optimization pass that combines a cast-and-multiplication to the proper multiplication operation. To compiler writers, this is nasty.Yet, in practice, it does make a significant difference to fixed-point multiplications and similar.And, as in the above example, the paired register result (which I do believe occurs on both 32-bit ARM Cortex M4 and RISC-V) also needs special handling. Depending on the hardware architecture, a paired bit shift may be slower or less preferable for pipelining or other reasons, than a single-register bit shift and a register move.(RISC-V and MIPS do need both mul-hi and mul-lo operations, because the latter provides that one further bit needed, but that cannot be avoided, when the shift is 31 and not 32 bits.)This kind of multiplication, and the related fused multiply-add in fixed point, is the only one that I tend to implement in GCC/ICC/Clang extended inline assembly. This has the benefit that unlike a separate assembly function, these C compilers can inline the code containing the extended inline assembly, and even choose the registers used (if the instruction set permits; it does not on 32-bit x86) as long as the proper register constraints are used.I do not believe that there is a way to describe the operation in standard C, except when the compiler implements the abovementioned optimizations itself.If we look at 8-bit architectures, the current compiler developers just do not see the need to optimize such expressions, because of the idea that "if anyone needs that, they're better off using a more powerful, e.g. a 32-bit microcontroller, anyway".In todays world, it is damned difficult to argue for spending more human effort, when a little bit more money thrown at the hardware works just as well or even better.I suspect only hobbyists and similar enthusiasts actually care about this.To circle back to the original topic, I do find it odd how much the discussion revolves around personal preferences, and especially attempts at explaining away others' differing personal preferences as stupidity, lack of experience, or lack of knowledge.Me, I like the hardware, but dislike the company because their business practices are contrary to my current preferences/goals, like I already posted in this thread earlier.I don't see anything odd in others liking the hardware so much that they're willing to put up with the company, or if doing commercial product development with employer-paid tools, even like to deal with the company. It's just different context, different situation, different weights/emphasis on various aspects. If my own situation were to change, my opinions would too.The interesting bit here are the detailswhya particular person likes/dislikes the hardware (or the company). It's just a bit dull/discouraging/annoying reading all the "because I'm happy with the hardware, you must be rather stupid and should change your career if you disagree or dislike the company" -type insinuations between the lines.I'm especially unhappy with the "I feel Atmel did ..." and "I feel Microchip did ..." type posts, because the writers obviously haven't checked the actual history, company revenues, development mailing lists et cetera, and just pull those assumptions out of their feelings, without any kind of basis in reality. Please stop; it just muddles the waters, as it makes it very difficult to those who only read but do not otherwise participate in the thread to uncover thefactsand personal reasons, and separate them from unfounded beliefs and feelings, which really, have negative value.If you don't want to stop, then please just make it clear when it is your personal belief or understanding without any references, and when you have facts you have based that belief or understanding on.

author: Zucca
author_rank: Unknown
timestamp: January 11, 2022, 04:31:16 am
content: (I want to do my first steps in the µC planet with Microchip they look like the easiest to learn....)

author: rsjsouza
author_rank: Super Contributor
timestamp: January 11, 2022, 01:47:56 pm
content: Quote from: SiliconWizard on January 11, 2022, 12:34:02 amThe best C compilers and optimizers for mathematic operations that I worked with were for the TI C5000 and C6000 DSPs - although their implementation was highly specialized in digital signal processing, you could still write it in plain C in a specific way and you would make use of its full MAC with sign extensions and special addressing. FFT was also quite interesting, which even used the C5000's HW FFT engine. But all that is history now.

author: Simon
author_rank: Unknown
timestamp: January 13, 2022, 08:35:12 am
content: Quote from: NorthGuy on January 09, 2022, 08:55:41 pmPrecisely, I now find myself thinking: I could do that with one of those new mega's. I only use or think to use ARM because it is faster for complicated things and can handle 32 bit at a time but I have done large number calculations on AVR no problem. Really it's all about the peripherals and the peripheral combinations that drive a particular µC long before you give a damn about the CPU on that µC.

author: Kleinstein
author_rank: Super Contributor
timestamp: January 13, 2022, 10:13:50 am
content: The CPU can be important when more memory is needed. Beyound 64/128K a 8 bit µC add extra complications.A simple CPU with deterministic run speed can be used with timing from code speed - though usually on with ASM coding. In this case the CPU also makes a difference. Ideally the critical timing should be set by the HW and not the code, but it is possible for simpler tasks.In the early days the quality of the IDE and compiler was also a big factor - the limited C for the early PICs was definitely a factor against them. Today something like support by GCC is wide spread and the field leveled a bit.

author: hans
author_rank: Super Contributor
timestamp: January 13, 2022, 04:39:24 pm
content: I think the transition from 8-bit / 16-bit MCUs to 32-bit will have a few things to learn, but not as much as some people make it out to be.I think in terms of CPU, you have the difference of Modified Harvard (8-bit PIC/AVR) and Von Neumann (most 32-bit chips). Reading constants on PICs or AVR requires special treatment with (code-LUT on PIC or LPM instruction on AVR). On Von Neumann it is just a normal memory load operation, since RAM/ROM/peripherals are in the same memory space.PIC24 is also a Modified Harvard architecture, and has 2 memory spaces for program and data, with accompanying TBLRD instructions (similar to LPM). However, it is also possible to map (a part of) FLASH memory into data memory space, so takes inspiration from Von Neumann.Design of peripherals on 32-bit MCUs is similar, but perhaps everything is a bit bigger as it has more bells and whistles. But if you learn how setting up the clock (clock tree + enable per peripheral) and GPIOs (remapping/alternate functions) work, I think you're already on the same level as learning a new modern 8-bit MCU. Sure a SPI peripheral on a STM32 may have a few extra configuration/status registers, but most features/bits can be left at zero unused..Other than that I can't really find any fundamental differences on how you would go about writing C/C++ code on an AVR (e.g. ATTINY/ATMEGA) or a 200MHz Cortex m4. Know what instructions run fast on the CPU, how you can set up peripherals to do the operations you need, etc.The Cortex-m7 does get a bit more complex because of (data) caches and multi-master memory buses. But I think these MCUs are converging towards application microprocessors (where average-case performance is increased), instead of being "very deterministic" microcontrollers.

author: Simon
author_rank: Unknown
timestamp: January 13, 2022, 06:51:25 pm
content: Quote from: Kleinstein on January 13, 2022, 10:13:50 amNo, you would be changing the CPU for the sake of the memory, Do you still really care about any non memory related features of just the CPU? by this time you probably wanted those nicer peripherals. I have never really thought about the CPU but then I am not an asm programmer.Any yes looking at the ARM based SAMC I picked it for the CANbus support and the general speed, but I never said I need ARM, it could have a fast 16 bit CPU for all I care. Even on a 32 bit system I will not waste my memory on oversized variables. It's a bad habit that spills into 8 bit work.Indeed the clock system was the most complicated bit I have had to get my head around. Things like counters are as simple as AVR.

author: hans
author_rank: Super Contributor
timestamp: January 13, 2022, 11:02:07 pm
content: Looking at ESP32.. people really don't seem to care that much it is using a relatively non-mainstream CPU core..Now there are also RISC-V MCUs on the horizon.. and when I see how popular it already is within the FPGA OSS community, it is incredible. People write a functionally working 32-bit RISC-V CPU in 100 to 200 lines of Verilog. There are plenty of quite performant cores that get to approximately the same calculation power as a Cortex-m3 (barrel shifter + multiplier) or even m7 (dual issue CPU). Attach code and data memory blocks, add your own peripherals, and you have got your own SOC or MCU! .. well running on a FPGA of course.I was actually profiling some of my firmware codebase for fun over the holidays. I was testing with the RV32I (base spec) and RV32IM (Hardware Multiplier/Divider) in emulation.. In my experimentation you would need a RV32IM with a good pipeline to get close to the speed of a Cortex-m3 CPU. However, to my surprise a lot of code runs at almost the same speed (-I or -IM). Some parts are a bit slower (10-20%) that involve indexing arrays of structs or do other (miscellaneous) arithmetic operations. Some code I refactored because it was possible to replace an integer division with a simple 2^n multiplication (tail division is a lot slower than some 64-bit shift/add/compare). But sometimes CPU benchmarks like Dhrystone etc. really put a lot of weight in the basket of number crunching, while a lot of firmware consists of moving some data around and (conditional) branching. You don't need much more than a RV32I, MIPS, Cortex-m0+ or m3 for that.(Heck perhaps even 8 or 16-bit CPUs are fine)

author: Howardlong
author_rank: Super Contributor
timestamp: January 13, 2022, 11:14:37 pm
content: Quote from: hans on January 13, 2022, 11:02:07 pmThere's already a RISC-V ESP32, the EXP32-C3 generally available... if you can find them in stock ;-).In addition the ESP32-C6 has also been announced, another RISC-V based device.I agree with your sentiment though, if the dev environment and support is there, and it's cheap, the core itself isn't particularly relevant.IME the IDE and hardware debug for ESP32 in the ESP-IDF is flakey as ****, but the chips are cheap. I can understand why not many get much further than Platform IO.If you want WiFi, you'd be nuts not to be considering ESP32 considering the price in comparison to traditional vendors' offerings.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: January 14, 2022, 10:40:46 pm
content: Quote from: hans on January 13, 2022, 11:02:07 pmDo you have a link to an example of this? I'd like to see it.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 14, 2022, 11:15:48 pm
content: Quote from: Sal Ammoniac on January 14, 2022, 10:40:46 pmYes, that was a slight exaggeration IMO =)If you can find a *working* RISC-V core in 100 to 200 lines of Verilog, so at least complying with the RV32I base, that's either bullshit, or obfuscated Verilog in the same spirit as obfuscated C.So i'd like to see that as well =)

author: hans
author_rank: Super Contributor
timestamp: January 14, 2022, 11:31:37 pm
content: 200 lines of code:https://github.com/BrunoLevy/learn-fpga/blob/master/FemtoRV/RTL/PROCESSOR/femtorv32_quark.vRISC-V CPUs can be really quite basic. The ALU only has half a dozen operations, in regreg or regimm mode. Then there is reg load, memory load/store, jumps and conditional branches.It's debatable whether the SYSTEM group is needed, which includes ECALL. In an embedded system without OS or system calls, itcould beomitted, or implemented as a jump to a fixed PC in FLASH.IMO this one is even more impressive, but not in straight Verilog (yet a language Silice that is not too abstract from Verilog). This core acoomplishes a dual-core RV32I with only a small fraction of increased code/resources, comparing tot a common 4-stage non-pipelined implementation:https://github.com/sylefeb/Silice/blob/master/projects/ice-v/IceVDual.mdObviously you can use varying degrees of "complying" or "compatible". I think these cores miss the ECALL instruction which is often not used, unless you want to implement an OS using system calls.There is also the SERV bit-serial RISC-V softcore which only takes a few hundred LUTs. But it is incredibly.. incredibly slow. Nonetheless it is possible to fit 1k+ RISC-V cores in a medium/large sized Virtex/Kintex FPGA. However, the SERV core does explicitly document that the core may execute illegal instructions, as the 5-bit opcode was hand-optimized to be decoded by a 4-input LUT to save space. So some opcode bits are handled as don't-care instead of their exact value..A CPU core only does not make a SoC, which obviously adds a lot more code to connect to a bus (Avalon, AXI, etc.), memory systems, let alone peripherals, etc..I was amazed nonetheless, because with modern toolchains and CMSIS/HAL libraries, it's easy to get drowned in over 200 lines of boilerplate code just to get PLL, clocks, I/Os set up to create a blinky program.

author: nigelwright7557
author_rank: Frequent Contributor
timestamp: March 19, 2022, 09:14:36 pm
content: PIC's are cheap.Having to make a pcb for one isnt a hard task so thats what I have always done.MPLAB X and Harmony can take time to get to grips with but they are free.Been using PIC's since 1985.Always read errata sheet first before picking a PIC.I bought one in and had a pcb made only to find USB wasnt right on it.I asked Microchip and they said USB doesnt work on 64 pin IC and to read errata sheets first.Many years ago my boss designed a PIC into a washing machine.None of the 100 circuit boards worked.Turned out no one told production the PIC has to be progarmmed first !So I got them to desolder, program and refit.

author: AaronD
author_rank: Frequent Contributor
timestamp: March 20, 2022, 03:49:37 am
content: Quote from: nigelwright7557 on March 19, 2022, 09:14:36 pmSince the PicKit programmer doesn't have a Linux driver, I rigged up a programmer from the GPIO pins of my Raspberry Pi instead, and used a free GPL-licensed command-line tool to run it:https://wiki.kewl.org/dokuwiki/projects:pickleAnd SDCC is better than MCHP's free compiler (doesn't take much at all to say that!):http://sdcc.sourceforge.net/So, since I now have a standalone toolchain for PIC too, like I always have for AVR, I just set it all up in Code::Blocks like I always have for AVR:https://www.codeblocks.org/No debugger for either one (probably could if I really wanted), but a UART spew and/or oscilloscope output works just fine for what I do.Quote from: nigelwright7557 on March 19, 2022, 09:14:36 pm

author: seamusdemora
author_rank: Regular Contributor
timestamp: May 02, 2022, 05:26:45 am
content: Quote from: AaronD on March 20, 2022, 03:49:37 amI'm completely new to this, so I have no opinions yet. I decided only recently to try a PIC uC in my Zero Power RPi project - it will interface with a DS3231, monitor battery voltage and replace some discrete logic & a one-shot. I've read a number of posts in this thread, and the compiler seems a sore point with many for a few reasons - quality and licensing seem to be most prominent. SDCC is mentioned often as a replacement for mc8.I'm a Mac user, and was glad to see that MacPorts covers sdcc :https://ports.macports.org/port/sdcc/However, both MacPorts and the SDCC SourceForge page (http://sdcc.sourceforge.net/) seem to suggest I stick with mc8:SourceForge: 'Microchip PIC16 and PIC18 targets are unmaintained.'MacPorts: 'Work is in progress on supporting the Microchip PIC16 and PIC18 targets'Am I missing something? These two statements are contradictory, but neither one of them is "encouraging" re using sdcc - at least wrt PIC16. If 'gcc' is a btter choice for 8-bit platforms, where can I find that?Thnx,~S

author: hli
author_rank: Frequent Contributor
timestamp: May 02, 2022, 06:33:11 am
content: Quote from: AaronD on March 20, 2022, 03:49:37 amThey have. I'm using it (on Kubuntu) for quite a while now. They might need some tweaking with the udev rules, and the PicKit seems to be a bit picky with the USB ports, but it works. (Although I upgraded to an ICD4 a while ago).

author: DavidAlfa
author_rank: Super Contributor
timestamp: May 02, 2022, 08:37:52 am
content: I love how Linux guys always use diminutives, "some", "little" "a bit"... which in the great majority of cases means "a lot", "take the poison", "search for a window in the 27th floor"

author: JPortici
author_rank: Super Contributor
timestamp: May 02, 2022, 08:42:07 am
content: ah, an unmantained compiler is better than the microchip one.of course.if you said MikroC i would have said well, ok, maybe, but i completely disagree whenever SDCC is brought inXC8 is extremely clever in code generation, you just hate ti write clear and understandable C.When you try to be smarter than the compiler, add inline assembly, use volatile where it's not needed, in that case code generation kinda sucks but that's probably true for most compilers.Please don't point at useless tests like "LOOK IT'S NOT USING INC BUT IT'S USING TWO INSTRUCTIONS TO INCREMENT A VARIABLE" (insert heavy breathing) but try using meaningful code instead.one of my favourite examples is the correct use of qualifiersthis function for PIC18Code:uint16_t readFlash(uint16_t address) {uint16_t __rom *ptrProgMem;ptrProgMem = (uint16_t __rom *) address;return *ptrProgMem;}will generate the exact code needed to read flash, without having to mess with inline assembly. Use a 24 bit address and you can point to configuration, IDLOC, etc, as well.by the way, does SDCC support the 24bit type and 24bit arithmetics natively? code becomes nonportable, but gives a huge boost in performance over 32bitwhat i don't like in XC8 is the linker, it's prone to fail when there is less than one code page available and it still doesn't recognize code spaces that have been added in recent parts (the memory access partition feature) but hey, every version has a small

author: seamusdemora
author_rank: Regular Contributor
timestamp: May 02, 2022, 10:25:05 am
content: Quote from: JPortici on May 02, 2022, 08:42:07 amSorry - but I'm not quite clear on this... are you saying that one is better served using the 'sdcc' over the free version of 'xc8' ?

author: Simon
author_rank: Unknown
timestamp: May 02, 2022, 03:43:58 pm
content: If you are using 8 bit I would use one of the new AVR chips, clearly they are good or microchip would not be coming up with new ones although they stuffed the naming right up. And yes objectively we know that the AVR is 4 times faster than the PIC, why use old designs?

author: AaronD
author_rank: Frequent Contributor
timestamp: May 02, 2022, 05:58:08 pm
content: Quote from: seamusdemora on May 02, 2022, 05:26:45 amQuote from: JPortici on May 02, 2022, 08:42:07 am"Unmantained" simply means that no one is changing it. What's already there still is what it was when the last person touched it. It may not be perfect, but if it's still better for the same price (free), use it.Quote from: seamusdemora on May 02, 2022, 05:26:45 amGCC doesn't work for PIC. It does work for AVR. Different instruction sets. One is designed to be "C-friendly", so it's easy to port GCC to it. The other is "silicon-friendly", originally meant to be programmed only in assembly (as I understand), and backwards-compatibility means that it can't change now. It works so much differently that a GCC port to that would cease to be GCC altogether.Quote from: hli on May 02, 2022, 06:33:11 amQuote from: DavidAlfa on May 02, 2022, 08:37:52 amI didn't know about the Linux driver for PicKit. I must have missed it, or it must be a new development, or maybe it only supports the older ones while I have a newer one. Anyway, the thing about tweaking udev rules is also something I have experience with, for a different project, and it's not particularly pleasant. I still prefer an independent GPIO-based programmer for the Raspberry Pi:https://wiki.kewl.org/dokuwiki/projects:pickleRead the documentation of course, set it up like it says, and it "just works". (at least it did for me)The vast majority of Linux (desktop) uses are no more customized than Windows is, and there are tools built into the GUI package (no matter which of several you end up with) to do just that. No need to go fumbling around the internals. If you do, then DavidAlfa has a point, but it's the exact same for Windows too, so...Quote from: JPortici on May 02, 2022, 08:42:07 amFor a lot of things, that's important, but sometimes it's not. For most of what I do at home, it's not.I don't copy code verbatim and "watch it work", which implies frustration to me when the "magic block of text" doesn't "just work". Instead, I understand the logic and what it's actually doing, and rewrite it for the new platform. Sometimes it's similar or even identical, sometimes not. It also helps me remember the context of what I was thinking/doing when I wrote it the first time, which is a big deal too.Where portability clearly becomes important is when you're not married to any particular platform - like maybe a library, or you're using a dev board that you already have, to get a jump-start before the real hardware comes in - and so the same code verbatim does indeed have to compile successfully and bug-free to several different chips.My projects are more serial than that, stopping at the "generic block diagram" stage until I have the real hardware, and then I implement it directly for that specific platform.Code:#if PLATFORM_1//complete standalone code for platform 1#elif PLATFORM_2//complete standalone code for platform 2...#else#error Platform not supported#endifQuote from: JPortici on May 02, 2022, 08:42:07 amAh yes, I had a project that needed that too. I think it was using the pro version, as my company at the time wanted to port an existing product from 8051 to PIC and bought "the good tools". (as you should at that level) Even so, it was quite a challenge to convince the linker to put this here and that there, keep all of this empty, etc. According to the (lack of good) documentation (at the time at least), it really wants to just do what it wants and say, "See? Your code is 'running' just like you said!"Adding to the challenge was the need to field-update the entire program, without a chance of bricking it (from the customer's perspective), when the fully-optimized binary was already more than half of Flash. I ended up with kind of an odd architecture, with multiple partial downloads, the "bootloader" never fully releasing control, and the application being more like an Arduino's init() and loop() functions where loop() doesn't contain the loop but is instead called once per loop from somewhere else, etc. But it worked!...and then our 8051 supplier told us about a new chip that would significantly undercut the PIC again ("You couldn't have told us sooner?!"), so we didn't actually sell my version.Oh well, they did say I could take the PIC code home and use it, so I guess that's a plus.

author: cv007
author_rank: Frequent Contributor
timestamp: May 02, 2022, 06:30:03 pm
content: QuoteIs saying just use xc8 since its current and supported. No need to seek out another compiler for a pic16/18, xc8 will work just fine. If you have mcu's that can use gcc, then that is nice as you then can also use c++ and will have a toolchain that will be familiar when moving from one mcu to the next. The pic16 you have now is the newer series and has some nice features, so just make it do what you want using xc8.Here is a simple example using the newer pic16-https://github.com/cv007/3DigitLedand there was nothing about xc8 that was a hindrance.I also created the same project for an avr tiny416 (newer avr0/1 series), where I used c++ (gcc). The end result was the same, the code is a little nicer since c++ was in use but when the device is finally doing its job it makes no difference.Just start using your pic16 curiosity board, making it do things, which is the end goal. Eventually you will get another board with a different mcu, and do the same. Repeat. The things like ide/toolchain/programmer are the obstacles in between your mcu and your end goal (mcu does something useful), and you just have to get your hands dirty in that middle layer, where nothing is perfection.

author: hans
author_rank: Super Contributor
timestamp: May 02, 2022, 09:07:19 pm
content: Quote from: AaronD on May 02, 2022, 05:58:08 pmI can't debate IF SDCC is better than XC8. No experience. But from my personal experience with XC8, I tend to believe it.However, I do have doubts aboutplanningto use unmaintained tools. They can work today, break tomorrow for all I know, and it's unlikely to be maintained or fixed. Also, how are new parts going to be supported? Because I don't think you will want to keep using the same PIC parts for the upcoming 10 years.QuoteTechnically speaking, you don't use a 'driver' for a PICKIT. As in, a kernel driver, that is. The purpose of udev rules is to handle device events, and very often those events are used to make USB devices accessible by any user in user land. Otherwise you would need root access to do so.If the kernel doesn't have a driver for a particular device, it doesn't understand what to do with it, yet still enumerates the device and makes it available in the system for general communication. By using a library like libusb, any program can directly talk to USB devices as if they were a "driver": an user-space driver as it's often called. These drivers aren't installed into the kernel, but rather the protocol is baked into MPLAB or other programs that access the PICKIT.The advantage of this is that every user-land program can do whatever it wants with it, in it's own way. For example, it's trivial to send commands to a PICKIT2 using a python library, and then the next second use the PICKIT2 in MPLAB again.Technically you can do the very same things in Windows, but in order to use libusb to talk to a specific device, you need to swap out the USB driver for a generic libusb one. This driver only does enumeration and then leaves the device alone. This would work great with a PK2 Python library, but if MPLAB expects the PICKIT2 to use Microchips custom driver, it may not be so happy to work with it anymore. And reinstalling drivers and replugging cables gets tiresome real fast.In my experience, the degrees of freedom on Windows is almost a complete subset of the degrees you have on Linux. The only exception is particular programs that are only on Windows, for example, the PICKIT stand-alone utlity, older MPLAB IDE, etc. But perhaps I'm also a bit biased as a long time linux user

author: hli
author_rank: Frequent Contributor
timestamp: May 02, 2022, 10:03:52 pm
content: Quote from: AaronD on May 02, 2022, 05:58:08 pmAFAIK MPLAB has always supported the current PicKit (and the previous one, to a certain degree) under all OSes. I'm using Linux for more than 10 years now exclusively, and never had issues. Yes, there are no _kernel level_ drivers, but MPLABX (the IDE, and the programming tool) always worked. Yes, a too-old MPLABX will not work with a too-new PicKit (and vice versa), but that the same under all supported OSes as well.

author: hli
author_rank: Frequent Contributor
timestamp: May 02, 2022, 10:15:57 pm
content: Quote from: DavidAlfa on May 02, 2022, 08:37:52 amWell the tweak actually was just changing something small (this was a year ago, I forgot the details - with a current MPLABX it worked out-of-the-box). And when it would have been a 'you need to install 10 additional packages and spend one day configuring the system' I would have called it that.I guess you do like Windows more than Linux - but there you need to rely on the software (and hardware) vendors to support the combination of tools and software you currently need to work correctly. If not, go looking for something else.In a computer system the arealwaysmoving parts - there is a newer PIC you want / need to use, then you need a new PicKit / ICD to program it, which needs a new MPLAB, and there you go. Or there is a new OS version which you want to upgrade to, and the you need to hope that its changes will not affect your software (or hardware devices).Yes, you can keep all in a single state, and then you will not need any tweak anything, but it also means you cannot do new things. And thats the same for Windows as for Linux. (and you need to hope your computer is not connected to the internet, because then there will be someone finding a new way attacking all computers, and you are back to the moving partsThe difference between Linux and Windows is that under Linux youcando the tweaking in case the vendors does not help you (and under Windows you just go, looking for that windows in the 27th floor for the computer to be thrown out). Unfortunately it is needed more than I would like, because vendors do not support it as well as they could. Its getting better though.

author: seamusdemora
author_rank: Regular Contributor
timestamp: May 02, 2022, 11:21:29 pm
content: Quote from: Simon on May 02, 2022, 03:43:58 pmMakes perfect sense - except for the 16F15244 I've already invested in.. But that's not a concern - if the AVR parts are superior, I'll be better off in the long run. Since AVR is owned by Microchip, isn't the development environment the same as for PIC?I don't think my application is resource-intensive: I want to use the AVR/PIC/Whatever to manage power for a solar-powered Raspberry Pi project. I thought initially I could get the Pi to manage itself, but that's gotten out of hand. There's a DS3231 RTC, comparator, one-shot, etc. I want the uC to control the RTC (i2c) to set the alarm, service the interrupt, actuate the power switch (a latching relay), and monitor the battery voltage. I do need x-low power consumption... well, that's probably best addressed in a new question?Thnx,~S

author: AaronD
author_rank: Frequent Contributor
timestamp: May 02, 2022, 11:34:05 pm
content: Quote from: hans on May 02, 2022, 09:07:19 pmQuote from: hli on May 02, 2022, 10:03:52 pmThat might be what I was thinking of. It requires MPLAB specifically, to use a PicKit. No other IDE knows the protocol, and AFAIK there's no standalone command-line utility either. Yes, MPLAB is free and runs everywhere, but I really like to have the same IDE for everything if I can get it. So far, I've settled on Code::Blocks. Thus, my PicKit doesn't work.Any command-line utility should work with any IDE, either as the compiler itself, or as a pre-build operation (gathering required resources), or as a post-build operation (distributing the binaries and/or programming the chip), or as a user-triggered "whatever" (also programming the chip, if you'd rather that be explicit like I do). XC8 is, so it's possible to use that in Code::Blocks or any other IDE, but AFAIK the PicKit "driver" isn't anything beyond MPLAB itself.

author: seamusdemora
author_rank: Regular Contributor
timestamp: May 02, 2022, 11:34:39 pm
content: Quote from: AaronD on May 02, 2022, 05:58:08 pmOK - Did not know that, but it's important!!

author: T3sl4co1l
author_rank: Super Contributor
timestamp: May 03, 2022, 12:53:16 am
content: AVR being "faster" I think was sarcasm, or hyperbole... maybe? I don't actually know the benchmarks offhand. But it's noteworthy that:- PICs often run faster (64MHz+?), but have less MIPS/MHz (typical 4 cycle instructions?)- PICs are terribly register constrained (everything is pulled through the W register; convention is to use 0-page in RAM for fast access, ala 8051, 6502, IIRC?) while AVR has absolute tons (32, though with some restrictions on which can be used for what)- Both are load-store architecture (I think?), so, it takes a while to do much of anything in ASM, even the simplest operations in memory require several instructions. So compared to more powerful ISAs, both are relatively low performing.Even as streamlined as AVR is, it has enough quirks that GCC is a bit of a force-fit. GCC's internal representation (GIMPLE) is 16-bit I think?, and AVR tends to be best used that way i.e. as a 16-bit machine hobbled with half word size. For example, GCC's ABI (application binary interface), register allocations, etc. go by pairs of registers; you'll never see it using e.g. r23 for two 8-bit function parameters, always r24 first (paired with r25, unused), then r22 next (paired with r23, unused), etc. That is, func(uint8_t a, uint8_t b) expects a and b in r24 and r22 respectively.Or, kind of unsurprising, but somewhat-specialized instructions like MUL are largely library-driven, like multiplying two uint16_t's results in a call to__mulsi3rather than inlining the arithmetic. (Only 8-bit ops are inlined, I think?) Which results in a ton of overhead when certain facts are known about the operands (like, an 8x16 is zero/sign-extended up to a 16x16 call), and makes repeated multiply-accumulate rather messy (sometimes the common registers are reused as if an accumulator, but often they get duplicated so you have e.g. the product in r22-r25, then summed into r18-r21). Even if you try to write out all the 8x8 component terms, it won't let you do that so easily, again because it assigns registers by 16-bit pairs, so you end up with a huge mess of erroneous sign extensions and shoving around arguments by one or two places, busywork that would all be trivially optimized out on a machine-level pass -- but again, it does optimization on IR so it doesn't know how to do this. (And I suppose, it's impressive that it does as well as it does, given this.)AVR-GCC has been fairly lackluster over history as well; I'm not sure about the latest versions, but performance probably peaked around v4 to 5.4? Give or take whether you're using any (of the few) language features that have been added since then, of course. (There was one bugfix that I know of, or, knew of but I can't remember what it was actually in regards to at the moment(!).. but other than that, mostly just the added language features since then, with a tiny bit of loss probably due to pruning a few nonfunctional (or faulty!) optimization steps or something like that. Anyway, GCC 8+ is, not much slower, it's some percent difference, mind -- but it's rarely in the other direction, AFAIK.Kind of as an example of how much effort it is to support new things -- there is one optimization that was finally added in GCC 8 I think. Normally, the ABI expects r1 = 0 as a shortcut. So, entering an interrupt, it always has to push and clear r1. Even if r1 is never read during the interrupt. And there was no way to inform the function prologue that it doesn't actually need to do that. Apparently what they did is create a pseudoinstruction, selected based on what's used in the function body. The assembler then converts this into the appropriate prologue/epilogue code. And this closed a ticket that was open for like, over a decade. So, not exactly easy to change things like this, given that GCC has to target literally almost everything, and there's probably just not too much priority for the AVR branch in general..?But yeh, just a couple deeply technical things I've picked up in using and reading about it. Not at all to turn you off it or anything, just, a few things about how it works.Or, not that this'll mean anything very much, if you aren't comfortable with instruction sets / assembler really... oh well?Anyway, nothing that affects casual use of C, for the most part. Usevolatileand ATOMIC and all that, as usual, as needed, for working with interrupts and stuff. (Trivia: the headers define system registers as volatile naked pointers.) A couple optimizations are easy enough, like invoking certain syntax to use IO port (in/out/cbi/sbi) instructions on respective registers (typically related to CPU, PORTs, or a few do-nothing general purpose registers you can sometimes use as fast RAM), which otherwise if you're not careful will just compile as SRAM access (at a couple cycles penalty).As for Code::Blocks, that's what I use, works fine, pretty well set up for avr-gcc already. Have to add the programmer commands though. Never got debug to work on it? I don't have much for debug tools anyway so, not sure what the deal is, but kinda doesn't matter too much. Anyway, never had a problem with AVRDude, and the latest version adds UPDI support via dumb serial adapter so the AVR-DA etc. are accessible without special tools at all, very cool.No clue what kind of PIC support might be found, besides extracting whatever assembler/compiler/programmer tools come in MPLAB and figuring out how to run them from outside. There's probably some 3rd party programmer tools you could look at (maybe that've been covered in this thread already idk). But yeh, anything comprehensive, one-stop adapter, good luck with that.Tim

author: hans
author_rank: Super Contributor
timestamp: May 03, 2022, 07:32:06 am
content: I've had the same problems with AVR-GCC's zero register. Why AVR has always kept with r0 is beyond me. At some point the ATMEGAs came in that added the MUL instruction, and that always places the result in r0/r1. Therefore everytime you do a multiply instruction, it needs push/pop r0, and before the pop it also has to move the multiply result in it's entirety out of the wayAnd MUL is more often than just writing a multiply sign. If you index an array of structs, and each element size is not 2^N sized, then that's best indexed with a multiply instruction.Since r0 is a completely functional normal register, and the "zero register" is more a software convention, I don't see why it hasn't changed. Perhaps backwards compatibility for users that wrote a part of programs in ASM. But honestly that means there are millions of AVRs wasting dozens of cycles on push/popping r0 around a MUL.Now PICs are practically still a lot slower. Since they have only a single register and a hardware stack, there is absolutely zero point porting the architecture to GCC that is completely built around software RAM stack frames. I suppose both SDCC and XC8 is full of static analysis to see which routines use how much data, which local variables don't have to life in time/space together etc.If you look just at Coremarks, then you'll find that an AVR can get 0.5 - 1 Coremark/MHz, and a PIC18 doesn't get much farther than 0.1 Coremark/MHz. Granted some PICs can do 64MHz, while AVRs tend to max out at 20MHz.Quote from: AaronD on May 02, 2022, 11:34:05 pmI personally use MPLAB IPE or MDB (Microchip Debugger) to do programming tasks only with the PICKIT. It's how I currently develop with PIC32s until I sort out GDB for the once (I got something working last weekend, but was only able to inspect the program location and not any variables)MDB is also useful , as its basically MPLAB in the command line. You can tell it to run an automated set of commands, including runnning the simulator, or programming the device and run the code for a set amount of time.You can also call MPLAB IPE from the commandline to have it program a PIC from a HEX file.

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 03, 2022, 08:30:07 am
content: Quote from: hans on May 03, 2022, 07:32:06 amBecause ofavr-libc, andavr-gcc ABI.That might sound snarky, but it is not my intention. The two are separate projects, and while there has been some coordination between the two, they have their own focus and aims. Basically, Atmel came up with the ABI. It got "frozen" in the two projects. (Note that while GCC does support e.g. 8-bitintfor AVR, you cannot use that option with avr-libc.) Nobody has come up with an alternative that was preferable enough to warrant a completely new ABI. Just implementing it once is one thing, but maintaining it and dealing with the loss of compatibility to existing binaries, is the bigger issue. Plus, there are likely corner cases in the hundreds of AVR devices, that have been taken care of in avr-libc and avr-gcc, that would need to be mapped and reimplemented in the new ABI.In other words, it is a "victory due to no competition" kind of thing.

author: JPortici
author_rank: Super Contributor
timestamp: May 03, 2022, 12:20:34 pm
content: Quote from: seamusdemora on May 02, 2022, 10:25:05 ami would use SDCC only if it was the only compiler available for my target. In this particular case, XC8 optimization is more than good enough in free mode - paid optimization help reducing code size, but in reality that's more because of what XC8 calls procedural abstracion (i.e: find out which blocks of code repeat and put up a complex set of calls so that every block that is repeated is called only once. Won't help much for speed, good luck debugging that) rather than better optimizationXC8 supports new MCUs, XC8 has actual support, free and paid.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: May 03, 2022, 01:22:34 pm
content: In contrast, ARM has several competing ABIs; though I think none-eabi is the most common/popular/supported right now? The others may be older, or maintained for support on specific devices (no Thumb support? old library compatibility?), I don't know that much about ARM as yet. Anyway it's no surprise, ARM is much older and has more versions. Also while the core itself has been maintained by ARM, its integration has largely been customer driven, and so too the software, at least beyond basic (core compatible) libraries I would assume. So, any time you get a new OS, or compiler, or whatever, there's potential opportunity for tweaking the ABI, and a new contender emerges.In contrast, the x86 ecosystem has almost entirely settled on the ancient Intel/IBM/MS convention, i.e. procedures begin with PUSH BP; MOV BP, SP and end with POP BP; RET  (with operands on the stack, n). Even in AMD64, where they had the opportunity to change much more (having more, general purpose, registers), they stuck with a similar convention. x86 I think, isn't generally available for integration? And it's only ever had, what, two or three OSs supported on it, though a host of compilers (but, they all have to target those OSs). So it's a very different ecosystem than ARM or AVR, yet still a very stable ABI, like AVR.Tim

author: JPortici
author_rank: Super Contributor
timestamp: May 03, 2022, 02:05:21 pm
content: Quote from: AaronD on May 02, 2022, 11:34:05 pmyoucoulduse ipe-cmd for programming, which is what's running under the IDE/IPE anyway. IPE is just a gui that controls ipe-cmd.However ipe-cmd seems to be another huge pile of crappily written java, there is so much latency inside it's unbeliveable. The actual programming is almost as fast as in programmer-to-go mode (80%-99% of theoretical speed depending on part and firmware image), but the set up and the time from pressing enter to actual execution.. gosh

author: westfw
author_rank: Super Contributor
timestamp: May 03, 2022, 10:19:06 pm
content: QuoteNope. The 8bit PICs are Accumulator/Memory architecture. Although the amount of "memory" (which PIC calls "file registers") at one time is somewhat limited (and memory is "banked", which is a pain for C to deal with.)QuoteDoes not.---I wish people would stop posting data based on long-obsolete compiler versions. The XC8 "free" version has improved since its initial releases. avr-gcc alsochangesfrom version to version, sometimes in good ways, sometimes for the worse. The 8-bit PIC architecture was designed before C was popular, and is spectacularly unfriendly to "typical" C compilers; it's something of a miracle that the available C compilers work as well as they do.Which is "faster" is largely irrelevant. You don't need "the fastest" cpu in your application, you only need one that is "fast enough." (something that has become really clear with the advent of cheap ARMs that are "clearly" much faster than 8bit CPUs.)PICs have really clear architectural "problems", and while the AVRs have "less" such problems, they're more "hidden." (Of the "General Purpose Registers" only half work with "immediate" instructions, there are only 4 register pairs, and only 2 real "index" registers (well, sort-of 2.5) There are special instructions for accessing "some" of the peripheral registers, but as the number of those has increased, many are no longer accessible by the special instructions.) They all have "warts." (and don't get me started on the Cortex-M0 warts and gcc deficiencies!)

author: jpanhalt
author_rank: Super Contributor
timestamp: May 03, 2022, 11:54:34 pm
content: Quote from: westfw on May 03, 2022, 10:19:06 pmCurrent 8-bit PIC's (e.g., 12F1xxx, 16F1xxx and later) have the entire user RAM mapped to "linear RAM," which acts like contiguous space, but it is not. Common RAM is spared and is still usable in its entirety. Linear RAM is usually accessed using the FSRx registers and no bank switching is needed. I still use banked RAM for working registers. That may be a pain for C, but not for Assembly, as one should know what bank is being used. I use linear RAM for buffers, e.g., a FIFO or GLCD screen buffer.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: May 04, 2022, 12:35:00 am
content: Quote from: westfw on May 03, 2022, 10:19:06 pmOh yeah, not to forget banking..!QuoteI... use avr-gcc 8.1.0, it's not exactly obsolete? It generates exactly these calls. I don't know offhand exactly when it's able to inline the calls or do any optimizations, but the claims are consistent with the observations.QuoteSpeaking of "faster", if CPU speed is an issue -- obviously, none of these 8-bitters will be what you need!Tim

author: JPortici
author_rank: Super Contributor
timestamp: May 04, 2022, 05:34:58 am
content: Quote from: westfw on May 03, 2022, 10:19:06 pmbut mooooom i want to play microcontroller wars/ hold on somebody on the internet isWRONGpick whichever you prefer

author: westfw
author_rank: Super Contributor
timestamp: May 04, 2022, 05:39:08 am
content: This is avr-gcc 5.4, the most recent "vendor supported" version:Code:WWHackintosh<2266> cat multiply.c #include <avr/io.h>volatile int x,y,z;int main() {z = x * y;}WWHackintosh<2267> avr-gcc -Os -mmcu=atmega328p -g multiply.c -nostartfilesWWHackintosh<2268> avr-gcc -Os -mmcu=atmega328p -g multiply.c -nostartfilesWWHackintosh<2269> avr-objdump -S a.out00000010 <main>:z = x * y;10: 40 91 00 01 lds r20, 0x0100 ; 0x800100 <_edata>14: 50 91 01 01 lds r21, 0x0101 ; 0x800101 <_edata+0x1>18: 20 91 04 01 lds r18, 0x0104 ; 0x800104 <y>1c: 30 91 05 01 lds r19, 0x0105 ; 0x800105 <y+0x1>20: 42 9f mul r20, r1822: c0 01 movw r24, r024: 43 9f mul r20, r1926: 90 0d add r25, r028: 52 9f mul r21, r182a: 90 0d add r25, r02c: 11 24 eor r1, r12e: 90 93 03 01 sts 0x0103, r25 ; 0x800103 <z+0x1>32: 80 93 02 01 sts 0x0102, r24 ; 0x800102 <z>

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 04, 2022, 05:44:12 am
content: Quote from: T3sl4co1l on May 03, 2022, 01:22:34 pmNo.There are two main ABIs: Microsoft/Intel andSYSV. While most people are familiar with the MS one because that's what they had at home as kids, the SYSV ABI is what the proper commercial systems (mostly Unix variants and compatibles at that time) used.Quote from: T3sl4co1l on May 03, 2022, 01:22:34 pmNo, quite a few more.MS-DOS, CP/M-86, Novell Netware, OS/2, BeOS, FlexOS, Solaris, Linux and Android, OpenBSD, FreeBSD, DragonflyBSD, NeXTSTEP, and VxWorks, at least. I'm sure there are four or five commercial Unix variants missing from the list, too.Both Via and AMD produced automotive x86 boards over a decade before Intel NUCs (released in 2013). I'm not sure exactly what they were used for (aviation entertainment? automotive enthusiasts? I dunno), but things like PicoPSUs were easily available in2006, for example. (PicoPSU is an x86 and x86-64 compatible DC-DC power supply with 12V input, in an ATX-compatible form factor. ATX is a motherboard standard.) The Mini-ITX form factor was developed exactly for such use cases. I know, because I had a VIA one in 2006 or so, just for tinkering.The x86 history is much more vibrant than might appear to a casual MS-DOS/Windows PC user!

author: westfw
author_rank: Super Contributor
timestamp: May 04, 2022, 05:56:23 am
content: __mulsi3 in avr-libc does a 32x32bit multiply, and while it's a function, it still uses the MUL instruction internally:https://github.com/gcc-mirror/gcc/blob/master/libgcc/config/avr/lib1funcs.S#L422(and I get the same code I posted above, even with gcc 8.1)

author: hans
author_rank: Super Contributor
timestamp: May 04, 2022, 08:31:57 am
content: https://godbolt.org/z/qoE9f1x34Seems fine to me, don't even need an optimizer. However, if you don't tell GCC what MCU you're using, then it will call the library function __mulhi3, which is a non-mul instruction multiply.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: May 04, 2022, 09:44:11 am
content: Aha, think I was thinking of mostly 32 bit operations: see this monstrosity for example,https://godbolt.org/z/b6nr8xEeK(fromhttps://github.com/T3sl4co1l/Reverb/blob/master/dsp.c, contrast withhttps://github.com/T3sl4co1l/Reverb/blob/master/asmdsp.S#L529which runs some 2-3 times faster.)Strange, I must not use 16x16 = 16 operations much then! That explains the confusion.Quote from: Nominal Animal on May 04, 2022, 05:44:12 amHmm lemme see here... yeah they're all using BP for stack frame. I gave that aspect as example of what level of generality I was thinking of. Which.. if I'm not mistaken, actually all the ABIslisted on Wikipediause the BP motif then? Which honestly I'm a bit surprised to see, but I guess it's just that practical to use.Is... is it not actually useful to speak of "ABI"s in such general terms? Like... I don't write compilers, I don't care what it is, I look at the spec sheet every time I'm writing ASM alongside compiled code. It could have params/returns from a different set of registers just about every time and I might not notice. Is this a thing people are actually extraordinarily picky about? Computers themselves, yes of course, if it doesn't match exactly that's a problem; but I'm a people here, talking to other people?QuoteWell yeah, like I said, about three?MS-DOS is just whatever, as well as anything earlier. CP/M was... oh, they used zero-page calls wasn't it? And just kinda went with it, porting to 8086. Which became the uh, 0-0xff program header thing in DOS. Or did they use soft INT calls like MS-DOS too? I don't know. And the MS-DOS and BIOS INTs always struct me as an odd mish-mash of register usage; but whatever, they can do it however they want, it's an interrupt not even a call, it has to return very clean aside from the couple things it returns.So then of the, let's see, OS/2, MS-DOS, Windows (granted, win16 and win32 APIs are pretty different), large similarities there; BeOS, what was, oh yeah I've heard of that, also a "commercial failure" so... it existed? Sure, but like, all those shitty ASM programs I wrote years ago, exist... do I get to invent ABIs for them too? What's the threshold here? And what, Solaris, Linux, Android, FreeBSD, NeXTSTEP---hey wait, that wasn't even x86, that was 68k wasn't it?! -- all share that common *nix thread. Maybe that's not common enough to share ABIs, I don't know. I would imagine they pick up common features from their respective platforms.Oh I see, NeXT did actually have a i386 etc. port. Like..why?..Tim

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 04, 2022, 11:22:37 am
content: Quote from: T3sl4co1l on May 04, 2022, 09:44:11 amAh, okay. Yes, that is a result of the 80x86 instruction set and register architecture (see e.gref.x86asm.net).The idiom is so deep that Intel later added the instructions ENTER and LEAVE to construct and tear down the stack frame using EBP and ESP exact that way.Basically, the sum-of-two registers indirect addressing mode only supports four register combinations:[BX+SI],[BX+DI],[BP+SI], and[BP+DI]. BX register is one of the four that is split into two sub-register halves, BL and BH. SI and DI have auto-incrementing addressing modes, and are used for other indirect addressing modes. That basically leaves BP for the stack frame. (SP being the stack pointer itself.)However, GCC for example does support-fomit-frame-pointer, and Intel Compiler Collection supports/Oy, which both omit reserving BP for the stack frame, if at all possible.Quote from: T3sl4co1l on May 04, 2022, 09:44:11 amWelp, I don't usually go into the details, no; they're not that useful, really. The differences on x86 are quite small, anyway.On x86-64, the calling conventions differ significantly. In particular, MS calling convention places thefourfirst integer or pointer parameters in registers, with up to four XMM registers for floating-point and SIMD parameters. SYSV places thesixfirst integer or pointer parameters in registers, and up to eight XMM registers. Any additional parameters will be put on the stack, which for very "hot" functions, can cause a notable slowdown.(In other words, that for portable efficient x86-64 code, one prefers to keep the number of integer or pointer parameters per C call to four or less, plus up to four floating-point or xmm parameters; but for non-Windows C code, up to six plus eight is fine. That's about it. I'd need to re-check for C++, but I typically just assume the standard library uses a hidden pointer for the object, but otherwise uses a similar calling convention.)Quote from: T3sl4co1l on May 04, 2022, 09:44:11 amI mostly pointed out those because it is a whole other culture (Unix, VxWorks, and the much rarer embedded folks) that wasn't Microsoft on x86, and those who did use DOS or Windows way back when, often erroneously think that that was all that 80x86 was used for. No, there was a LOT more.Moreover, there was a lot of standardization efforts outside the Microsoft enclave, especiallySingle UNIX Specificationthat becamePOSIX(IEEE Std 1003.1).Quote from: T3sl4co1l on May 04, 2022, 09:44:11 amThat varies between the ABIs/calling conventions. On the 8086, 80186-80486, theintinstruction is basically the easiest way to do a "syscall".x86-64 (AMD64 instruction set) provides a separatesyscallassembly instruction.In the MS-DOS era, it was common for each compiler to have their own calling convention; there wasn't an ABI per se, except maybe for BIOS and such.One of my first proper paid programming gigs in the early-mid nineties was to copy-protect a commercial MS-DOS program, so that each copy was different, and contained a difficult-to-replace version identifier. A key part of that was that I replaced the EXE relocator code with my own hand-written one, which modified (not frobnicated, but close) basically all of the code, and failed if the key in the file itself did not match what the relocator code incidentally produced. (Basically, each serial number was then a random number.) The funky part of that job was that I didn't get any access to the source code (talk about paranoid people!), and I actually wrote most of the assembly code using MS-DOSdebug.exe.In other words, even the "run-time linker" itself was provided by the compiler, and not the OS.It is important to note that the x86 BIOS, too, became much more complex whenACPIcame around. It is nothing like "load some registers and then runint 0xHHanymore.Quote from: T3sl4co1l on May 04, 2022, 09:44:11 amActually, the commonalities were more due to a desire for compatibility, especially in the C compilers. The86open(that started in 1997) is what brought Linux so close to Unix. Their work completed in 1999, when theELF file formatwas chosen for executables and dynamic libraries across most operating systems running on x86. Even Intel participated, and started efforts that eventually made their Intel Compiler Collection compatible enough with GCC to be used in SYSV ABI OSes on x86. At and after the turn of the century, if the OSes used the same calling convention, you could run binaries for one operating system on a completely different operating system, using a simple "shim" layer in between!How many of you have heard ofOpen64? It is the GPL-licensed C compiler AMD provided for the new AMD64 (x86-64) instruction set, and what Nvidia used to optimize code in their CUDA toolchain. It continued the standardization path that bridged different companies and open source projects in the nineties on x86, and in some ways culminated in ISO C99 and POSIX.1-2001 (IEEE Std. 1003-2001). Around that time, Microsoft saw the existing standardization efforts as their opponent, and did all sorts of nefarious stuff, that basically stopped any further cross-platform standardization for well over a decade. (Even their brightest star, the Annex K "safe" bounds-checking interfaces (the ones with the_ssuffix you see in Microsoft documentation, is being discussed as to-be-removed in a future version of the C standard, as there isn't any real use for them.)In a very real sense, a lot of positive momentum –– not towards asinglegoal, but towardsinteroperabilityand modularity and freedom of choice –– was lost soon around the turn of the century. We might be at the point where we have most of that back, but I'm not sure (as in I do not know; I do not have enough information to be sure one way or another).Even GCC development stagnated horribly, becoming a cult-like gathering of "if you don't have a PhD in Computer Science, we shall not read your messages, you peon" self-aggrandizing idiots. (I believe it was a big reason why AMD supported Open64 so much more than GCC.) I guess it was the appearance of LLVM and Clang, and a new generation of developers, that managed an internal change in GCC. It's still a slow and cumbersome to participate in, but it's definitely better than it was at some point! And GCC is significant, because not only does it support a huge swath of different hardware, but it has quite a few language backends, too.So, yeah; many of the choices done were compromises, but they were done for a good reason, to achieve at least the possibility of interoperability across operating systems on x86.

author: westfw
author_rank: Super Contributor
timestamp: May 04, 2022, 05:30:54 pm
content: QuoteWell, yes. Of course...Code:accum = accum + (int32_t)*ptr1++ * *ptr2++;vsCode:; r25:r24:r23:r22 += mul_signed(r21:r20, r19:r18)Those do substantially different things (logically, not mathematically!)C in general does a particularly poor job of "mixed size arithmetic" - it doesn't have the concept, and has rules that say it can't.(IMNSHO, this provides one of major excuses for "dropping into assembly language" in a C program. (another is "access to carry or other status bits")

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 04, 2022, 06:37:03 pm
content: Quote from: westfw on May 04, 2022, 05:30:54 pmAgreed; in fact,Am×Bn+Ckwithn,m,kreferring to different sizes in bits of the terms, is a very typical use case for me to use GCC/Clangextended asm. The case wherek=m+nis the most common, obviously, but fixed-point variants (with rounded result) can be extremely useful, too.On architectures where the multiplication instruction can take arguments in different registers, extended asm in an inlined helper function means the compiler can choose the registers used at each call site, and generate pretty darned good codearoundthe assembly snippet.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 04, 2022, 07:52:00 pm
content: For carry, I've used GCC's builtin functions such as '__builtin_add_overflow' and the like.

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 05, 2022, 07:42:42 am
content: I have as well. Also, usingvector extensions, defining a SIMD vectorized data type via something liketypedefbase-typevectorized-type__attribute__((vector-size (N* sizeof (base-type))));(as an array ofNbase-typecomponents pervectorized-typevariable or member) does not actually require hardware SIMD support, nor SIMD support for that component count; but the compiler will generate very good code, using SIMD if possible, for basic algebraic operations (addition, subtraction, multiplication, and division) done component-wise in the vectorized data type.That is,Code:typedef float vec4f __attribute__((vector_size (4*sizeof (float))));static inline vec4f vec4f_mul_add(const vec4f a, const vec4f b, const vec4f c) { return a*b + c; }generates SSE/AVX code on x86-64, NEON code on ARMs with NEON vector extensions, and so on. On architectures that support a pair of floats (like say MMX on Pentium 5), the compiler implements it as a pair of vectorized values. Nice.You can also treat it as an array. For example, a dot product operation using the same type could be written asCode:static inline float vec4f_dot(const vec4f a, const vec4f b) { a*b + a*b + a*b + a*b; }(For those wondering, theinlineabove does not actually tell the compiler anything; it does not force the code to be inlined at all. It is just that to reduce cognitive load, I usestaticto denote ordinary functions useful in the current file scope only, andstatic inlineto denote simple helper and accessor functions. That is, the presence ofinlinethere is only a hint for us humans, and irrelevant to current C compilers. I often replace it with a preprocessor macro, something likeHELPER_FUNCTIONorHELPER, that expands to appropriate compiler/OS-specific definition; often into__attribute__((unused, always_inline)) static inline, to denote that it should be inlined and that it is okay/normal if the function is never used, in which case the compiler does not need to bother to emit code for it at all.)This is supported by GCC, Clang, and Intel Compiler Collection at least, but is not standard C at all.

author: westfw
author_rank: Super Contributor
timestamp: May 05, 2022, 08:45:26 am
content: QuoteHuh. I didn't know that existed. It looks neat for the multiply/accumulate sort of things that DSP uses, but my goto application is an IP checksum, where you can fold the ones-complement wrap-around carry into the add of the next word, with a bit of care.Code:| (old MIT 8086 cross-assembler syntax. Sorry about that!)xor bx,bx | initial value for xsum, clear carrylpchk: lodw |get next word 1 byte, 16 cyclesadc bx,ax |overlap adding last CY 2 bytes, 3 cloop lpchk |next word 2 bytes, 17 cmov ax,bx | put where results have to goadc ax,*0 | add final carry bit.I don't see how to do that with the gcc built-ins. (I guess it additionally depends on having a loop counter that you can decrement without affecting Carry...)

author: NorthGuy
author_rank: Super Contributor
timestamp: May 06, 2022, 01:30:38 pm
content: C has lots of built-ins for using CPU specific commands, but I find it much easier to write assembler directly.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 06, 2022, 05:48:26 pm
content: Quote from: NorthGuy on May 06, 2022, 01:30:38 pmDepends on your perspective.But some of the built-ins, such as the ones I mentioned, are not CPU-specific, which makes them portable (as long as you use GCC, and I bet a number of them are also supported by Clang).I've written an arbitrary precision arithmetic library, and it's portable. It uses this kind of built-ins for some operations. I didn't write any CPU-specific code, and I'll get better performance than if writing pure C only - but of course, writing some critical parts in pure assembly would be more efficient (I think that's what GNU GMP does), but maintenance and portability would be annoying.

author: Simon
author_rank: Unknown
timestamp: May 08, 2022, 07:15:52 am
content: Microchip seem to like shooting themselves in the foot. They abandoned their IDE and are trying to make people abandon the atmel IDE. MPLABX is a massive nightmare. It feels like no two installations will ever be identical and it constantly demands to have you update little packs. It does not ooze confidence. Their code configurator in MPLABX is awful, I won't even touch it, atmel studio has a code configurator that looks much better but clearly they intend to just abandon it, links to documentation don't work. So I am using a basic ARM chip because it is all I could get hold of and writing my own initialization code. I'm only using a microchip/atmel chip because it's what I could get hold of at the time, I did not choose it because I like their idea of not support.

author: Pineapple Dan
author_rank: Contributor
timestamp: May 20, 2022, 04:12:30 pm
content: Quote from: Simon on May 08, 2022, 07:15:52 amTheir code configurator indeed isn't particularly great but it is an absolute dream compared to setting up a simple GPIO pin in Zephyr

author: Simon
author_rank: Unknown
timestamp: May 20, 2022, 05:54:40 pm
content: Quote from: Pineapple Dan on May 20, 2022, 04:12:30 pmbelieve it or not not all of us are pathetic teenagers that cannot tell the difference between their arduino or an OS application and embedded programming where you have to actually use brains, skill and some experience to produce something. I won't use configurators, the day they fuck it up I am fucked! Why hang my career on a bunch of assholes like those that mismanage at microchip?

author: AaronD
author_rank: Frequent Contributor
timestamp: May 20, 2022, 06:05:47 pm
content: Quote from: Simon on May 20, 2022, 05:54:40 pmIt's a good way to get started when you don't have a clue how any of it works, and you have to understand most of it all at once before you can be sure that something isn't waiting to bite you......provided that the tool actually matches the product and doesn't have bugs in it.But yes, as you gain understanding, I think you should get away from the automatic tools and write the init code yourself, manually. The better you are at doing that, the better you can make the chip work for you, instead of the other way around.I write this as a decades-long 8-bit guy trying to figure out a Raspberry Pi Pico (RP2040). Everything looks to be spelled out in the datasheets (several of them, which itself is new), but there's enough going on that I think I'll be back to the library functions for a while.

author: Simon
author_rank: Unknown
timestamp: May 20, 2022, 06:18:10 pm
content: The code configurators setup the peripherals, if you don't understand the peripheral then either you won't be able to use the configurator at which point part of redocumenting the train crash that the datasheet is is to write that init code. Some peripherals are rammed with subtle options that may not make it into the configurator or without thorough understanding of what you are doing are wasted on you, or your money was wasted on the chip. Sometimes you need to do something a bit special that no configurator can account for.Because no manufacturer gives a shit about helping you and just wants your money they suck you in with the peripheral setup, confuse you with higher level functionality that need not be tied to the hardware and before you know it you are using just another arduino.I've been working away at a samc, yes it's a pain, but the code configurator will not teach you the pitfalls, you either do it one way or the other, they have little to do with each other unless you go digging in the code to find out how it works but then that is not why you are using a configurator.....

author: T3sl4co1l
author_rank: Super Contributor
timestamp: May 20, 2022, 08:23:40 pm
content: Quote from: Simon on May 20, 2022, 05:54:40 pmY'all right there pal?For my part, code generation is fine. As with anything, it's how you use it, don't assume it knows what it's doing -- or that you know what you're doing, for that matter.If in doubt, come up with a test to figure it out.And never lose sight of what code is. It's for humans. (As unbelievable as that may sometimes seem for C...) Any random language will do for the machine, with whatever degree of translation might be necessary (whether trans/compiled, interpreted, emulated..). We choose to work in higher level languages, because it's easier, more powerful. So, what's the point? Use whatever is most accessible and familiar for anyone who may be reading your code. So if that means using mfg recommended tools, code generation and etc., probably use that. If a GNU or other free toolchain is reasonable enough, probably use that. The more you cook from scratch, the less familiar it will be to others, and the more important it is to be well written.Which, mindmyaudience, here -- if you're just getting started, or inexperienced, or tend to be a bit too clever for your own good -- pace yourself, tone it down, let the tools work for you. Make your intentions known, try to leave insightful comments (AND KEEP THEM SYNCED WITH THE CODE), don't prematurely optimize. CPU cycles are cheap, stick to easy-to-use, well-trodden platforms. If you're experienced, you write clear code, you're prepared to deal with less common, less well documented platforms -- by all means, rock on.If you aren't writing for anyone -- just pet projects and such, maybe you don't even intend to publish it online or anything -- sure, anything goes, get experimental, no problem. Just don't burden others with spaghetti code and lacking comments.Except when that's the point, in which case send it off to ioccc or whatever.Tim

author: Simon
author_rank: Unknown
timestamp: May 20, 2022, 09:21:58 pm
content: I don't have a problem with a functioning code generators but what microchip offer is several different versions of a mess. It's not even clear what to use for new projects. I hear lots of good things about the STM32 system. naturally things it offers are nothing to do with the hardware at all like screen/gui creations which could probably be used on any mcu but for the fact that you have now been locked to that manufacturer, hm.September last year I had been in my new job for 3 months. Various future projects had been mentioned and I was getting anxious. I had no MCU's. I had spent 3 months trying to find replacements for parts that the design subcontractor had been unable to find or that build contractors could not get. I had been giving my opinion on the limited and now expensive options for buying the STM32 parts used by the current projects: I don't have one, it's 50/50 that they are genuine and work just because I don't want you to blame me when several £1000's tits up wit the products.I explained to my boss that given the supply situation we needed to purchase 2 years worth of stork of ANY MCU just so that we had some knocking around for potential projects with enough leeway to buy more before we run out with a years warning. So he agreed and I went hunting, I did consider the STM32 parts, including a good look at what we were already using but none available or the prices were quite high. For what I am doing I only need an M0/+, I had been looking at the samc parts because of the CAN availability and good price and they are safety rated which in my previous job was a good start but not needed here but still at $1.47 each they trumped similar spec chips from STM on price given the demand and no availability.Now my experience was highly limited with the samc and I had set myself the task of finding anything and bare metal programming it, but at $1.47 each in 1000 and with some basic exposure to it the samc was ideal as a basic start and we could get them in November. Early December a "big" order of less than 20 units landed for something I had been working on that i inherited using the arduino/samd, we had the chips in stock and delivered. Now we are doing a new batch.the samd of course was also unobtainium as everyone is probably using it in their arduino based projects - yuk.i would love to find a source of higher level libraries wiuth proper instructions that are not architecture locked but it's hard. Now if you look at the price of a PCB with an SNTM32 based on an M3 or M4 you may as well get a PI-0 board for the same price and leapfrog into GUI projects with all that support operating systems give you. Currently we - me and my new apprentice who can none the loss teach me a thing or two - are developing a project that uses a PI 3 for the heavy graphical stuff accompanied by a samc to do the real time stuff. Perfect solution. Yes he insists on spending a week to get the microchip configurator to work, but in less time I wrote start up code for the same peripherals he uses and he had to give up on the ADC DMA only to end up after 2 days of messing about with the same result in the configurator that I had with less than a day writing code.

author: Rudolph Riedel
author_rank: Regular Contributor
timestamp: May 22, 2022, 04:36:24 pm
content: I like to use ATSAMC21 and ATSAME51 but it looks like the next time I can get some fresh ATSAMC21J will be 10/2023, maybe. :-(At least I have a few more ATSAME51 and the ATSAMC21J and the ATSAME51J electrically only have 1 pin different, so I already have designs on which I could populate either with the help of two configuration resistors.In the future I probably will only use ATSAME51J19A-AU and buy a few more.STM32H7 looks interesting but is unobtainium as well.All the manufacturers would do themselves a favour if they would feed some stock to catalog distributors like Mouser and Digikey.Right now there is a good chance that I give up on hoping to get more ATSAM when I find a controller family from some other manufacturer to replace these with - and the bar is getting lower.

author: Simon
author_rank: Unknown
timestamp: May 22, 2022, 08:14:16 pm
content: For microchip buy direct, for STM32 go screw, TSM won't let you pre-order, you can sign up for a notification when they are in stock, I expect by the time you get to them they will be sold out to the dealers. So STM are not looking very hopeful for me.

author: chickenHeadKnob
author_rank: Super Contributor
timestamp: May 22, 2022, 09:21:53 pm
content: Quote from: Rudolph Riedel on May 22, 2022, 04:36:24 pmMy intuition on STM32H7 and other similar desirable higher end parts is that many folks have designs ready or nearly ready to go and are simply waiting for them to come back. Thus prolonging the shortage for those parts in particular. You need to apply game theory and guess which expedient parts are lowest in demand and will be first in surplus.

author: NorthGuy
author_rank: Super Contributor
timestamp: May 23, 2022, 04:54:24 pm
content: Quote from: chickenHeadKnob on May 22, 2022, 09:21:53 pmShortages affect everything. It is impossible to predict the future. The best strategy is to buy what you can and re-design.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 23, 2022, 05:02:23 pm
content: Yep. The times are better either for the very large corporations that can hoard large stocks and manage to have priority anyway, or for the companies selling low volumes of very high-margin products (then you can handle relatively modest stocks and still make a profit.)

author: Simon
author_rank: Unknown
timestamp: May 23, 2022, 05:56:55 pm
content: Quote from: chickenHeadKnob on May 22, 2022, 09:21:53 pmWhich is what I did and picked SAMC, a part that I have to actually program, pitiful code configurator no one will want to use and not used in arduino or other stupid open source or IoT crap.With high end chips there will be people hoarding just in case like I bought 1'000 parts that I knew were more than capable enough so that I could do anything with them. My new colleague wanted to buy STM32's but to get any worth using given that we have an M0+ solution already would be so expensive that we won't.

author: westfw
author_rank: Super Contributor
timestamp: May 23, 2022, 08:29:36 pm
content: QuoteMattairTech has a core for Arduino that supports SAMC21.Even if you really hate Arduino, it can be useful to look at their code (MattairTech's code, I guess) to see how they have initialized things (for example.)

author: Rudolph Riedel
author_rank: Regular Contributor
timestamp: May 25, 2022, 05:05:37 pm
content: Quote from: Simon on May 22, 2022, 08:14:16 pmGood one, most of what I am looking at has an estimate shipping date of 31-May-2023, much as the rolling dates on Mouser.And most orders need to be in multiples of 160 if not 1500.Then I found one item with incoming stock of 81 in june but could not pre-order since it could only be ordered in multiples of 160.Order now and you may receive some day.At least I ordered enough CAN-Transceivers directly from TI before things got ugly.Now I ran out of digital isolators.

author: Simon
author_rank: Unknown
timestamp: May 27, 2022, 12:13:47 pm
content: Quote from: westfw on May 23, 2022, 08:29:36 pmI can use the code configurator as an example, it will be less crap than anything arduino like. I just wont use the arduino it would be a ridiculous business decision.

author: Brianf
author_rank: Regular Contributor
timestamp: May 27, 2022, 07:10:46 pm
content: Quote from: Simon on May 27, 2022, 12:13:47 pmWhy would it be a ridiculous business decision?Surely good business decisions are about delivering the right product at the right time, and at the right price. If using Arduino achieves that then what is the problem?

author: Simon
author_rank: Unknown
timestamp: May 27, 2022, 08:06:42 pm
content: To rely on something like that is not a good idea at all. My main requirement is libraries for higher level stuff, anything that is about setting up peripherals needs doing properly. It's a bad business decision to use a system that hides the majority of the hardware from you. I want to use the hardware, not ignore it.People seem to be obsessed with programming microcontrollers like they are running an OS or are a larger computer. Microchip confused the hell out of me by calling interrupt routines callbacks, a callback is a software interrupt in an OS, nothing to do with a microcontroller hardware interrupt, but clearly they target the software developers.Arduino is all about the software and totally ignores the hardware. So people will be running around mimicking what the hardware will do for them using slower software constructs.I like to know that when I open my code tomorrow it is exactly as I left it and that I am not trouble shooting someone elses problem as I have in the past with arduino.Unsurprisingly Arduino are now targeting the industrial market as monetising the arduino no longer works. Industrial stuff wants to be safe etc. my guess is that they will now be selling licenses in the same way freeRTOS does if you want to use it in something safety critical. Good business move.

author: Simon
author_rank: Unknown
timestamp: May 27, 2022, 08:10:09 pm
content: Quote from: Brianf on May 27, 2022, 07:10:46 pmYes, and at a time when I could not get a SAMD because it is used in arduino and everyone wanted them I chose another chip and resolved to do it the hard way. As a consequence my employer is very happy with the fact we have delivered on time, my time (money) spent bare metal coding taught me a lot that will save a lot of time in the future and instead of some STM32 that was inflated to £14 I got perfectly adequate chips for £1.50. So yes at the right time certainly, price uh you can argue about the value of development time and the cost of debugging stuff you did not write.

author: westfw
author_rank: Super Contributor
timestamp: May 28, 2022, 02:26:34 am
content: QuoteNormally when the subject comes up, we conclude that "the hobby market" is too small to have much impact on sales of a manufacturer as large as Microchip...(Right now, of course, everything is unobtainium, whether it's used in Arduino, or used elsewhere. :-( )QuoteIf you say so. I thought your string of recent complaints was based on the configurator NOT working on your target chip...

author: Simon
author_rank: Unknown
timestamp: May 28, 2022, 07:10:59 am
content: I'm sure plenty of companies use arduino too, I remember selling some atmega328's through ebay to a company, I believe they did safety stuff....... People may also be using the SAMD for non arduino stuff, at the time SAMD or SAMC were the same to me, I would have used either but SAMC was about to be available so I woent with that, they are similar chips.Yes I do hate the code configurators, but my colleague uses them as he does not see the value in spending time on registers and as much as he hate microchips particular sluttering he uses it anyway. So I don't mind letting him set the peripheral up for me in a project with it so that I can then go in and look at the code to see that I have understood it correctly.one day people might realize that their projects are broadly similar and they may be relying on their own standard boards so actually setting up the whole thing with a code configurator becomes more time consuming than taking a copy of your own template code that has already got all the settings you plan to use. If I didn't want to do registers I'd get something running a proper OS and learn to use that.

author: voltsandjolts
author_rank: Unknown
timestamp: May 28, 2022, 01:39:58 pm
content: I have a lack of trust in configuration tools, but viewed as a reference for getting configuration done in your own code, they're quite useful.

author: Simon
author_rank: Unknown
timestamp: May 28, 2022, 03:12:21 pm
content: Quote from: voltsandjolts on May 28, 2022, 01:39:58 pmQuite. The little look I have had at microchips I need to understand the hardware so have to read the datasheet in detail, by the time I have done that I can simply write some code myself that is in english with copious comments and whatever I like to explain to my future self what I was thinking.I looked at the code to set a counter up. having got a signal it confirmed that the debugger could not show what the counter value was so I wasted a day or more trying to strat the counter not realizing it was running.I did learn that to check if a sync bit is set busy something I thought should work did not. I thought thatwhile ("sync reg" & "my mask of bits to test") {}should work it turned out that this was not the case. The configurator code used:while ("sync reg" & "my mask of bits to test" == "my mask of bits to test") {}which when I replicated it worked, who knew, to me they look the same. but solved.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: May 28, 2022, 07:52:39 pm
content: Yeah if you need "mask of bits" plural, and need all of them, you need the equality. Or if some should be low, equality to the desired states. If it's just one bit, it's equivalent to truthiness (or falsity) of course.Tim

author: nigelwright7557
author_rank: Frequent Contributor
timestamp: July 13, 2022, 02:33:50 am
content: I have used PIC's since 1985.Was a PIC consultant for 13 years.So done hundreds of PIC projects.The current situation is most SMD PIC's are not obtainable.I have been resorting to using through hole PIC's as I can still get some.MPLAB is huge, not easy to navigate and error prone.My PICKIT 3 does fall over now and then.I found the Snap to be more reliable but it needs the pcb powering to use it. Just a cut down and cheap pickit 4.I found debugging is difficult with MPLAB if you use compiler optimisation. It gets hung up about optimised code and ends up with broken breakpoints.The PIC's can be pretty horrible. i/o pins that have strange uses and mean you cant use a full port to pass data. i.e. VUSBThe smaller PIC's have none linear memory spaces which can sometimes cause problems.I no longer use assembler and just use XC compilers. Most of my projects are converted to C now.