Embedded thread

>not updated since 2015

uhh wat
last commit was yesterday

Arduino baby reporting in. Was messing with shift registers before taking a bit of a break.

How did you guys get started? Are you all electrical engineers or what?

Attached: 20190503_005236.jpg (4032x3024, 3.26M)

I'm an IT goon but my dad is an EE and he got me into electronics when I was young

>It might not be very beginner friendly, but this is the most straightforward way to do it
And also the most retarded. Putting register addresses directly in the code as magic numbers is a recipe for unreadable and non-portable code, and if you are #defining them, you're just rewriting CMSIS for no good reason.

The virgin Arduino.

The chad Zilog Z80.

There's a thread like this in /diy/

To answer the question, the Arduino framework because I'm really lazy to bother with STM's HAL

Does anyone here know about FreeRTOS? Why can tasks have infinite loops in them but they don't block the entire program?

Attached: rtos madness.png (741x632, 33K)

Because a software interrupt is called which lets the RTOS know it's time to jump to another task
The software interrupt may be generated every 1000 machine cycles, or every 1 msecond or whatever

Basically all AVRs (atmel)

I'm looking at STM32 though

>71156511
ooof

This one is getting too smart for us rabbi

Attached: Vermessung.png (715x626, 504K)

What is the interrupt tries to run while a function inside the task hasn't returned yet?

My own Forth for STM32 F0 and F4.
Peripheral configuration are generated from SVD files and a little custom dsl config format.

All embedded processors have a datasheet and a header file. you never type register addresses.
if you want to change the value of the register 0xDEAFFEEF which is responsible for the GPIO pin 23 you will find in the provided header file the following
> #define GPIO_REG_23 0xDEAFFEEF
and that's how the cookie crumbles in embedded programming.
Code for microcontrollers is easily readable, even if it has raw addresses, because the people who read it and tweak it are familiar with the micro-controller and all of its internal structure.
I worked 1.5 years on xilinx's ip cores and then had to take a look upon the linux code that microblaze used to talk to the spi devices using the qspi IP core. you cannot imagine how fucked up looked to my colleagues due to all the weird operations, but to me it was as if I wrote it, since I knew even the slightest detail about it.
It takes a lot of time become familiar with the device and then the code, any code, written for that device is very easy to read and understand.

CS grad here, doing my M.Sc. in EE now.
I've worked for years with FPGAs, PCI-e, linux drivers, bare metal programming.

I am currently making a smartwatch with esp8266, I2C OLED 0.96" display.
that's the cheapest embedded project you can start.

CMSIS with LL subset of HAL

erm, chad and masterrace was already taken, so it was either that or just bare metal C.

Attached: 1524352272829.jpg (321x362, 35K)

because they are scheduled, that's the OS part of RTOS. are you stupid or something?
also for(;;) is a traditional way to do infinite loops in unix style

do you even know how interrupts work?

i intend to write a rudimentary (rt)os for my arduino mega (atmega2560) that has only been collecting dust for the past 5 years or so for my non-existing embedded portfolio
currently implementing drivers for the peripherals that it has
after that i'll be doing some online scheduling, probably rate monotonic, semaphores, priority inheritance, and whatever else i can think of
but for now im still getting a hang of the peripherals it has
this is basically what i do for a living otherwise, except i work with some powerpc ecu:s, its usually pretty comfy except when big bosses want to push software to customers, then it can get stressful
scheduling, interrupts, etc.
i used freertos in uni a couple of years ago, never really liked it all that much but it seems ok
read about context switching

Attached: 1558893239256.jpg (714x1000, 101K)

you'd probably either do
#define GPIO_REG_23 (*(volatile uint32_t*) 0xDEAFFEEFu)

or
typedef union
{
uint32_t R;
struct
{
uint32_t register_location_0:4;
uint32_t:27; /* reserved */
uint32_t register_location_1:1;
} B;
} GPIO_t;

typedef struct
{
GPIO_t GPIO_0;
/* .... */
GPIO_t GPIO_23;
} GPIO_s;

#define GPIO_REG (*(volatile struct GPIO_t *) 0xDEAFFEEFu)

volatile struct GPIO_s * const GPIO = &GPIO_REG;

but yeah, the header file you get for each cpu probably has everything except the "volatile struct GPIO_s * const GPIO = &GPIO_REG;" already defined

>bitfields
never fucking do that

Attached: vwdv9QZ.jpg (418x379, 26K)

i've encountered cases where accessing single bits in bitfields is faster than masking the entire register

By meaningful do you mean hobby projects or something you can sell?

Hobby projects are easy just start with a small idea

Not the user you responded to. Certain micro-controllers actually have the hardware capability of accessing and modifying individual bits. You could hold for example 8 Boolean bits in a single uint8 variable and use them individually. It's very comfy if you need to decode incoming messages and make decisions base on individual bits in given sequence.

>All embedded processors have a header file.

Yes, that's what CMSIS is, a set of headers and macros for register operations.
I was surprised by OP putting "bare metal C" as a separate point.

>What do you guys use?
sepples in cortex m4 BT SoC's and proprietary blobs
>What I wish I could use?
[no-std] Rust with a RTFM scheduler

Because FreeRTOS has a preemptive scheduler, easy.

Vendor libraries always have subtle bugs and race conditions that will fuck you up - I tend to use them as a reference and write my own.
HAL and bare metal is not mutually exclusive. Obviously you need to structure your project with a HAL.
I never use RTOSs as they are pure bloat and usually completely pointless. 99% of things can be structured as an event loop which will be much more efficient. For very rare cases where your task is so complicated that you struggle to express it as a state machine, then you can use longjmp/setjmp to cooperatively multitask.

Bitfields are fine if used internally, and not serialized and sent onto a wire. What else do you suggest, to make your series of boolean flags consume 8 or 32 times more memory?? One system I'm working on is tracking ~25 boolean properties per item on 200 items. That's a choice between 5K of memory or 160K of memory.

and plenthora of cases when it's way worse

C standard is very vague about how bitfields should be implemented in memory and majority of its behavior is implementation-defined. E.g. standard only allows int and _Bool to be underlying type and doesn't say anything about order of layout.
And embedded dev is the field where you might be forced to use uncommon C compiler.
And you loose the the bitwise operations over masks. It's just not good for memory-mapped registers.

>What else do you suggest
in C, masking
in saner designed language, arbitrarily wide integers

I avoid bitfields on memory mapped acesses because you never know when the compiler goes full retard and emits a byte or half word access on a register that is specified to require only full word accesses.

>Arduino
>Chad

Attached: 1554299462247.png (800x800, 708K)

>Descartes
>opinion
trash material

>And embedded dev is the field where you might be forced to use uncommon C compiler.
this is unlikely to happen. usually you end up using a qualified compiler such as greenhills thats well defined
also you should do unions with full register access and bitfields, this way you dont really sacrifice one for the other

Use libopencm3, it supports a big range of STM32 devices.

you never know what kind of bullshit is keil though is a good idea
and despite being well (implementation-)defined, it can still differ between implementations

I just want to make them as a hobby. is there a book or guide you could recommend me?

one week

>How did you guys get started?
I like computers and knowing how things work.
It all snowballed from there.

Do you sell your memedouino inventions Jow Forums?

How much profit do you make on each one?

overpriced shit

Attached: ESP8266-OLED-preflashed-development-board-Screen-0-96-inch-OLED-version-ESP8266-18650-0-96-inch.jpg (1000x1000, 121K)

I use this stuff for testing "serious business" hardware and making small add-ons like debug displays, so memeduinos and STMs make up some vague part of my paycheck.

That thing is pretty useless in practice. It has a bit of computing power and memory, a bit of network connectivity, a bit of I/O and a crappy display, making it a jack of all trades but master of absolutely none.

Assembly or Baremetal C

Been doing a lot of work with 16 bit DSPs. I'm currently working on a raw audio recorder and player using a dedicated ADC and DAC.

Also starting research on a dual core DSP that recently came out.