Author Topic: I want to start "playing" with ARM micros  (Read 5405 times)

uliano and 2 Guests are viewing this topic.

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15942
  • Country: fr
Re: I want to start "playing" with ARM micros
« Reply #25 on: December 23, 2024, 02:36:17 am »
Yep, I'm probably biased here, but definitely RISC-V assembly, even in its lowest common denominator (RV32E) is a LOT nicer.
 

Offline Doctorandus_P

  • Super Contributor
  • ***
  • Posts: 4009
  • Country: nl
Re: I want to start "playing" with ARM micros
« Reply #26 on: December 23, 2024, 03:24:06 am »
How serious do you want to play this?

If you like "arduino", you can just stick with it, as already mentioned there are plenty of Arm Cortex boards which work with arduino. Mostly ATSAM, but others too. There are some STM chips supported, and that Raspberry thing (which is a dual core processor, with nifty I/O). Another "easy entry" may be with Teensy boards. Teensy uses NXP. There is a big hobby community around those.

If you want to go C on bare processors, (or the simplest breakout boards). Apparently the tools around NXP are of better quality then STM. From Atmel / Microchip, I only use the old Mega's. I've been programming them for years before "arduino" existed and put a lot of effort in my own libraries. I find Atmel / Microchip very annoying, It seems like they make a new and incompatible line of micro's every 5 years or so.
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 4840
  • Country: nz
Re: I want to start "playing" with ARM micros
« Reply #27 on: December 23, 2024, 03:33:41 am »
Another "easy entry" may be with Teensy boards. Teensy uses NXP. There is a big hobby community around those.

Teensy was all originally AVR. It's only the 4.0/4.1 that use the big grunter 600-960 MHz NXP Cortex-M7.

They all support the Arduino IDE and libraries. Teensy 4 has a very slick OOBE with the Arduino IDE.

The only thing is $20+ Teensy 4 with just 1 MB RAM looks expensive these days compared to cheaper full-Linux boards such as the Pi Zero & Zero 2 with 512 MB RAM (and quad core on the Zero 2) or the $5 Milk-V Duo with 64 MB RAM and 1 GHz Linux CPU plus 700 MHz 64 bit microcontroller CPU which supports Arduino.
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 4840
  • Country: nz
Re: I want to start "playing" with ARM micros
« Reply #28 on: December 23, 2024, 03:40:54 am »
Yep, I'm probably biased here, but definitely RISC-V assembly, even in its lowest common denominator (RV32E) is a LOT nicer.

That's CH32V003 (actually RV32EC).

The RISC-V CPU in the Pi Pico 2 / RP2350 is pretty full on other than lacking FPU. A full set of 32 GPRs, plus lots of (standards-conforming) extensions for things such as register-plus-shifted-register for address generation -- not an addressing mode as in Thumb2 but more like an LEA instruction. Also lots of extra bit manipulation instructions including single bit operations (handy on a microcontroller) and multiple-register push/pop for function entry/return.
 

Offline richnormand

  • Supporter
  • ****
  • Posts: 722
  • Country: ca
Re: I want to start "playing" with ARM micros
« Reply #29 on: December 23, 2024, 04:09:02 am »
"I'd like to get into working with ARM micros. "


https://www.edx.org/learn/embedded-systems/the-university-of-texas-at-austin-embedded-systems-shape-the-world-microcontroller-input-output

Took it a while back and it was was excellent. Used ARM micro from TI.
At the time it was free with graded exams and such.

I am sure EDX has similar offerings now. Taking the course real time with exams is much nicer than an archive course with Q/A support from the profs.


Repair, Renew, Reuse, Recycle, Rebuild, Reduce, Recover, Repurpose, Restore, Refurbish, Recondition, Renovate
 

Offline wilfred

  • Super Contributor
  • ***
  • Posts: 1415
  • Country: au
Re: I want to start "playing" with ARM micros
« Reply #30 on: December 23, 2024, 04:29:04 am »
"I'd like to get into working with ARM micros. "


https://www.edx.org/learn/embedded-systems/the-university-of-texas-at-austin-embedded-systems-shape-the-world-microcontroller-input-output

Took it a while back and it was was excellent. Used ARM micro from TI.
At the time it was free with graded exams and such.

I am sure EDX has similar offerings now. Taking the course real time with exams is much nicer than an archive course with Q/A support from the profs.

I didn't want to register a new account and tried to sign in with my microsoft email account. It didn't let me use a personal email account and suggested I use a school account email address.
It also says it costs $200 if you want the graded exams and the certificate. But I see Jonathan Valvano listed and I have seen some good videos on YT on his channel. https://www.youtube.com/@JonathanWValvano/videos

But I want to commend you for actually suggesting something directly on target with the OP's desire to learn ARM architectue and programming.  :-+
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4361
  • Country: us
Re: I want to start "playing" with ARM micros
« Reply #31 on: December 23, 2024, 06:42:55 am »
Quote
There are some STM chips supported [by Arduino]
That's MOST of the STM chips, these days.  (Since ST took ownership of the main "core", and built it on top of the LL libraries.)  There is also an older core that support just a couple of chips (Blue Pill with STM32F103, mostly), but do so on VERY bare metal (IIRC, not using ANY ST IP, due to fear of licensing issues back then.)
Also ARM based are a bunch of Nordic Semiconductor boards, aimed at IoT stuff.  In addition to the "Arduino layer" these also add an OS (MBed, I think) to support the network stacks.)

Quote
It also says it [the TI class based around TI ARM chips] costs $200 if you want the graded exams and the certificate.
That's unfortunate.  I took the class the first time it was offered (when it was free), and it is indeed quite good, and closer to bare metal than most "intro" choices.  On the plus side, they put a lot of work into making the grading work on live hardware that YOU run, which is pretty cool.  Also, the same TI board is (was?) also supported by Arduino.
On the minus side, the chip they were using is getting a bit outdated WRT TI's current lineup.  (Hmm.  The development board is still sold, though.  https://www.ti.com/tool/EK-TM4C123GXL )

Quote
The only thing is $20+ Teensy 4 with just 1 MB RAM looks expensive these days
IMO, that's the wrong way to look at it.  $20 is not expensive.  It may be less powerful compared to similarly priced boards from elsewhere, but a closer-to-bare-metal board has advantages if you're trying to learn ARM Architecture, instead of "linux."  Only the heavily mass-produced boards (from RPi or China) are likely to hit less than $20 for a full development board.

 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 9466
  • Country: fi
Re: I want to start "playing" with ARM micros
« Reply #32 on: December 23, 2024, 07:34:47 am »
Me personally? I use PIC microcontrollers, and I use MPLABX and Microchip compilers to do my development for them - just as Microchip intended. Depending on who you ask, this combination is a steaming pile of junk.

It works because 8-bit PIC microcontrollers are relatively simple and projects are at most medium complexity, also Microchip has been pretty conservative in changing their software offerings compared to some others (people complain about any change, but people complain anyway; but writing C for PIC, compiling and flashing has basically stayed the same). Being low to medium complexity, PIC projects tend to have one developer. Also those who use PICs are also likely to use PICs for everything. Therefore just having a Windows machine and MPLAB installed on it to do the job works just fine.

Things get different with larger projects; teams working on them; external libraries; possibly many different microcontroller families involved. Now you suddenly need real software development practices, including versioning, tool standardization, using scripting instead of pointy-clickys, using actual code instead of code generation, ... And now, imagine that exactly due to this complexity of projects, manufacturers think they can create business value by monetizing this need, and provide tools that manage all this, yet these tools do exact opposite, drive the situation worse. When code generation needs to be get rid off, they add more code generation. When pointy-clicking needs to be replaced with code, they create a library which makes writing code even more difficult and then add a pointy-clicky code generator to generate this impossible-to-write-by-hand code. This is what ST Cube et al really are.

It is an unsustainable equation: it still works when the use case is as simple as PIC. When you still develop on a single computer. When you still don't use anything else than one microcontroller family (e.g. STM32). When reliability and maintainability doesn't really matter; getting something quickly suffices. And when you are a young and eager hobbyist for whom transitioning into new paradigm every few years is fine. But as soon as you break out of these constraints, everything falls apart. This is why we see frequent threads describing the pain of installing, maintaining and updating three different IDEs and development frameworks, one of each going obsolete and transitioning into new framework every year, and creating instruction manuals with screenshots of what to click on pointy-clickys, and so on.

It is much easier in the long run to just adopt normal software development practices: use classic tools; write code and scripts to do things, avoid pointy-clickys and code generation. Luckily, with ARM microcontrollers none of this shit is needed. (Compare this to 8-bit PIC, where Microchip's own compiler is the only option.)

This is also why I think the moment you go from PIC to ARM is exactly the right point of getting rid of the manufacturer tools. They maybe covered 99% of PIC use. Same isn't true for ARM anymore.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6590
  • Country: nl
Re: I want to start "playing" with ARM micros
« Reply #33 on: December 23, 2024, 07:55:24 am »
get an nucleo board, get an st.com account, login.
Then goto the STM32 Youtube MOOC and follow the course.
Expect 40 - 60 hours of studying and playing along with the board.

the MOOC is one of the best courses for ST environment covering basics to detailed peripheral configuration  as ARM microcontroller manufacturers make.
It is as following a paid two week course for free. After that you can choose to go different manufacturers, go bare metal low level or stick to Cube or perhaps back to the Arduino depending on what you like. At least you will have a solid foundation.
 
The following users thanked this post: davep238, Dazed_N_Confused

Offline tooki

  • Super Contributor
  • ***
  • Posts: 13264
  • Country: ch
Re: I want to start "playing" with ARM micros
« Reply #34 on: December 23, 2024, 04:32:45 pm »
If checking different options is not interesting for you, I would also go for an Nucleo board. Keep in mind that there is an (unofficial) Arduino core called stm32duino which supports a good selection of Nucleo boards, they keep a list of the supported boards here:
https://github.com/stm32duino/Arduino_Core_STM32/blob/main/README.md
That began as an unofficial core, but it later came under ST’s stewardship and is now the official STM32 core for Arduino. (The link you posted of the list of cores even calls it out as “official”.)

I agree that the Nucleo boards are a great approach due to supporting both the OEM and Arduino frameworks. I also found the stm32duino people to be extremely responsive: I found a bug in a board definition (LED pin assigned wrong) and they fixed it within hours.

The MCU family I have used the most is ESP32. Compared to that, Nucleo boards have a much better debugger, and the compiler is also much faster. (It’s remarkable how slow the ESP32 (Xtensa) compiler is. The compilers for STM32, AVR, and RISC-V are way faster.)
 

Offline __george__

  • Contributor
  • Posts: 13
  • Country: no
Re: I want to start "playing" with ARM micros
« Reply #35 on: December 23, 2024, 04:47:57 pm »
hat began as an unofficial core, but it later came under ST’s stewardship and is now the official STM32 core for Arduino. (The link you posted of the list of cores even calls it out as “official”.)

Hm, that's interesting, because I saw the statement that it is not officially supported in the STM32duino organizations page which says:
Quote
STM32duino GitHub organization is an open source community, it is not part of the official software ecosystem supported by ST. Nevertheless ST contributes to this community.

But good to know anyway :)
 

Offline tooki

  • Super Contributor
  • ***
  • Posts: 13264
  • Country: ch
Re: I want to start "playing" with ARM micros
« Reply #36 on: December 23, 2024, 04:51:16 pm »
Yeah, I saw that too. But nonetheless, it’s the one that has ST’s blessing. I think by “not part of the official ecosystem supported by ST”, they mean that ST won’t help if you contact them for support the same way they would if you find a problem in their HAL.
 

Offline __george__

  • Contributor
  • Posts: 13
  • Country: no
Re: I want to start "playing" with ARM micros
« Reply #37 on: December 23, 2024, 04:58:24 pm »
Yeah, that makes sense. They just don't want to get "official" support requests about the core, that's all it seems.
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 6436
  • Country: es
Re: I want to start "playing" with ARM micros
« Reply #38 on: December 23, 2024, 07:41:20 pm »
I'd try a basic mcu like the Stm32G0 series, higher end models are quite complex and overwhelming.
HAL is ok for starting or simple projects, you'll learn a lot by checking the generated code.

Unless you really like that, going baremetal without any libs is kinda time consuming, LL is really good.
« Last Edit: December 23, 2024, 07:43:02 pm by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15942
  • Country: fr
Re: I want to start "playing" with ARM micros
« Reply #39 on: December 23, 2024, 08:43:23 pm »
ST's LL is pretty bare and if you only use its header files (it also has some higher-level, albeit not as high-level as the HAL, in its C files, but you absolutely don't need them), it's only a very thin layer above registers, and unless you have a very good reason for doing so (and enough experience for that), rolling your own, which is probably going to be pretty similar, may make little sense. Contrary to the HAL, it does very little else than encapsulate registers access.

One nasty thing with ST is that they have removed all makefile-based projects from their SDKs (they used to provide some), which makes finding out the right compiler options and defines much more annoying than it used to, and is further pushing people to use those stoopid point-and-click IDEs instead of using their own makefiles (or cmake stufff).

For those interested, here are CPU/arch GCC options for a few of the STM32 series I've worked with:

Code: [Select]
# STM32 L4 & F4:
-mthumb -mthumb-interwork -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=hard

# STM32 G0:
-mthumb -mcpu=cortex-m0plus -mfloat-abi=soft

# STM32 U5:
-mthumb -mcpu=cortex-m33 -mfpu=fpv5-sp-d16 -mfloat-abi=hard

To avoid linking unused code/data, you can also use these more general options:
Code: [Select]
-ffunction-sections -fdata-sections

And finally, typical linker options are:
Code: [Select]
--specs=nosys.specs --specs=nano.specs -Wl,-T<linker script>,-Map=<map file>,-o<elf file> \
  -Wl,--gc-sections,--no-warn-rwx-segment,--print-memory-usage
 

Offline ocelot

  • Contributor
  • Posts: 12
  • Country: gb
Re: I want to start "playing" with ARM micros
« Reply #40 on: December 23, 2024, 08:50:59 pm »
ST's LL is pretty bare and if you only use its header files (it also has some higher-level, albeit not as high-level as the HAL, in its C files, but you absolutely don't need them), it's only a very thin layer above registers, and unless you have a very good reason for doing so (and enough experience for that), rolling your own, which is probably going to be pretty similar, may make little sense. Contrary to the HAL, it does very little else than encapsulate registers access.

One nasty thing with ST is that they have removed all makefile-based projects from their SDKs (they used to provide some), which makes finding out the right compiler options and defines much more annoying than it used to, and is further pushing people to use those stoopid point-and-click IDEs instead of using their own makefiles (or cmake stufff).

For those interested, here are CPU/arch GCC options for a few of the STM32 series I've worked with:

Code: [Select]
# STM32 L4 & F4:
-mthumb -mthumb-interwork -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=hard

# STM32 G0:
-mthumb -mcpu=cortex-m0plus -mfloat-abi=soft

# STM32 U5:
-mthumb -mcpu=cortex-m33 -mfpu=fpv5-sp-d16 -mfloat-abi=hard

To avoid linking unused code/data, you can also use these more general options:
Code: [Select]
-ffunction-sections -fdata-sections

And finally, typical linker options are:
Code: [Select]
--specs=nosys.specs --specs=nano.specs -Wl,-T<linker script>,-Map=<map file>,-o<elf file> \
  -Wl,--gc-sections,--no-warn-rwx-segment,--print-memory-usage

And with the later GCC versions
Code: [Select]
-flto for Link Time Optimization - the compiler additionally effectively saves the program source after initial parsing in an ELF section, and then when you link the code again with -flto, it actually does the call optimization. 
So you find that functions get inlined, or partially or completely deleted from call hierarchy, because global optimisation can take place. Difficult to debug/trace but can reduce code size by an extra few percent.. 

This is further optimisation than just using/not using functions and code- by using the
Code: [Select]
-ffunction-sections -fdata-sections. That leverages the linker's rule that if nothing from a named section of the ELF file is used, it is not included in the final binary.  So by putting every function and data block in a different section, it can eliminate the unused sections.


If  libraries are also compiled with LTO, even the library code gets optimized into your code.

The price you pay is much larger ELF ".a" files before linking, but you gain final linked program space.

If on the other hand you link one of the ".a" ELF files containing the LTO data,  without the Link Time Optimization option in future, it just uses the original machine code also stored in the usual place in that same ELF file, so that can be debugged fairly sensibly - it will preserve all the function names and call hierarchy.

 
« Last Edit: December 23, 2024, 09:00:15 pm by ocelot »
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 6436
  • Country: es
Re: I want to start "playing" with ARM micros
« Reply #41 on: December 23, 2024, 10:04:44 pm »
-flto can cause weird issues, so use with care.
« Last Edit: December 24, 2024, 11:01:34 am by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15942
  • Country: fr
Re: I want to start "playing" with ARM micros
« Reply #42 on: December 23, 2024, 11:53:44 pm »
-flto can cause weird issues, so use witt care.

I wouldn't recommend it either, especially for embedded stuff.
 

Offline peter-h

  • Super Contributor
  • ***
  • Posts: 4435
  • Country: gb
  • Doing electronics since the 1960s...
Re: I want to start "playing" with ARM micros
« Reply #43 on: December 24, 2024, 01:11:57 pm »
I come from a similar background to the OP, even down to doing Xilinx FPGA work. I am of a similar age but not retired :)

Now working on STM32 (32F417/437). Cube IDE. A bit of a learning curve but it's OK. The Cube MX "code generator" gets you started with trivial projects and after that it is, as always, real work :) MX generates the "HAL" code fragments and they are handy for seeing how stuff works at low level but is best avoided for any real functionality.

But this stuff is pretty complex (especially when you get into LWIP, FATFS, MBEDTLS, FREERTOS, ETH, USB, etc) and I hope this hardware platform will do me for the rest of my life expectancy :)

ST do not support their chips unless you are a huge user. So you are on your own. I've learnt a lot by posting Qs here.

There is also the ST forum but is it full of "my LED does not blink - HELP" posts and almost nobody on there helps you. Just sometimes they do...
« Last Edit: December 24, 2024, 01:16:37 pm by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3303
  • Country: ca
Re: I want to start "playing" with ARM micros
« Reply #44 on: December 24, 2024, 03:12:27 pm »
This is also why I think the moment you go from PIC to ARM is exactly the right point of getting rid of the manufacturer tools. They maybe covered 99% of PIC use. Same isn't true for ARM anymore.

Microchip tools are similar to STM. They have MCC which does the same as Cube. Much more similarities than distinctions.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 9466
  • Country: fi
Re: I want to start "playing" with ARM micros
« Reply #45 on: December 24, 2024, 04:29:23 pm »
This is also why I think the moment you go from PIC to ARM is exactly the right point of getting rid of the manufacturer tools. They maybe covered 99% of PIC use. Same isn't true for ARM anymore.

Microchip tools are similar to STM. They have MCC which does the same as Cube. Much more similarities than distinctions.

I was specifically commenting on 8-bit PICs. It is different from ARM development in two important ways:
* Project complexity is limited by limited hardware anyway;
* There is unavoidable vendor lock-in anyway because C compiler choice is limited due to the esoteric ISA

With ARM, there are similarities (CPU core, SWD, ...) between even different manufacturers - something you didn't have e.g. between PIC18F and ATMega. These similarities give a new opportunity of tool sharing. For example, I use same compilers, same flashing tools, same debugger, same code editors, same startup files and very similar linker files for STM32 and nRF52. Therefore, I avoid vendor lock-in in two senses: locking into manufacturer, and locking into their specific workflow (which changes every few years).

As a result, if and when one transitions from simple 8-bit microcontrollers into more complex ARM projects, in my opinion it is a excellent opportunity to get rid of vendor lock-in, vendor specific software, and code generation, and start adopting software development practices like version control and expressing programming intent as code (instead of graphical code generation suites). I'm very happy that I did.
« Last Edit: December 24, 2024, 04:31:42 pm by Siwastaja »
 
The following users thanked this post: Dazed_N_Confused

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3303
  • Country: ca
Re: I want to start "playing" with ARM micros
« Reply #46 on: December 24, 2024, 05:29:38 pm »
With ARM, there are similarities (CPU core, SWD, ...) between even different manufacturers - something you didn't have e.g. between PIC18F and ATMega. These similarities give a new opportunity of tool sharing. For example, I use same compilers, same flashing tools, same debugger, same code editors, same startup files and very similar linker files for STM32 and nRF52. Therefore, I avoid vendor lock-in in two senses: locking into manufacturer, and locking into their specific workflow (which changes every few years).

I use a text editor with various compilers to write code for PC, Mac, Linux, various MCUs. There are many different compilers, which get invoked depending on the target. This doesn't bother me a bit. If necessary, I can add new compilers, which may take may be an hour to set up. The only IDE I still use is Vivado, mostly because of its graphical FPGA editor.
 

Offline fchk

  • Frequent Contributor
  • **
  • Posts: 284
  • Country: de
Re: I want to start "playing" with ARM micros
« Reply #47 on: December 25, 2024, 11:35:02 pm »

I am looking for something more powerful than an 8-bitter. Thus, ARM. However, I know that RISC-V is starting, too.

There is also PIC32. If you know 8-bit PICs you will feel at home very quickly. And some of them even come in DIL packages, e.g. PIC32MX270F256B-50I/SP
https://www.microchip.com/en-us/product/pic32mx270f256b
Very easy to use on a perfboard, much less complicated then STM32 from a software side of view..

PIC32M* uses MIPS, PIC32C* uses ARM. MIPS and ARM are like Coke and Pepsi. MPLABX will take care of the differences, if you want.

And: using MPLABX doesn't prevent you from using command line, make, svn/git etc.
 
The following users thanked this post: tooki

Offline hans

  • Super Contributor
  • ***
  • Posts: 1714
  • Country: 00
Re: I want to start "playing" with ARM micros
« Reply #48 on: December 25, 2024, 11:58:58 pm »
I still think the Raspberry Pico is a most fun place to start (especially the v2, perhaps with Wireless, which will be released soon).., especially if you don't have a particular goal in mind yet.

It can be programmed with PlatformIO or Arduino. Has onboard bootloader for just uploading programs, or SWD pins for debugging.
PlatformIO and Arduino has a large catalog of libraries for sensors, displays, motors. The wireless version has WiFi/BT as well.

The hardware is still quite simple and easy to use. The HAL isn't overly complicated. Registers are still friendly to DIY. I'm aware STM32 (or other ARM parts) often have more advanced peripherals and features, but at some points its hobby..
The PIO's invite experimentation too and can also bridge some digital gaps..

This is basically the largest span from ease of use (uploading the first blinky program shouldn't take more than 10 minutes including IDE installation&setup) all the way up towards advanced usage.
« Last Edit: December 26, 2024, 12:00:32 am by hans »
 
The following users thanked this post: cfbsoftware, davep238, WillTurner

Offline MathWizard

  • Super Contributor
  • ***
  • Posts: 1795
  • Country: ca
Re: I want to start "playing" with ARM micros
« Reply #49 on: January 02, 2025, 05:39:27 am »
So far as a noob to ARM/STM32, I bought a few STM32 Blue Pill clones, and used the ArduinoIDE, to program some basic things onto it. The most frustrating part was getting the USB to connect properly, or getting all the drivers/settings for that.

I've gone the STM32 way and haven't looked back!

I started compiling under Linux when you had to build your own compiler, these days ST offers the whole suite of IDEs and board configurators in one place, which makes it very easy. Some people complain about the configurator and the libraries, I use a mix and match approach. Configure the chip in the configurator and then add or change peripherals manually (especially interrupts!). To each their own I guess.

I started with an STM32F103 and built a small guitar effects processor out of it, it worked ok for 72MHz. Last I built was an audio spectrum analyzer using an STM32H7 that sends live audio data to a PC over Ethernet. I guess it depends on what your application is. Best way to start with a microcontroller is a blinky, and then think of something that would be fun for you. You may have to build a bit of hardware around, but that's part of the fun.

Cheers,

Alberto
Hi did you make threads for some of those projects ? Now that I know some op-amp circuits, and some assembly and C programming, I have a few audio projects in mind. Maybe a thing or 2 for guitars, but also I have soundcards and mobo "soundcard IC's", and various digital audio IC's I've salvaged. Hopefully some of them can be erased and programmed, if I can find the full datasheets for them.

I also have an old mid-1990's guitar effects processor that's getting a bit twitchy, and I'd love to try to watch what a few chips do, and reproduce it if possible w/ AVR or STM32 chips, and mod on my own versions, w/ new parts.

I'm just about finished upgrading my Keithley 5.5d DMM to 7-seg LED's, and I'll try and make a continuity tester with it too. Today I'm modding my stereo w/ a ATtiny44A, in the hopes of fixing a digital problem it's having.

I have a few things I'd like to add some MCU's to.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf