How to flash an LED: writing ARM assembly for an STM32 microcontroller • Hacker News Board

Re: How to flash an LED: writing ARM assembly for an STM32 microcontroller

#61

Post by lochsh » Sat, Apr 04, 2020, 2:02 PM UTC

digitaltom wrote: post #60

lochsh wrote: post #56

Earlier quoted context omitted.

Thank you for the compliment ^_^ I'm glad you found the post helpful. This isn't a typo, actually. If you look at the documentation of the BSRR register (which is screenshotted in the blog post), it says of BRy: > These bits are write-only [...] [Setting to 1] Resets the corresponding ODRx bit So setting BR8 in the BSRR clears the ORD8 bit in the output data register. Because our LED is active low, this turns the LED…

Ahh I see now, thank you for teaching me. My mistake! Do you happen to know of any great learning resources, basically more posts like you've written that go into lots of details and explain why things are done? Thanks again!

I'm not sure I do have suggestions for such resources sadly :( If anyone has any please drop them here!

Re: How to flash an LED: writing ARM assembly for an STM32 microcontroller

#62

Post by dmitrygr » Sat, Apr 04, 2020, 7:54 PM UTC

_noise_ wrote: post #54

dmitrygr wrote: post #3

Earlier quoted context omitted.

no, i spent months on this, and the answer is no They use IP from synopsis, but synopsis refuses to allow their docs to be published so every manufacturer has to read them and regurgitate them into their own docs in their own words . In any case official STM docs are incomplete. See their driver source - it accesses undocumented registers and sets undocumented bits in documented regs. Without them the usb core will n…

I don't know what issues you are having with STM32 I2C, but I have done dozens of STM32 designs and have never had an issue and needed to bitbang it.

Send an address only packet (smbus uses these) Just try. Now do it to an address that doesn't ack. Enjoy your wedged i2c state machine.

Re: How to flash an LED: writing ARM assembly for an STM32 microcontroller

#63

Post by jbott » Sat, Apr 04, 2020, 8:12 PM UTC

thebruce87m wrote: post #59

unbalancedevh wrote: post #58

I have years of experience in asm programming with PIC processors, and my job is embedded software development. I got an STM32 development board a couple years ago to get my feet wet in ARM embedded development. I got completely bogged-down in setting up the development environment. It took me forever to get a blinking LED, and I spent an ungodly amount of time unsuccessfully trying to figure out how to change the ra…

Do you mean in assembly? If you just mean C, then if you’re already in embedded then I’d say a few years ago it was easy. These days it’s super easy - tools like STM32CubeMX will allow you to get even custom hardware up and running in no time. It will even spit out multiple project types - everything from ARM Keil/MDK/uVision to just a simple makefile.

I disagree that GUI tools like STM32CubeMX are useful. They end up being a crutch that end up adding increasingly complex wizard driven autogeneration, rather than just exposing the configuration in easy to consume ways. Sure, you can get something running fast, but it’s incredibly difficult to move from “blink a led via this template project” to “build a useful project integrating multiple peripherals”.

I think there’s some actually interesting work being done with standardization like SVD files, but too many vendors treat them like second class citizens compared to their bulky code gen solutions.

Re: How to flash an LED: writing ARM assembly for an STM32 microcontroller

#64

Post by thebruce87m » Sat, Apr 04, 2020, 9:51 PM UTC

jbott wrote: post #63

thebruce87m wrote: post #59

Earlier quoted context omitted.

Do you mean in assembly? If you just mean C, then if you’re already in embedded then I’d say a few years ago it was easy. These days it’s super easy - tools like STM32CubeMX will allow you to get even custom hardware up and running in no time. It will even spit out multiple project types - everything from ARM Keil/MDK/uVision to just a simple makefile.

I disagree that GUI tools like STM32CubeMX are useful. They end up being a crutch that end up adding increasingly complex wizard driven autogeneration, rather than just exposing the configuration in easy to consume ways. Sure, you can get something running fast, but it’s incredibly difficult to move from “blink a led via this template project” to “build a useful project integrating multiple peripherals”. I think ther…

I think it’s decent - configuring a clock tree and initialising the peripherals by hand might be a good way to learn the chip but in terms of rapid prototyping I’ll take the GUI driven leg up any day.

Re: How to flash an LED: writing ARM assembly for an STM32 microcontroller

#65

Post by thebruce87m » Sat, Apr 04, 2020, 10:26 PM UTC

dmitrygr wrote: post #62

_noise_ wrote: post #54

Earlier quoted context omitted.

I don't know what issues you are having with STM32 I2C, but I have done dozens of STM32 designs and have never had an issue and needed to bitbang it.

Send an address only packet (smbus uses these) Just try. Now do it to an address that doesn't ack. Enjoy your wedged i2c state machine.

I’ve recently used the “HAL_I2C_IsDeviceReady” function to scan the whole address range to find devices on the bus with no issues. I’m not near my PC to double check but I’m pretty sure that does what you’re talking about and seems to work ok for me - unless you’re suggesting it’s intermittent?

Re: How to flash an LED: writing ARM assembly for an STM32 microcontroller

#66

Post by lochsh » Sun, Apr 05, 2020, 1:59 AM UTC

dmitrygr wrote: post #62

_noise_ wrote: post #54

Earlier quoted context omitted.

I don't know what issues you are having with STM32 I2C, but I have done dozens of STM32 designs and have never had an issue and needed to bitbang it.

Send an address only packet (smbus uses these) Just try. Now do it to an address that doesn't ack. Enjoy your wedged i2c state machine.

I think it's worth noting that there are multiple I2C peripherals by ST -- one for STM32F1, F4, and L1; and a different one used for STM32F0, F3, F7, L0, and L4.

Re: How to flash an LED: writing ARM assembly for an STM32 microcontroller

#67

Post by rabryan » Sun, Apr 05, 2020, 2:06 PM UTC

__init wrote: post #45

rabryan wrote: post #39

Earlier quoted context omitted.

Avoid ST at all costs in my experience. Their documentation is terrible. They never acknowledge hardware errata even after clear evidence of it. They’re not a company with a solid engineering culture imo

I'm really surprised to hear that. ST has always been one of my favorite manufacturers. I find their datasheets to be clear and well laid out, though I will note that I'm usually more interested in the hardware side than the software side. Their chips and boards are also high quality and convenient, e.g. GPIOs are often five-volt tolerant, Nucleo boards come with well-made breakout headers and several peripherals (at…

I’ve used their accelerometer (LIS2D). Performance and specs are great - it was just a pain to develop the embedded interface with it because the documentation had a bunch of mistatements and was missing critical information (a weak pullup on a certain line caused a bunch of current consumption - took days to figure out). Also they had an off by one bug in their LIFO queue that took a long time to figure out. Once you getting it working its great. Last time I checked they still hadnt updated their documentation with what I reported to them...

Re: How to flash an LED: writing ARM assembly for an STM32 microcontroller

#68

Post by rabryan » Sun, Apr 05, 2020, 2:08 PM UTC

userbinator wrote: post #47

rabryan wrote: post #43

Earlier quoted context omitted.

Atmel (now under Microchip). They have great documentation and software libraries. And they actually acknowledge hardware errata in the documentation.

And they actually acknowledge hardware errata in the documentation. More so for Microchip than Atmel --- it's pretty common to find on some of their newer and more complex parts a ton of errata, among which there are some extremely "WTF!?" ones like "feature X does not work at all".

Yeah I love those. They highlight features xyz on first page of datasheet. Then on the last few pages its like btw features xyz dont work on rev A-F. And your supplier doesnt know what revs they have...