Why do people not like Microchip?

[AaronLee]

Well 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.

Very 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.

[Bassman59]

I really don't understand what the attraction is to Eclipse, other than it's free.

My 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."

[JOEBOBSICLE]

Well 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.

Very 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.

With 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.

[rcbuck]

for ARM I prefer to use either Rowley CrossWorks (or its free-for-non-commercial-use clone Segger Embedded Studio)

Sal, 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.

[nctnico]

I really don't understand what the attraction is to Eclipse, other than it's free.

My 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.

Not 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.

[rsjsouza]

I really don't understand what the attraction is to Eclipse, other than it's free.

My 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.

Not 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.

Well, 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.

[Sal Ammoniac]

Quality MCU documentation is very important to me, and I find Microchip documentation to be generally better than just about anyone else's.

Except 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.

That'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.

While 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.

I 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.

[Sal Ammoniac]

for ARM I prefer to use either Rowley CrossWorks (or its free-for-non-commercial-use clone Segger Embedded Studio)

Sal, 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.

Yes, 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.

[SiliconWizard]

Well 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.

Very 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.

That'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.

[AaronLee]

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.

Yes, 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.

[AaronLee]

That'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.

I 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.

I 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.

I 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.

[Bassman59]

I really don't understand what the attraction is to Eclipse, other than it's free.

My 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.

Not 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.

Well, 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.

My 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.

[rcbuck]

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.

Sal, thanks for the information. That confirms what I thought. Rowley/Segger Studio are really nothing more than another IDE.

[nctnico]

I really don't understand what the attraction is to Eclipse, other than it's free.

My 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.

Not 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.

Well, 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.

My 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.

I'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.

[SiliconWizard]

My 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 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.

[Bassman59]

My 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 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.

Now that I think about it, VScode and NetBeans (used by Microchip Harmony) have it too.

[SiliconWizard]

My 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 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.

Now that I think about it, VScode and NetBeans (used by Microchip Harmony) have it too.

Speaking of VSCode, for those liking the features but willing to avoid any nasty MS hidden code and telemetry, you have VSCodium: https://vscodium.com/

[bd139]

Or just turn it off in the settings...

[westfw]

Atmel specifically designed the AVR for C.

So 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...)

[westfw]

I still use emacs ... but it doesn't have the find-references or find-declaration feature.

Are you not aware of TAGS ?

Code: [Select]

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...)

[Sal Ammoniac]

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.

Sal, thanks for the information. That confirms what I thought. Rowley/Segger Studio are really nothing more than another IDE.

How 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.

[AaronLee]

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.

Sal, thanks for the information. That confirms what I thought. Rowley/Segger Studio are really nothing more than another IDE.

Rowley/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.

[AaronLee]

I'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.

What 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.

[AaronLee]

How 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.

Again, 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 1

Then 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.

[DavidAlfa]

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: [Select]

#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   TRISA3

void 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();
        }
    }
}