What do I need to know and be able to do to make it as an embeddedfag?

this
i never got how these work
does your penis just refuse to grow or what

Computerz

>C++
He's not gonna make it

>tfw started working with AVRs in C
>Actually more fun bittwiddling then using libs
>Write nice clean C
>Designing my own shit in KiCad
>Order of parts came in from DigiKey the other day
>First PCB is shipped
>tfw dropped out of CE because I fell in love
>never gonna make it in tech
>Fuck it, lets make weird shit.

Attached: 44685250_316388612287075_8424114000714792960_n.png (500x417, 166K)

Backside

Attached: 44758949_969978713188225_3914690758468173824_n.png (500x417, 97K)

as powerful CPU's get cheaper and smaller, it's a pointless skill to learn

Yeah, no. Let me just embedded a full OS into this package that's not going to be updated for years at a time. Worked pretty well for first gen IoT applications.

This.

Nowadays you can embed a barebones linux in a potato. As the technology advances you can expect the embedded field becoming smaller and smaller.
The only current benefit is the cost saving of a fully customized platform, but it will soon overtaken as people realize that is cheaper to buy premade modules that has been already validated. i.e. raspi 0 vs own pcb

Yeah but where space and accountability is important, having a full blown OS is too large of a surface to manage. Look at that board I posted, why the fuck would I need to be able to SSH into that? How do you audit multiple OS packaged solutions and their interactions? The complexity makes it brittle. But for smaller applications, this model will easily take what was traditionally CE domain and move it out.

Let's use that board above, very little would change if we slammed a PiZero in there, most of that is for power, programming and display.

Don't bother, it's the worst area of tech to get into

Are you kidding? Actual engineering that is safe from pajeets and zoomers?

Learn C, C++and read all you can on machine language

>peepee in a cage
>peepee gets hard
>peepee hurts
>peepee gest soft

I agree the pure embedded work will never dissapear, but it will become very small and, with standarization, probably done by electrical engineers.

here is your (you)

>select "usb cadget" stuff when compiling linux kernel
>???
>your system is now a USB device

Once you understand Arduino, move to STM32 and start real embedded.

massive pads for those tiny traces

Is there any small board that runs win10? What is happening with win for arm?

Bough orange pi zero, it's great but I haven't used linux for a decade and would like something similar but running windows.

Another question. Can those chink intel sticks with hdmi connector run headless?

Attached: intel-compute-stick.jpg (500x430, 22K)

Pretty damn sure they can.

Yeah, I'm handsoldering everything so I figured the TQFP would be hard enough.

wtf? what are the trace widths? 5mil?
You better hope osh can handle that or else you'll receive a blank board.

6mil, followed their design rules on their site. It's just a tiny bloody board 6cmx5cm. Been dealing with SMD components for the last bit, figured I might as well go balls to the wall.

I'm worried about the power supply more then anything. Ran it by the guys at the space and they gave it the all clear, but I don't want to have to bodge in a external power supply because I fucked up. Should handle 9v via that barrel

1. Basic physics of electricity (e.g. so you don't connect a LED straight to a 5V supply)
2. Basics of MCU architecture (bit width, integer/FP math, Harvard/von Neumann, registers, what is interrupt, DMA, timer)
3. Most common MCU interfaces (GPIO, UART, SPI, I2C)
4. C (you can live without C++ and assembly - although it's useful to at least be able to *read* them)
5. Specifics of a particular MCU line-up because oh boy there's a lot of specifics

Now this all applies for "low level" embedded programming on MCUs like ATmega, PIC, Cortex-M.
Once you get to Cortex-A and embedded x86, you're dealing with Linux, BSD or WinCE, hardware is heavily abstracted, and a completely different skill set is required for building OS images, configuring kernel and drivers, managing threads etc., and you'll probably be using something other than bare C.

Arduino is a decent start because it only has a handful of features and the API does a good job of hiding frustrating hardware stuff, but also doesn't prevent you from digging deeper and bypassing the API if you want to do something with the hardware directly. But don't stop at Arduino like too many people do; the step from Arduino to "real" MCU programming may be somewhat steep but you get A LOT more options opened up, both interface-wise and performance-wise.

t.embeddedfag

The "cheap powerful CPU" part is true but only in the "Cortex-M will eventually replace most 8-bit stuff" sense.
There are several problems with pre-made Linux modules for embedded tasks, aside from the general "using eagle to catch flies" issue.
a) They aren't cheap and they aren't tiny compared to single chip MCUs. You need a pin socket on the main board to accommodate them, so the whole assembly can't be less than a couple centimeters thick.
b) They have a limited choice of industry-specific hardware, like precision timers, multiple ADCs/DACs, serial interfaces like CAN etc.
c) They have a lot of programming overhead if there's no off-the shelf code for the stuff you want. The effort required just to develop drivers/APIs to use your custom hardware from a full-blown OS can be higher than for doing the entire task on some STM32.
d) They suck ass for timing-critical applications because Linux is not a RTOS and you can't use hardware interrupts from userland. Even the start-up time can rule out Linux for many tasks (e.g. stock Raspbian on a Pi needs like 20 seconds to boot from cold state - you can trim it down, but see point b)
e) They suck ass for anything that requires reliability (e.g. safety-related automation) because you can't realistically audit the immense amount of code involved, and modules
f) They suck ass for anything that requires longevity because you can't rely on them making the same module for 10-15 years.

What kind of projects would you suggest someone tries tackling to get some experience? I'm and looking for something else to work on after my current project :)

i usually do fat vcc traces if i cant have a +v and GND planes

One of the guys pointed that out after I had sent the gerbers off :/ I ran it through a calc and I should be good up to 600 mA draw. If I end up with some coasters, I'll chock it up to the cost of learning a lesson. What I'm really interested in is how that tiny voltage regulator deals with a 4v drop with such a tiny heatsink.

What voltage reg is it my dude?

post schematic
also, vias and copper planes are basically free on 2 layer boards. Stick to 10 mil traces minimum unless you are working on a super tiny board. Looks cool though, will you be hand soldering it? What size are the resistors, 0805?

It's this little guy over here. Thankfully it has thermal protection if shit gets too spicy!

digikey.ca/product-detail/en/diodes-incorporated/AZ1117IH-5.0TRG1/AZ1117IH-5.0TRG1DICT-ND/5699683

Pic related, Wish I set that up before hand. But live and learn! Next board I'm going to pay serious attention to power. Going to be hand soldering the whole thing, done some SMD kits and don't mind it at all (except for that time I inhaled a resistor lol). LEDs are 0805, if I could be arsed to reroute it all I could have gotten the grid way more dense.

Attached: asdf.png (1517x1039, 329K)

I don't know, all of the stuff I do "for fun" is still work-related. I started as an PC GUI programmer back when Delphi still was a thing, and then the company got more PC guys and less embedded guys so I sort of slowly switched over time. I still don't do hardware at all though.

Have some traces, because holy shit does this look metal af. Why didn't anyone tell me CAD was cool?

Attached: Untitled.png (1008x824, 130K)

I would rather put a 100nF decoupling cap on supply rail than GND

So how many of these don't have some manner of hardware backdoor on them?

Be able to read and comprehend datasheets.
Know a decent bit of assembly for popular architectures, e.g. ARMv7 and PIC32
Understand how to write your own heap algorithms (if you need one), typically focusing on anti-fragmentation as opposed to speed
Know C.
Know the details of working with endianness in C.

Anyone can build a bridge that stands, but only an engineer can build a bridge that barely stands.

You could clear up a lot of congested routes by using copper fill planes and vias. Then you wouldn't have to worry as much about current draw as each individual part would be able to source itself through the plane. You may want to supply the plane with a beefy trace though. It also sort of acts like a cap (keep in mind for rf stuff)

Have any resources for learning the dos and don't of pours? Anything that clears those routes up would be awesome. Avoided them this time because I didn't want to fuck them up

Shouldn't they do the same thing or am I missing something like established conventions?

Here's something else I'm waiting on doing, buddy wanted some blinken for his drive bay. RS232 comms and Molex power. Need to jigger around the traces and mounts still. But bigass toggles, lights and segments :D

Attached: Untitled.png (3868x2524, 607K)

eLinux has so many problems it's hard to know where to even start.
Firstly, good luck getting linux running on anything slower than a Cortex-M3, and even that's going to be questionable. It wouldn't even fit on on-board flash, meaning you have to piss away board space on external flash. Meanwhile, I can put FreeRTOS, Contiki, or even one of my home-brewed solutions on a Cortex-M0 without a problem.
Hardening the kernel for a specific platform can take months, meaning you either lose out on upstream improvements (including security updates, which is a big deal with anything that connects to a network), or you stagger development across different versions, but that makes turnaround times even longer.
There's so much shit in a Linux kernel that just isn't needed for most embedded platforms, e.g. users, permissions, terminal support. Fuck, often times you don't even need a filesystem, or at least not a sophisticated one. All of that stuff contributes to code size and inefficient performance.
eLinux is good for something like a mid-grade Cortex-A or embedded x86, where there's a sophisticated bootstrapping procedure and enough non-volatile memory to warrant a real filesystem, but it's woefully impractical on anything smaller than that.

I meant for the atmega

ATMEL

Linux runs just fine on 386SX@16mhz?

You literally cannot run the Linux kernel on Cortex-M or any other MMU-less microcontroller. (There's a MMU-less port, but it's outdated and barely compatible with anything, so it's pointless)

386SX had a MMU and typically came with 1-4 MB of RAM and ample nonvolatile storage.
Also no, current Linux kernel does NOT run on a 386SX.

Shout out to that time I had irssi running on that old ass port on a nintendo DS

so why doesn't Jow Forums have an EE general yet?

too many brainlets on this site
also doesn't /diy/ have one?

I'd honestly leave it to EEs. They're going to be much faster to learn CS necessary for embedded than the other way around.
It's not such a prospective field anyway, more like a shelter for EEs to stay employed. Not to mention that if you're worried about pajets taking over, then its way worse there than here.
stfu moron, you don't want Jow Forums to swarm over there

yeah, because why would you like to build your device under 50 cents when you could buy a 20$ units
you're thinking in terms of amateur hobby projects made in small batches

Is there any downside to making the traces as large as the board layout allows? On the little projects I've done myself I just used the largest width that didn't get in the way of routing things and called it a day, worked fine on my machines (tm).

Tell me that in 10 or 20 years.
Everything is getting more powerful and modular, and mass production will soon catch is price

Your nutbladder would break

Also, these few euros boards are tested and validated by thousands of people, and with the current sdk a fucking monkey could out something together, unless you are speaking of thousands of devices (or more in the near future) a premade hardware module make more sense

Except then you can't create a decent package for it. Why do you think laptops aren't modular? Form factor restrictions. There's a reason a PC case is a big box of space.

Hobbyists can put something modular together and end up with a decent bit of hardware, but that isn't production ready and horridly expensive. You can get AVRs from China for 30c a pop.

Point d was only true until recently. Fully preemptiable patched kernels exist, they just need to be manually compiled.

>Tell me that in 10 or 20 years.
well then, tell me NOW why are 8bit mcu's still a viable option (and will be in the future)
>unless you are speaking of thousands of devices
why wouldn't I? also, id doesn't have to be in thousands to make sense

>You can get AVRs from China for 30c a pop.
avr's are horribly expensive and clearly for hobbyists, you can get comparable mcu's at 10x (or even more) cheaper than this, at single cents per piece.
sure, I don't deny modularity, mass production, community support and all of that, but that simply isn't enough

* Get an EE degree.
* Do some programming.
* Get a relevant job.
* ????
* PROFIT!!

I just developed a device with my company that will ship in the tens of thousands.
We just put a nordic arm m4 because we dont give a shit about the peanuts we would save with a small procesor but we do care a lot about development time and future proofness if we add more functionality.
A rpZero was also mentioned and the initial brainstorming, but we werent so sure about legacy support, but we all agreed that development cost would be a fraction of the ones we had shall we had used it.

>sure, I don't deny modularity, mass production, community support and all of that, but that simply isn't enough

Yet

My point was that it’s dogshit cheap compared to hardware that can run Linux. What kind of mcus do you see in the wild?

god damn CHIP was such a fucking sham

How about masochists?

used to, 386 support was removed in 3.8

Yes but see point c. You can't just throw "config_preempt_rt=on" into the config file; your drivers and userland code must also be written with real-time in mind, which means a lot of existing stuff won't work well, and then what is the reason for using the Linux kernel when leaner ones are available?

I don't really see the point of starting any new projects with 8-bit MCUs nowadays, with the exception of ultra tiny/ultra low pin count applications (you can't have a Cortex-M in a 3x2mm 8-pin package yet).

i could explain it in several ways, but at the end of the day, it's a philosophical issue.
modern computers are dumb. i mean that sincerely.
everything you do with computers is so defiled by monopolies and legacy and government organizations that it's just disgusting.
a microcontroller is a (potentially) =60 cycles for no good fucking reason.
if you want to meme that i'm recommending you buy an arduino as a "computer", go ahead. but if you think it's reasonable that we need 4ghz hex-cores in shit laptops to view fancy images and formatted text i question you.
there was a time long ago when 1mhz and 64k of ram with a dogshit ISA was a whole lot..

cont.

>What do I need to know and be able to do to make it as an embeddedfag?
Yocto

Newfag here, by EE you mean Electronic Enginieer?

cont
no current software is an excuse for the needs of modern hardware.
so many people know that discrete pci gpus have huge latency, but nobody cares.
so many people know that x86 is horrid, but nobody cares.
hell, so many people realize the same thing with development environments. try to get a framebuffer to draw lines in in linux. no libraries other than x11.
it's not impossible, but it's not very fucking fun or efficient.
now try it in plan9. very well designed abstractions make it a fucking breeze.
i started writing games a few years ago, and the environment is fucking atrocious no matter where you go. an example being minecraft, a game that i could formalize top to bottom, drops frames from 200 on basically anything.

1. i don't really believe you, but i don't expect you to prove it, so moving on..
2. i unironically hope that another company takes your market because doing things the way you are doing them is lazy at best and dishonestly betraying your customers' interests at worse. this might seem like a jump, but it's not. if you think amazon's stupid fucking $5 to $20 wifi buttons with stickers and an stm32 (which is still a microcontroller) are Kool you are retarded and don't deserve technology.

The problem with 328p is that low-end STM32F0 variants cost the same, but have significantly more processing power and features (DMA, DAC, 24/32-bit timers, actual debugging interface, etc), and if you run out of I/O or memory, you can just swap it with slightly more expensive variant instead of wasting development time and PCB space on external chips.

An advantage of 328p is the Arduino API, which is much simpler than STM32Cube, but that's only good for very simple stuff.

oh i agree, but those aren't good reasons for actual products that don't need better performance (which are made in bulk by companies that can get the avrs for much, much less)
i would also argue that the stm32 environment is suitably more complex in exchange for all those features, which is of concern. st-link + open source programmers are alright but nowhere near as convenient as a parallel port or a real isp + avrdude, both of which are so simple you could homebrew your own with relative ease. as far as jtag, an alternative could be emulating an avr for debugging, since they're so fucking braindead simple, or proving your programs.. but i don't really consider that to be an alternative, in all honesty.
i honestly haven't used debugwire so i can't comment on how good it is, but it does exist.

>wasting development time and pcb space on external chip
i don't think either of these are significantly damaging to warrant much of anything. you're gonna need one if you need a LOT of memory anyways, and spi on an avr is easy.

it's not really a problem if you're white, you'll have plenty of room

There are volume discounts on ST chips too; and companies that need very simple stuff in very large quantities use one-time-programmable MCUs, not 328p's.

STM32 was frustrating to develop for just a few years ago, but now you can get TrueStudio or Keil for free, both being full-featured IDE with debug and CPU support headers included. It's still not as easy as Arduino, but it's vastly more flexible.

>i don't think either of these are significantly damaging
Yes they are. SPI RAM is an absolute ASS to deal with since it's not directly addressable, while I/O expanders increase latency, waste CPU cycles on extra I/O and can't be mapped to interrupts. And on the pricing side, a single expander or SRAM chip is half the cost of the MCU.

>stmmeme32
FUck that piece of bloated garbageware. holy shit. I am never touching that piece of shitware ever again.

pajeets follow the money, son

>bloated

Well I dunno, on my desk I now have a 320x240 LCD with multiple proportional fonts, bar graphs, gradients and animations running off the cheapest STM32 with 4K/16K RAM, and I'm not even using any bare metal programming to save code space or cycles.

>staying cucked and designing your own hardware
OP learn VHDL if you want to be the Chad of embedded. Look into the SoC Zynq chip from Xilinx. It has two CPUs and FPGA so do the classic Hardware/Bare Metal/Linux combo

Just_Look_at_that_Retarded_Syntax. Who would ever use CamelCase AND underscores? What the actual fuck?
Fuck this shit. You have to write a million lines to set a single bit.

FPGA experience does indeed give you +50 to embedded cred, but it isn't something you should rush to learn before MCUs.

Also wtf are you doing suggesting one of the most complex chips on the market to a beginner.

*not designing your own hardware (fuck me)
But seriously look into FPGAs and even better the SoC. They are of course more expensive than micro controllers but you are not nearly as limited as you can make your own peripherals and stuff like that. Also being able to do everything concurrent (like true concurrent not like those programming languages or whatever that are """concurrent""") is super useful. It requires that you think in a completely different way than when writing slow and sequential software

Well the FPGA part is only as hard as you make it. One should start out with working with the I/O and for instance invert a signal or blink an LED from a button. Getting to use the CPUs on the chip is difficult I will agree and I only have limited experience in that and Vivado (Xilinx' IDE) is a cruel mistress. But I would recommend all Embedded guys to have a CPLD or small FPGA dev board in their collection

You will never be a successful programmer if you hang up on irrelevant shit like mixed case. I have yet to see an embedded API that isn't a mess.

And yes, unlike Arduino, you do have to set a bunch of parameters to switch a single GPIO bit, that's the price of flexibility when your pins have so many different modes. But you write a function for this once and forget it.

FPGAs are not "designing your own hardware". Actually designing your own hardware is designing your own hardware, which is also an extremely useful skill too but it's very difficult to be adept at so many things.

The problem with FPGA is a vicious cycle of there being few FPGA specialists -> companies are wary of using FPGA because a project shouldn't depend on a single irreplaceable guy -> nobody posts FPGA job offers -> there are few FPGA specialists. Job positions for FPGA tend to be very well paid, but there are so few of them.

Attached: Capture.png (415x424, 19K)

>FPGAs are not "designing your own hardware"
but it is lol.
It's not normal programming. You are describing actual hardware when writing VHDL/verilog

>it's the year 2018
>he is not playing with legos

I fucked up the adapter from the motor to the lego though. Just had a quick idea, but will do a clean one tomorrow or suttin.

Attached: lego.webm (1280x720, 2.49M)

PS: Yes, I am using Linux. Not raspbian bloat shit, but Yocto with only stuff that I acutally need. Linux is pretty fucking comfy for embedded dev these days. Like really.

Attached: IMG_6109.jpg (3000x2000, 483K)

It's not normal programming, sure, but it's also nothing like routing a PCB. You are rearranging existing logic in the FPGA based on code.

Lol, I remember making a suspiciously similar thing back in the 90s to lift lego dudes up a tower. There was no CPU in it though, just a timer.

Attached: 12.jpg (1166x1640, 250K)

>but it's also nothing like routing a PCB. You are rearranging existing logic in the FPGA based on code.
You are. You are effectively rearranging the routes and let the synthesis tool generate lookuptables. There is no existing logic. It all gets generated (except of something like multiplication-units, but that's a different story)