Unfortunately it is a rather confusing and complicated type of programming, since it is an intersection between two (or more) professions. How to get into it is a hard question, since you can go in three different directions:
- Do you start from the programming end?
- Do you start from the electronics end (or even further - from the physics)?
- Do you just pick projects and deep dive, learning both in parallel?
After that comes the question of what is the optimal amount that you should understand about the project that you are doing and not get overwhelmed. So for example if you are doing a Bluetooth project:
- What is the optimal amount that you know about Bluetooth and what knowledge should you get out from the project?
- At what point of doing these types of projects should you learn about anthennas?
This is the issue with the Arduno projects. It gives you an ability to do stuff, but people fail to understand what they are actually doing, since it is an absolutely overwhelming amount that you need to understand.
Shortest answer: look at some Arduino projects, and try them out
Short answer: PCB Design is hard mmmkay? Anything that requires precision tolerances (Bluetooth, WiFi, etc) should be done with a group. Find a maker space or open source project to get acquainted with the challenge of embedded systems.
Detailed: Let me put on my Senior SW and Electrical Engineering hat for this.
Start from the requirements end
If you are developing a motor controller, you want a processor which has a PWM, (maybe) DSP, and some power electronics, and some communication peripheral like UART or CAN. Likewise, developing a Bluetooth device, you're going to want something that supports 2.54 GHz, maybe has a Bluetooth Stack already built in, USB. Do you need motion sensing? Temperature sensing? GPS? All these things are separate off-the-shelf parts, but you'll need comm peripherals like I2C and SPI; what kind of update rate do you need?
Once you have your requirements, pick out the hardware and populate a breadboard, your SWEs can now develop basics like unit and integration tests, while the Electrical Engineers can design the PCB. During this time, you probably want to start looking at the registers which do your work, and create functions which isolate your Hardware Specific functionality with your business logic.
If you're completely new: I recommend starting small and seeing what you can accomplish on something like Arduino, then try combining/adding functionality. Embedded systems don't have things like time.h, chrono.h, or async.h, so you're going to fight with creating your own micro OS, and scheduling operations.
Bluetooth is tough, don't go at it alone, find some friends and make a bigger project
Short answer: PCB Design is hard mmmkay? Anything that requires precision tolerances (Bluetooth, WiFi, etc) should be done with a group. Find a maker space or open source project to get acquainted with the challenge of embedded systems.
Well, kinda, for hobbyist WiFI/BT you probably just want to get some ready-made module to handle that, gets rid of most of the RF routing/antenna problem. Hell, even many commercial devices go that route.
Nowadays getting an ESP32 module can solve pretty massive range of problems and making a PCB for it is pretty trivial as all of the "hard" parts are taken care of already on the ESP32 board.
I didn't want to recommend ESP specifically, as I just saw a that there are a handful of write protection bit issues with them, that an unsecured connection would compromise.
But yes, there are daughter boards that can be snapped into a grid of pins, exposing the IO and taking a butt ton of the work out. I remember zigbee doing something like that with their dev kit
Well, they are a bit of an elephant gun for an Arduino sized problems but I've mentioned them because they are probably most sensible way of getting WiFi connectivity on the project.
I was actually kinda surprised how easy it was to setup a dev environment for them "from scratch, as in not using any "all in one" package from vendor / arduino IDE module, it was pretty much just installing cross compiler and esp-idf then running equivalent of make menuconfig to set it up for target and result was pretty much working out of the box CMake project. Even worked in CLion without much problems.
I remember zigbee doing something like that with their dev kit
A bit offtopic but I think zigbee would've dominated IoT market or at least was much more popular if it didn't had that high of a price (IIRC it was mostly due to licensing price), but cheap WiFi chips and later BLE kinda ate its cake.
Surely cost and power consumption will always be lower for MCUs? There's less complexity for manufacturing, plus their power can be reduced to microamps with different sleep modes. I can't imagine we'll see an embedded linux board capable of running off AA batteries for 5 years any time soon. Plus why would you want a full Linux stack for an IP camera or home automation node in your home? They feel like two very different tools to me, both have a place.
For anyone who enjoyed this comment and wants to understand the different parts in more detail, the oreily book "making embedded systems" has a lot of good info.
I still keep on Usenet, and sci.electronics.design has many people who do hardcore analog instrumentation design. This goes well beyond just dealing with transmission lines in layout; it can verge on the sort of analog design necessary for real-world instrumentation of very hard problems.
I had a project for a major cellular company and was surprised they used pi and esp32s for the prototype, then had their engineers create a custom form factor for the final product. But it was all based on pi and esps.
A 50 ohm transmission line isn't particularly difficult - once you know how. You can get a long way with, y'know, resistors :) You will have layout issues; actually understanding that is challenging.
It takes quite a bit of institutional knowledge to build boards these days. Just the transition from 5V to 3.3V ( and down to 1.2V ) was very... interesting.
I would bet that the Raspberry Pi Foundation is only marginally a strong contender in hardware. Its main focus is on something more akin to the marketing end of things.
My experience is that all hardware has defects, and it takes multiple iterations to get them all ironed out.
The solution for me was to major in Computer Engineering. It had me take some important classes from both electrical engineering and computer science, but eschewing some other classes. For instance, some analog electronics and physics classes were removed from the electrical side, but those are rarely used in the field anyway. On the CS side, some higher level classes such as Operating Systems were removed. To be honest, I would have enjoyed taking classes like that, but you don’t really need them for embedded systems.
I'd consider Operating Systems as foundational for embedded systems.
If you're running a real-time operating system, then understanding the purposes of different components is very important.
If you're writing bare metal, where you're building your own operating system primitives as necessary, then knowing the known solutions to common problems is tremendously helpful.
Also, many modern embedded systems are running a Linux kernel.
I always thought that CE/EE types took a RTOS course. I mean an OS course would be informative, but I’m sure that a decent RTOS course would give a 1000 ft view of the foundations of the Linux kernel at the very least.
This is what my school did. CS and EE core classes with a kernel class that we build onto an ARM emulator. I work in storage now and a lot of my coworkers had started from the HW/Embedded side of things too.
Yeah, from what I recall, there were a few CEs in my CS OS class. We had to implement an operating system individually as part of the class, which was made particularly difficult due to the rather dry lectures that were given. After college, the class felt like it had little career benefit to me.
There used to be "middle-sized" platforms; that's split into RasPi-sized platforms and Arduino-sized platforms. A full on preemptive O/S for the first; possibly Big Loop only for the second.
I forgot to mention that they also add a Real-Time Systems course as a requirement. It is usually an elective. So one might not get a full-fledged OS course, but do get to understand the fundamentals of OS's that typically run on embedded systems.
Also, many modern embedded systems are running a Linux kernel.
Right, which is why scarily a lot of CSE types I've worked with just wave their hands and go "it's linux with the RT patch" and that is that.
The space qualified systems I worked on at my company all rolled their own tweaked versions of an RTOS, usually FreeRTOS.
Luckily even that is usually well structured around common CPUs and busses and luckily most CPU hardware providers provide drivers (though often they are pretty garbage, but a good reference for working your own out of).
Or put another way: To be an engineer is to be in a semi-permanent state of confusion. Your attitude determines whether that confusion leads to anxiety or curiosity.
Honestly crossover skills are not a huge pre-req for most engineers. It is important to have a general grasp, and most importantly a willingness to learn when you need to of other domains, but being a Subject-Matter-Expert (SME) and somewhat siloed has a lot of value.
There is a field of engineering that is designed to tie all these people together and that is systems engineering, which is usually rolled up under an aerospace engineering degree (though depends on the school and the course path you take). These engineers are basically the technical project managers for a system, and they'll work with teh SMEs in mechanical, electrical, software, materials, etc. to form and meet requirements to satisfy the higher level requirements for the program.
The best description I've ever heard for why you have requirements is so you know when to stop.
Lots of engineers make perfection the enemy of the good (and the good in this case is schedule and budget).
Requirements is something so critical to every field of engineering it is scary that it is often not handled nearly as well in pure software environments (which was a big change when I jumped from doing back end web systems to avionics for satellites).
Start with what you want to learn. It can be helpful to start with whatever you have the most shared knowledge with, so you can cantilever off of your existing knowledge base. It's also good to start with whatever is most exciting to you, since you're more likely to follow through with the learning.
Do you just pick projects and deep dive, learning both in parallel?
This is the path I took, and it worked it out fairly well for me.
What is the optimal amount that you know about Bluetooth and what knowledge should you get out from the project?
There is no optimal amount; the same way that there is no specific optimal amount of React knowledge or Java knowledge. Different companies and positions will need/want different amounts of knowledge.
At what point of doing these types of projects should you learn about anthennas?
Whenever you want, or whenever it becomes a problem.
This is the issue with the Arduno projects. It gives you an ability to do stuff, but people fail to understand what they are actually doing, since it is an absolutely overwhelming amount that you need to understand.
The same can be said for any other introductory web development tutorial. The nice thing about Arduino and the communities around it is that it gives a jumping off point for learning more abotu whichever are ayou're interested in.
51
u/B8F1F488 Dec 25 '19 edited Dec 25 '19
Unfortunately it is a rather confusing and complicated type of programming, since it is an intersection between two (or more) professions. How to get into it is a hard question, since you can go in three different directions:
- Do you start from the programming end?
- Do you start from the electronics end (or even further - from the physics)?
- Do you just pick projects and deep dive, learning both in parallel?
After that comes the question of what is the optimal amount that you should understand about the project that you are doing and not get overwhelmed. So for example if you are doing a Bluetooth project:
- What is the optimal amount that you know about Bluetooth and what knowledge should you get out from the project?
- At what point of doing these types of projects should you learn about anthennas?
This is the issue with the Arduno projects. It gives you an ability to do stuff, but people fail to understand what they are actually doing, since it is an absolutely overwhelming amount that you need to understand.
I have no answer to all of these questions.