61–70 of 71 posts
I am toying with SPARK on smaller chips. You can gradually replace parts of C code, like I think you can in Rust too, and work up to doing full-scale replacement or projects from scratch with SPARK on embedded devices, which has a lot of the benefits of Rust and then some[1][2]. I am a polyglot with certain biases/strengths in some PLs over others, so perhaps my early 80s experience with Pascal makes Ada/SPARK2014 ea…
I was looking forward to trying Rust on my ESP32 projects but always had a hard time. All the tooling is too complicated. There is flasher coded in python, IDF coded in C, you need to run MinWin on Windows which makes it even harder. You can't run all of this in docker because docker for windows doesn't allow mapping COM ports into container and stuff. Everything about just compiling a code seems so tiresome and unst…
Well not to be inflammatory, but aren't you making your life more difficult by doing development on Windows? You could just run Windows in a VM if you need any Windows specific software, and have your main OS be something more suitable for software development. Of course ideally everything would just work on Windows, and there's nothing wrong with running Windows as your main os, but the reality is that especially bl…
I play a lot of games and use lab software for electronic engineering so Windows is a must.
And try to convince my wife I need a third computer.
Earlier quoted context omitted.
Well not to be inflammatory, but aren't you making your life more difficult by doing development on Windows? You could just run Windows in a VM if you need any Windows specific software, and have your main OS be something more suitable for software development. Of course ideally everything would just work on Windows, and there's nothing wrong with running Windows as your main os, but the reality is that especially bl…
As sibling says, for embedded toolchains Windows is often the best supported platform.
I was looking forward to trying Rust on my ESP32 projects but always had a hard time. All the tooling is too complicated. There is flasher coded in python, IDF coded in C, you need to run MinWin on Windows which makes it even harder. You can't run all of this in docker because docker for windows doesn't allow mapping COM ports into container and stuff. Everything about just compiling a code seems so tiresome and unst…
Well not to be inflammatory, but aren't you making your life more difficult by doing development on Windows? You could just run Windows in a VM if you need any Windows specific software, and have your main OS be something more suitable for software development. Of course ideally everything would just work on Windows, and there's nothing wrong with running Windows as your main os, but the reality is that especially bl…
MacOS...has a monopoly on developing for Apple products, but I can't imagine the embedded toolchain is particularly good?
I do enjoy the image in my head of some hipster guy in a coffee shop with a macbook, scope, power supply and a bunch of wires sticking out a pcb trying to debug something though.
I am toying with SPARK on smaller chips. You can gradually replace parts of C code, like I think you can in Rust too, and work up to doing full-scale replacement or projects from scratch with SPARK on embedded devices, which has a lot of the benefits of Rust and then some[1][2]. I am a polyglot with certain biases/strengths in some PLs over others, so perhaps my early 80s experience with Pascal makes Ada/SPARK2014 ea…
Out of curiousity, what do you feel Rust would need to reach maturity?
Earlier quoted context omitted.
Well not to be inflammatory, but aren't you making your life more difficult by doing development on Windows? You could just run Windows in a VM if you need any Windows specific software, and have your main OS be something more suitable for software development. Of course ideally everything would just work on Windows, and there's nothing wrong with running Windows as your main os, but the reality is that especially bl…
I'm not sure of the situation with ESP but in many embedded environments you HAVE TO use Windows for development.
I think more embedded devlopers should insist on only using linux tooling. Windows is a broken platform for software development. Programming an embedded device should be as simple as using GCC and a flashing tool.
Requiring some kind of insane windows IDE seems like such a 1990 way to develop software, imo.
Earlier quoted context omitted.
They do help, hard realtime only means that there can be no blocking (critical) section with a possible unbound time limit, toggling an IO register with a lower frequency as the CPu clock can still be done while shovelling in datagrams into the RF stack that can DMA acces in withput any CPu doings anyway..
i agree it can be done but it's a fragile balancing act. What I don't agree with is that Rust provides anything particularly special allowing you to do this.
It only is if its done that way.. Normally you use a small RTOS that provides some sane abstractions to handle such mix of tasks or you can add some code that does that, for simpler applications (where simple does not mean uncritical or not hard RT) that can work fine too, and especially a single core can make things easier to argue about.
> What I don't agree with is that Rust provides anything particularly special allowing you to do this.
Well, compared to what? While there are already some languages (like nesC) or "frameworks" (OS) that do something like that they are well, frameworks and not a language or tied to a specific "runtime (environment)" like nesC is to tinyOS.
Rust itself provides protection against data races, which already helps a lot for making it less fragile, as you call it, and it also provides type-based (thus zero runtime cost) access control and design contract functionality, check:
https://docs.rust-embedded.org/book/static-guarantees/index....
Compared to plain C, ASM or C++ this is something special that rust provides in helping to do that.
Look, I do not argue that two cores do not help to have to separate domains for different level of critical, but quite often you do not require that, I mean I did some hard RT applications with FFT + a PID controller running or some fixed point physic calculations going on plus an user interface + GLCD output and communications (e.g., wifi, zigbee and/or UART) on a very basic 16 MHZ or sometimes (for bigger stuff) 32 MHz AVR chip.
Compared to that AVR chip, which could already handle a lot of not-so-simple hard RT apps here, the ESP C3 RISC-V CPU has:
* 160 MHz – so 5 to 10 times more, and a 4-stage pipeline compared to 3 on the AVR IIRC
* 15 levels of interrupt priority one can configure (the AVR only had a fixed level and the ISR basically had to turn of interrupts completely.
* a general DMA engine that can handle 108 to 128 MB/s so way less work for the CPU to shovel data towards UART, I2C, SPI, the crypto engines or the WiFi Bluetooth stacks.
With all that you got most of the more frequent interrupts stuff gone even while sending lots of stuff over the ether and the CPU can handle the actual app.
Oh, this is exciting. I've been trying to get PlatformIO to play nicely with my ESP32C3's but it's been a pain. Only the standard Espressif RTOS tooling seems to do anything but hang the chip for some reason, and I don't know enough about PlatformIO to modify my config to make it work or to open an issue on Github. Replacing one complex, half broken tool chain with another isn't such a bad deal, and I'm very much in…
I may not had to much nerves to just wrestle the initial learning curve, but my experience for PlatformIO was so bad that I do not plan to touch it ever again... All you need is a compiler, a flash tool and maybe (nice to have but for a lot of stuff not a requirement) a JTAG debugger, so why the heck does I need that half baked, overly complex monster of pseudo IDE? The tooling shown by ESP-rs seems nice and simple,…
Earlier quoted context omitted.
Well not to be inflammatory, but aren't you making your life more difficult by doing development on Windows? You could just run Windows in a VM if you need any Windows specific software, and have your main OS be something more suitable for software development. Of course ideally everything would just work on Windows, and there's nothing wrong with running Windows as your main os, but the reality is that especially bl…
In my experience Windows is the generally the best supported for general embedded work, video, graphics, audio, hobbyist, IDEs, etc. Linux has the best for server and server related hardware but is often pretty equal..ish? MacOS...has a monopoly on developing for Apple products, but I can't imagine the embedded toolchain is particularly good? I do enjoy the image in my head of some hipster guy in a coffee shop with a…