they just took 20 yrs to land rtos features in linux, if you plan on building an RTOS its best to fo
they just took 20 yrs to land rtos features in linux, if you plan on building an RTOS its best to focus on micro controllers
XMicrocontrollers is the plan!
Zalso while ‘Making an RTOS’ might seem cooler you are better off ‘sending sensor data to a web dashboard’ which in itself is an iot project. Bonus points if you build everything from scratch (if its for learning purposes)
!check dm
XShould I also grab LEDs to simulate concurrency? Is there a nice kit someone could recommend?
MYou could show it in your serial port. LED are also good way
Get a led pack, resister pack, jumper wires and a breadboard
Get a led pack, resister pack, jumper wires and a breadboard
MHey @everyone, There has been a lot of talk about this, I'm sure you have heard about it, and
wanted to get your take—especially from those of you knee-deep in real-world dev work.
We keep hearing about the shift toward "safer by design" languages like Rust,
particularly in safety-critical software. I can’t help but wonder how much of that
translates to the day-to-day realities of embedded development in our cases.
Take Google’s Android team, for instance—they’ve ditched unsafe languages for new
code, switching to Rust, and they claim a significant drop in memory vulnerabilities as a result.
I do think that is impressive.
But for those of us who’ve been in the trenches with C/C++ for years, is this push for
safety really as transformative as it seems?
Or are we trading old problems for new challenges?
Do you actively think about moving to safer languages? What are the barriers or benefits in your experience? Are you open to it,
or is the idea of leaving C/C++ behind still a bit too wild?
Looking forward to hearing your thoughts!
wanted to get your take—especially from those of you knee-deep in real-world dev work.
We keep hearing about the shift toward "safer by design" languages like Rust,
particularly in safety-critical software. I can’t help but wonder how much of that
translates to the day-to-day realities of embedded development in our cases.
Take Google’s Android team, for instance—they’ve ditched unsafe languages for new
code, switching to Rust, and they claim a significant drop in memory vulnerabilities as a result.
I do think that is impressive.
But for those of us who’ve been in the trenches with C/C++ for years, is this push for
safety really as transformative as it seems?
Or are we trading old problems for new challenges?
Do you actively think about moving to safer languages? What are the barriers or benefits in your experience? Are you open to it,
or is the idea of leaving C/C++ behind still a bit too wild?
Looking forward to hearing your thoughts!
ZIsn't the answer here it depends, And also when teams switch I wonder like for android the code that is switching is the AOSP code not the applications right? I feel like @Ming and @ke7c2mi would have gone through enough to have an opinion on this. I on the other hand think its trading between dieties
TI don't think it's an either/or proposition. There's way too much installed C/C++ for it to 'go away'. In places where it makes sense, and you can realize efficiencies, people will use and learn Rust. But there are going to be multi-language devs and systems.
T@barafael could probably lend you some perspective on what real life is like a Rust dev.
MI think there is a lot of work that still needs to go into making sure those multi-language systems can be built in a way that ensures no rewrites in the future. I say this because last I checked interop isn't at a great place, yet. Especially the interop between Rust and C++, with both having concepts that the other doesn't understand and is hard reconciling like Rust does not understand function overloading and C++ not having traits.
I agree with you though I think it will take some time. And this point, it becomes a matter of urgency but eventually the industry is taking that path.
I agree with you though I think it will take some time. And this point, it becomes a matter of urgency but eventually the industry is taking that path.
ZYou could also interOp by API rather than by FFI then you can have your walled gardens
BDisclaimer I'm a zealot and spent the last 4 years of my career coding (bare metal and distributed systems, also lots of "multi language interop"), mentoring, and teaching rust. And yes, I think it's about trading old problems for new challenges. The old problem is e.g. a hardfault if you are lucky, the new challenge is a compile error. For me this alone was transformative. Package/dependency mgmt, docs, and how rust does zero cost functional patterns did the rest. Also being able to define asynchronous io on mcus and have it translated to a perfect interrupt-driven state machine.
Rust is hard to learn for most, and it stays hard in some ways. And it's immature in some areas compared to others. But it's been so much fun.
Rust is hard to learn for most, and it stays hard in some ways. And it's immature in some areas compared to others. But it's been so much fun.
ZHow does async io get translated to ISR state machines could you shed some light on that please?
BCheck out embassy.dev
ZLol! this is cool, especially the no need for RTOS part
ZIt's been a while since I have tried embedded on rust, last time I think RTIC was just coming online.
BAsync functions represent an operation to be performed. This is a state machine and it's called a future. Every edge of the state machine is to be taken as a reaction to an event. Rust itself doesn't tell you how to drive the state machine, it only provides some of the required infrastructure(waker trait, future trait). The ecosystem does the rest. Tokio is a futures runtime that relies on epoll, kqueue, or other event loop depending on os. Embassy relies on nvic hardware and doesn't need os or allocator
BWorth noting that in theory, by expressing your application with structured concurrency (composing futures together), you can skip the stack. You know the maximum size of your futures statically.
BRTIC (formerly RTFM lol) is a similar beast. They do async too now. But their unique point is concurrency with static guarantee no data races (rust), no priority inversion, or deadlock (RTIC guarantee)
ZEmbassy looks like a young Zephyr to be honest. In part I guess because you have embedded_hal traits and you can just move from architecture to architecture with just commands. It's impressive how much the eco system has grown since 2021
ZAlso thank you for all the info.
MThe argument I was given was that memory-safe languages like Rust, Go, etc is that it frees up the developer to actually concentrate on solving the problem.
Having the language/compiler do bounds checking, Allocation/Deallocation, type safety, etc means that I don't have to, and like most programmers, I am lazy so I'm quite happy for the system to do things for me!
To write 'safe' code in C/C++ is possible - but it means that you need to constantly be aware of what you are doing with your allocations. That can get tiring and at some point something is going to slip through.
One of the dangers I can see is that developers can then get complacent and don't think about their memory management at all - as even in memory safe languages that are going to be some bits that are not memory-safe.
Static and Dynamic Application Security Testing (SAST & DAST) can help but even they are not going to find every issue and even then I have seen them throw up false positives occasionally.
Organisations such as the NSA are advising organisations to move to more memory-safe langauges
https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
Having the language/compiler do bounds checking, Allocation/Deallocation, type safety, etc means that I don't have to, and like most programmers, I am lazy so I'm quite happy for the system to do things for me!
To write 'safe' code in C/C++ is possible - but it means that you need to constantly be aware of what you are doing with your allocations. That can get tiring and at some point something is going to slip through.
One of the dangers I can see is that developers can then get complacent and don't think about their memory management at all - as even in memory safe languages that are going to be some bits that are not memory-safe.
Static and Dynamic Application Security Testing (SAST & DAST) can help but even they are not going to find every issue and even then I have seen them throw up false positives occasionally.
Organisations such as the NSA are advising organisations to move to more memory-safe langauges
https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
R
DHello Folks
TWelcome DNS, what brings you to DevHeads?
ACan I send data for two sensors with two variables from Arduino to ESP32 so that the value of each sensor appears in a different variable in ESP32?
TI'm glad you brought up SAST/DAST in the context of complacent development as I was going to say, "the static analysis tool will catch it!"
That's probably a danger regardless. You're either thorough or you aren't. No language is going to prevent buggy code/bad coding practices.
That's probably a danger regardless. You're either thorough or you aren't. No language is going to prevent buggy code/bad coding practices.
AHi! I stumbled upon this server on disboard. I am but an average electrical engineering graduate who got interested in embedded systems and systems programming, and now trying to self-learn. Currently learning programming on STM32
ZWelcome! let us know when you stumble and we will try to help.
B"No language is gonna prevent bugs/bad coding practices" I do generally agree, but I think that is an oversimplification. It's like saying "no driving style is safe on the road"
TPlease elaborate... If I drive drunk it doesn't matter if I'm in a tank or not I'm still not going to drive well and am much more likely to get in an accident.
If I'm in an auto-piloted taxi, then am I really driving?
If I'm in an auto-piloted taxi, then am I really driving?
BThe driving style is the language. Yes accidents happen even for very conservative drivers, but it just isn't the same likelihood. Not a perfect analogy. But saying the tool doesn't matter is papering over the details
ZNo language or tool offers you
auto-pilot even with the safe languages stuff will still happen.TTradeshow Time 
: https://www.eventbrite.es/e/iot-stars-embedded-world-north-america-2024-tickets-928514942187
: https://www.eventbrite.es/e/iot-stars-embedded-world-north-america-2024-tickets-928514942187Eventbrite
Join IoT Stars during Embedded World North America 2024 and meet leading IoT professionals in Austin, Texas.
TMore info here: https://discord.com/channels/1130679493799977062/1130679493799977066/1290837852707360768. Reply or DM me if you'll be in Austin next week and want to meet up.
UYes, it's possible. You can use wired communication serial UART Pins between both micros.
AI have five sensors. Can I transfer their readings from the Arduino to the ESP32 via UART or do I need level shift?
USince they operate on different voltage level, the best way to use level converter or else you can bring the voltage of arduino to 3.3V. This can be done by a voltage divider circuit using one 10k resistors and one 20k resistor at Tx Pin of Arduino.
ADo you mean like this?
AOr how ?
A@Umesh Lokhande
Uyes, try and test with these connections
AWhat is the best type of ESP32 in terms of voltage reading accuracy from analog pins because I have an ESP32 but the reading accuracy is not stable or close. It rises and falls at high degrees of more than 500 bits up and down and is also not stable. For example, it rises to 1700 and drops to 1432 and rises to 1520 and drops to 1300. What is the solution?
MYou could have an external voltage sensor
Or maybe look at how bits the ADC is
Or maybe look at how bits the ADC is
Uyou can improve ADC's accuracy using reference voltage. Here is how to do it https://www.youtube.com/watch?v=mzlq65fr3uI
AGreetings. I hope you are doing all well. I cannot participate today due to a family issue. I am very sorry for letting you down. I will more likely participate in Sunday's Engineering Hour.
NGreetings! No worries at all. We hope to see you tomorrow for the Office Hours: 'How to Choose the Right IoT Cloud Platform.' Just a quick note, there’s no Engineering Hour this week, so take your time. Looking forward to seeing you soon!
NReminder 
Just 2 hours left until our AMA: Troubleshooting Common Yocto Build Issues! Don't miss your chance to join us, ask your questions, and get expert insights. See you soon!
https://discord.gg/wAYBXw4K?event=1234725050561593425
Just 2 hours left until our AMA: Troubleshooting Common Yocto Build Issues! Don't miss your chance to join us, ask your questions, and get expert insights. See you soon!
https://discord.gg/wAYBXw4K?event=1234725050561593425
THope everything's okay, Maestro.
N@here The event is starting now! Come and join us—see you there!
