Embedded Programming The Future

Go To Last Post
26 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All,

This is a programming question, the job market seems to be steadily moving ARM FreeRtos Linux etc etc.

To future proof career prospects, would you add C++ (or Python) to my skills or stay with C. I do not really understand the ARM Linux part. Does this mean people are writing FreeRtos code on Fedora or Ubuntu in say Eclipse and programming ARM chips. What advice would you give, as i am currently a bit lost on what way to turn.

Thanks,

Tuurbo46

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Embedded systems is a fairly broad description. It ranges from tiny single chip micros up to large distributed systems. For me personally i generally work with single chip micros. I use C,C++ and javascript on these. For small linux based systems like wireless router based boards to the likes of raspi I program in C,C++, lua, javascript and maybe python. For the most part i’d use existing applications like mosquitto, lighthttpd, sqlite etc to provide infrastructure.

I went for an interview last week and the requirement was programming ARM. I was asked about my experience with a variety of cloud and web based technologies of which I’ve had significant exposure to.
People want to harvest data from the real world using small micros and have them communicate to cloud based servers where the data is collected, processed, analysed and presented via web pages to the users.

As for what operating system you use on your desktop machine varies. I use mac and have virtual machines for windows and linux. Many tools these days work on all. I have a free instance on Amazon AWS for testing cloud servers that runs linux.

Note that ARM have both microcontrollers that are usually single chip micros with on chip flash, to the Cortex A series that are multi 100MHz to GHz multicore processors with memory management and demand paged virtual memory. The A series is what you’d normally run a small version of Linux on. These would have many megabytes of ram and external flash. Virtually all smartphones (even Apple) and tablets run ARM architecture processors.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tuurbo46 wrote:
To future proof career prospects,
To prove the future is a fallacy.

Better is continuing education, just-in-time training, seek a mentor/become a mentee/join a guild (read, listen, Q-and-A), practice (the journeyman becomes a master)

Tuurbo46 wrote:
(or Python)
Python is one of the memory-safe computer languages.

Tuurbo46 wrote:
or stay with C.
C is alive and well; Checked C is of interest.

fyi, C++23 may have fixed-point math.

Tuurbo46 wrote:
I do not really understand the ARM Linux part.
Likewise (Linux kernel is 1MB of object code)

Some customers require less (an RTOS of 100KB or 10KB of object code, and/or, a framework)

Tuurbo46 wrote:
What advice would you give,
Turn with your customers.

Will that be correct for your career? Maybe

Will that be a match for you? <your answer is within you by your intuition>  (caveat : avoid moral hazard)

Project and people versus CPU/OS/computer languages

From mid-80s EE Times, the top three for what one seeks in a "job" :

  • challenging work
  • good people to work with and for (in, with, and/or at an entity, partnership, or team) (peers, managers, directors, executives)
  • recognition

 


Memory safe computer languages | AVR Freaks

C: The Immortal Programming Language « Barr Code

Checked C - Microsoft Research

2019-07 Cologne ISO C++ Committee Trip Report — 🚀 The C++20 Eagle has Landed 🚀 (C++20 Committee Draft shipped; Contracts Moved From C++20 to a Study Group; `std::format` in C++20; C++20 Synchronization Library) : cpp

...

 

Library Evolution Working Group Incubator (LEWGI) Progress

...

...

GitHub - johnmcfarlane/cnl: A Compositional Numeric Library for C++

Modern Embedded Programming: Beyond the RTOS « State Space

EE Times | Electronic Engineering Times | Connecting the Global Electronics Community

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess it depends on the environment where you intend to work but in my personal experience (last 10 years in automotive) the use of C (with one notable exception in this area) is all but dead. All production code (usually running on powerful, muticore ARMs) is C++ with a lot of the system, support code in Python. So in my world I'd concentrate on C++ and Python. (the "host" side of Electronic Control Units in cars almost certainly complies with Autosar and that bit is C not C++).
.
Of course a huge developing area is IoT and Web technologies and if you wanted to target that you might be looking at a completely different skill set.
.
As a dyed in the wool Asm and C programmer I found the transition to C++ quite fraught. It's not just some additional syntax to learn but a whole different approach to problem solving. (quite a lot of my C++ probably appears very C like in fact!)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

Thanks for your input.  My interests are robotics and automotive.  I started in electronics, then jumped across to embedded so I work in the electronics/ embedded areas.  I currently work in robotics but quite old fashioned robots that have ten 8-bit micros onboard.  At some point the products will be updated and probably go RTOS.  There has been talk of bringing in contractors to kickstart new development, but I would like to be up to speed on RTOS before it starts.

 

I know its always hard to give advice but would you learn C++/ Python on desktop programs, or jump straight into buying a FreeRtos dev board and start from there.  

 

Thanks,

 

Tuurbo46

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tuurbo46 wrote:
... but would you learn C++/ Python on desktop programs, or jump straight into buying a FreeRtos dev board and start from there.
Start on a PC or such then re-evaluate.

Reason : More choices in editors and IDE when learning a computer language (embedded development can lead to restrictions)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

What has FreeRTOS got to do with C++ or Python?

 

But anyway I'd learn both on a PC where the dev systems, debugger and access to instant feedback are much easier. Port your language knowledge to embedded later.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
What has FreeRTOS got to do with C++ or Python?
MicroPython on FreeRTOS on :

  • Texas Instruments CC3200
  • Espressif Systems ESP32

MicroPython is on the ZephyrTM Project RTOS though on a few boards.

Zerynth Python is on ChibiOS or FreeRTOS.

 

https://github.com/micropython/micropython/tree/master/ports

GitHub - wipy/wipy: The WiPy libraries, releases, hardware files and docs (TI CC3200)

Home | Zephyr Project

Zerynth Supported Devices

ChibiOS free embedded RTOS - ChibiOS Homepage

 

edit :

Zerynth - The Middleware for IoT (DesignSpark)

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Fri. Aug 23, 2019 - 02:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The OP asked:

 

Does this mean people are writing FreeRtos code on Fedora or Ubuntu in say Eclipse and programming ARM chips.

The language you write in is quite independent of the OS that runs your development (provided the appropriate tools are available). When you write "FreeRtos", you would NOT  be using that in a runtime environment with a real OS such as linux. So, simply mentioning FreeRtos implies cross-compiling and the process of cross-compiling is essentially host-OS independent. So, you are mixing apples and oranges, the target and the host. 

 

Likewise, when you write "ARM chips", you could be writing apps in Python or C or C++ or whatever that execute in a linux environment OR you could write in a variety of languages, maybe leveraging FreeRtos (but not necessarily so), to run without an OS.  

 

To not lock yourself into a dead-end, you probably ought to be at least conversant with these various situations.

 

Also, team-work is one of the characteristics of the programming job space that is becoming increasingly true at the low end. For someone doing professional work with the kinds of tools that you mention, it appears more and more true that you will be part of a team. This is happening because of the sheer code size but also to (try to) insure code quality and reliability. In many ways, being able to work in a  team environment is almost more of a challenge than dealing with the issues like algorithm design or program structure or matters of language-specific syntax.

 

Those are my two cents, pence, centavos, whatever.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tuurbo46 wrote:
To future proof career prospects,

Good Luck with that...

 

 

I am guessing you are a student in University maybe?  Not too important.  But my outlook is the same either way.(and sounds somewhat like another Freak, may the deities prevent that I beg)

 

If you want to do programming as a career....Do not get into embedded systems.  >>WHAT!?<<  Yep.  I said it.  If you really want to sit and write code all day and drink fluids with a lot of caffeine, then get into web development.  Strictly software.  Why?  The landscape has changed dramatically, and in a very short time.  Hardware development is not what it used to be.   Nowadays most hardware is done on Arduinos or Beaglebones et. al. and once proof of concept is done, and the investors are signed, someone flies to China and they have them hack it apart and make it cheap for mass production.  It's not easy to get into any meaningful hardware development opportunities these days....but web designers...good ones are getting good pay and other perks as well.  Especially here in the NYC area.  I look back now and wish I had taken that path as opposed to the one I did.

 

Then again, you could also take advice from a line in my signature regarding a known career path.  wink

 

All the best on your quest

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Last Edited: Fri. Aug 23, 2019 - 04:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If it were me, I'd start with the things you know you don't understand.  It's a 'known unknown', and you know how to deal with it.

 

Tuurbo46 wrote:

 I do not really understand the ARM Linux part

 

Get them straight.  Personally, I couldn't use an ARM chip to run a robotic arm, but then again, nobody's asking (or offering to pay) me to.  S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am sure as heck no robot authority, but I do know a spot of that Linux stuff. So my question is, does that robot move with a BLDC motor? Because Linux is not going to do that for ya; I don't believe that an RTOS will ether. So if you don't want to ponder on the BLDC and its control signal(s), and frankly who would, it is way more interesting to consider choreographing the kinematics, and that is right proper out of my paygrade, but I think that might be more of a Python and Linux thing. One thing I find mysterious is how the choreography signals could be made from the data that an R-Pi Linux machine might be able to spit out. It seems to me that the Linux machine needs to feed an MCU or FPGA with the kinematics data so it can buffer and output the signals jitter free. To my eyes, an RTOS is a sort of snake oil, but I want Linux to be responsive like an RTOS, does that make any sense.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can run a RTOS under Linux if you so desire - look at Linux CNC. I have it running my CNC mill.

 

RasPi rather sucks for any decent real time stuff as it has crappy i/o, That doesn't stop it talking via USB or ethernet to a controller that does the grunt work. If you want to do machine vision, then the Raspi is ok for that - as 'real time' for that is usually 100's of milliseconds +.

 

There's also a swag of multicore chips that have Cortex M and Cortex A processors so the A runs the likes of Linux and the M runs the bit bashing real time stuff. So running freeRtos on the M and Linux on the A is a real possibility. The likes of the Beaglebone have two 200MHz 32 bit cpus called PRUs on chip with a 1GHz Cortex A. There's examples of CNC controllers using the PRUs to run the motors and the computation done on the A under Linux. 

 

Back in the early 2000's I was using embedded Linux boards talking to AVRs. Fast forward a few years and you have the Arduino Yun that has a wireless router chip running Linux talking to an AVR or a Raspi connected to an Arduino via USB.

 

There's a project I was looking at recently that is a port of GRBL (originally for an AVR) which is a CNC/laser cutter/3d printer controller. This port is for an ESP32 which gives it Wifi and a web page for the user interface - the code is in C/C++ and html/javascript for a single chip micro!

 

My biggest learning curve at the moment is crypto - just about anything that communicates requires encryption at some level. It's not really an option these days - you need crypto.

 

One of my recent projects started as a serial to WiFi gateway. The scope grew and now I've got a swag of configuration and diagnostic functions to implement. Since I'm constrained a little on flash storage, I need to be careful how big my web page code gets, so this rules out a lot of the libraries and frameworks you'd normally use on a 'normal' web page. 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A lot of the top end CPUs are like that. An "application processor" (in fact 4 or 8) and then lots of small CPUs, often M3s dotted around. You run Linux on the big cores and the small ones control the peripherals.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ron_sutherland wrote:
I don't believe that an RTOS will ether.
An RTOS can though may be safer to have a BLDC ASIC that receives a commanded speed and contains a watchdog.

ron_sutherland wrote:
To my eyes, an RTOS is a sort of snake oil, ...
Though some RTOS have an impressive EAL that may be a systems requirement due to safety standards (railway, avionics, mechatronics, automotive)

ron_sutherland wrote:
... but I want Linux to be responsive like an RTOS, does that make any sense.
Yes and available.

IIRC, real-time became configurable in Linux kernel v4.

Linux's latency may be greater than an RTOS's latency though may already be more than adequate.

 


An OS in a Can | The Ganssle Group

[4th paragraph]

After this experience [frantic simple RTOS] I looked back and realized that a number of systems that I'd built would have been easier to code and more robust had I included an RTOS. 

...

EAL - Evaluation Assurance Level 

The Common Criteria | CISA (USA Department of Homeland Security)

[mid-page]

Common Criteria Evaluation Assurance Levels

IIRC, some Linux distributions are at EAL2.

There may be only a relative few RTOS at the upper EAL, and/or, may be mostly frameworks and schedulers.

 

Home | seL4 (for CPU with an MMU)

leads to an assured RTOS for a few MCU with an MPU :

eChronos RTOS | TS | Data61

 

CubedOS: A SPARK Message Passing Framework for CubeSat Flight Software

Intro To SPARK | learn.adacore.com

 

Latency | RealTime < Linux4SAM < TWiki (scroll down to benchmarks (two) for test result data)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you heard about the Tesla wiring patent?   They want to put more controllers into cars.  The following is quoted from a CNET article.  For example a door would have a controller to handle locks, windows, mirror, etc.

Tesla's immediate solution at the time was to shrink the size of the various harnesses into smaller sections that were less complicated to install in the vehicle. The new architecture design iterates on that idea by breaking the harnesses out into subassemblies with controllers. This also allows the harness pieces to be made more rigid, which will ease installation for robots.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
As a dyed in the wool Asm and C programmer I found the transition to C++ quite fraught. It's not just some additional syntax to learn but a whole different approach to problem solving. (quite a lot of my C++ probably appears very C like in fact!)

I am glad to hear I am not the only one who found the transition from C to C++ problematic.  My C++ code was mostly C hacked into the existing C++ code I was adding features to.  I dont know why it was so hard for me at the time, but looking back at it now the object stuff seems pretty straightforward, but it is indeed a different way of looking at things. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
Latency | RealTime < Linux4SAM < TWiki (scroll down to benchmarks (two) for test result data)

 

10 to 30 uSec of jitter to the speed or position pulses sent to a BLDC drive sound like a disaster. I have worked with high-end PNP (and some CNC) machines, and they would shake the parts off in an instant when jitter got into there timing. I seem to recall the position pulse timing being better than that, a lot better, I do not think an RTOS (or even an ISR from an MCU) was making the pulse (e.g., the position or velocity steps) timing that told the BLDC drive what to do. I have a notion that the PWM hardware could be set up to make precise pulse outputs accurate to within a clock cycle. If that was true, then an R-Pi could calculate data for a multi-axis move and stream it to the MCU to buffer and place on the (PWM) registers that would cause the precise pulse timing for the move. There would be no jitter, and most any multi-tasking time-sharing bull shit would be okay.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ron_sutherland wrote:
10 to 30 uSec of jitter to the speed or position pulses sent to a BLDC drive sound like a disaster.
That's possible as real-time Linux's jitter is an order of magnitude greater than the precision of GNSS PPS.

 

 

RTLinux/RTCore dual kernel real-time operating system

by Victor Yodaiken, Cort Dougan, Michael Barabanov

FSMLabs

https://www.fsmlabs.com/pdfs/RTLinuxPro_White_Paper.pdf

[page 1, top of right column]

...

A one millisecond periodic thread running on a 1.2GHz AMD K7 PC shows worst case scheduling jitter of no more than 12 microseconds when the secondary kernel is under heavy load.

...

via News | FSMLabs (legacy, page 15 of 16)

due to

Real-Time Control of Magnetic Bearings Using RTLinux | Linux Journal

[after]

Figure 4. Oscilloscope Trace Comparing Digital (Upper) to Analog (Lower) Controller Response to a Mechanical Impulse

Advanced Experiments

...

The rotor has spun up to 11,000 RPMs successfully, with the AMB [active magnetic bearing] under full digital control, passing through a critical speed at 2,700 RPMs. In virtually all rotating machinery, from the humblest hair dryer to the modern passenger jet engine, critical speeds occur at distinct RPMs. At these critical speeds, the vibration of the rotating shaft grows large and places high loads on the bearings and other components. These present extreme tests for the bearings.

...

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But the usual situation in an SoC is an application CPU for the OS operating application and a bunch of MCUs (usually M3) dotted around for the real time hardware interaction stuff.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

High end servo systems would be using dsp for control and/fpgas. Of course, you can get a couple of cortex A class cpus along with your fpga fabric on the one chip these days.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

IIRC, RTLinux is not Linux: RTLinux, with it's own scheduler, takes over the hardware and runs Linux as a low priority task.

Last Edited: Mon. Aug 26, 2019 - 12:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

Thanks for all your input.  I have learnt so much from this post. 

 

Does anybody recommend the least painful book/website transition from C to C++.  

 

Many thanks,

 

Tuurbo46

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tuurbo46 wrote:

Does anybody recommend the least painful book/website transition from C to C++.  

Tuurbo46

 

Potassium cyanide.  What you what is the most useful transition.  S.

 

Edited to add:  There will be pain any which way.  It's how you learn.  S.

Last Edited: Tue. Aug 27, 2019 - 08:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Future-Proof Your Career with Lifetime Education | Electronic Design

With many employees now extending their stay in the workforce, it’s becoming more important to adopt a pattern of “lifelong learning” to keep up. And more universities are getting on board to meet those needs.

Nelson C. Baker | Aug 01, 2019

...

Nelson C. Baker, Ph.D., is the Dean of Professional Education at the Georgia Institute of Technology and professor in the university’s School of Civil and Environmental Engineering.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

IIRC, real-time became configurable in Linux kernel v4.

and v5 on 20-July'19 for PREEMPT_RT (not hard real-time)

realtime:rtl:blog [Wiki] | The jury has spoken

via realtime:start [Wiki] (Linux Foundation)

 

"Dare to be naïve." - Buckminster Fuller