Microcontroller thread

Microcontroller thread
>working with stm32
>use bare metal C/assembly, fee like I am wasting time
>using stdperiphlib, everything takes time to set up and I feel like I am still wasting time
>use STM32CubeMX (HAL), everything is done for me, feel like I don't know shit
Is there even a solution to this?

Attached: 3233974581.jpg (1000x1000, 227K)

lamo i just use 328Ps or 2560s with arduino because it's more fun to develop something new.

I used to work with 8 bit micros exclusively, AVRs, PICs, 8051/8052. I had to move on to STM32 because of how powerful and cheap they are, also STM32CubeMX makes setting up stuff really fucking easy. Even more than I would like.

>Is there even a solution to this?
To what? Your broken brain that considers learning a waste of time? Yeah, maybe shock therapy or something.

If it were up to me, I would do everything in bare metal C by only defining whatever registers I needed.

Expect things to get more abstracted and bloated as microcontroller prices plummet.

Learn how to do something bare and then say fuck it and do it with HAL cause efficiency is key

what made you need to trade up from 8-bit to 32-bit?

Attached: 1563686152306.jpg (436x436, 26K)

Mostly USB and absence of FPU, since it just feels unnatural to do USB in 8 bit micros. Unless they have hardware for driving USB you have to use clunky and hard to use shit like V-USB. Hell even with USB hardware, its not ideal, the bus is too narrow for anything intensive like bulk transfers
I work with motor controllers and we have a lot of floating point calculations, which are just too hard to do in 8 bit micros. Even with heavily optimized assembly routines to do floating point calculations, its still slow, taking tens of CPU cycles.

>USB on a 8-bit
i can get that. i usually take the lazy route and cram a w5500 into the circuit and use static IPs and a half-baked validation scheme since i mostly do access control. don't do much with floating-point calculations, but that has to be rough on 8-bit without dedicated hardware.

You're up for a fun ride.

Attached: ph.jpg (1280x960, 217K)

dope. i got one of those 7-pin, 12-button keypads working with the ADC to use only one wire, but pulling a DPDT relay up fucks things up when reading button presses. any tips?

I messed around with an arduino today. I’m making several led’s blink in succession, did it with C which was trivial.
I have a pic18f452 coming in the mail. I’m going to just stick it on a breadboard and then learn how to flash it (how do I do that by the way?)

The most common way to solve this is to incorporate a delay between measurements to exclude noise. For example, if you're having an interrupt for button press, don't react into it right now, instead setup a timer. Once timer hits, check if the pin is still up, if it is, do the job.

This problem has been solved million times already, you better off grabbing some library that would do that for you.

I-is that what I think it is?

Attached: ph~01.jpg (120x96, 7K)

>don't react to it right now
Practically, this is fine for my application. I'm building a 2-factor authentication door lock with a network stack that can remotely lock it down. Adding the mag-stripe reader is trivial.
I've implemented a passive timing mechanism to avoid locking things up with delay(), so I figured there was a way to add or subtract a value during the pull-up to account for its noise.

You can make things simple by migrating into FreeRTOS and implementing delays inside of "threads".
No, it's chinese STM32F103RCT6 devboard

>No, it's chinese STM32F103RCT6 devboard
Ah I see, it looked similar to the SiFive board.

>You can make things simple by migrating into FreeRTOS and implementing delays inside of "threads".
Agreed, ARM micros are made to be worked with an RTOS. That's the best way to use them

sounds like more effort than abusing the fuck out of millis() and setting consts for timing checkpoints.

If you want to do it the best way possible, use timers and interrupts. I agree RTOS does make things a bit more complicated and heavy

that does remind me when i made my wunderground stations: doesn't millis() have a problem with carryover? i think i tied the reset pin to an output to trigger when it got too high to avoid that fear, but i dunno if that was just QoS paranoia or if it was couched in a legit fear of breaking something.

testies
1...2...3?!

HAL is so bloated. Has anyone used LL?

LL is pretty good, but if you're just going to use LL, there's no point in using STM32CubeMX at all, just download stdperiphlib and get it done with, its almost at the same level as LL, maybe even lower level