How much effort will it be to learn to deploy #rust on my #arduino vs learning enough C to get by?
-
@alter_kaker @riley For local variables you have a few ways. Add {} to the field declaration ('u_int8_t foo[SIZE] {};'). Then for every ctor the compiler will zero init foo unless the specific ctor has a different member initializer.
-
@alter_kaker @riley Or write a ctor that zero initializes. Or don't declare a ctor but when declaring an instance of Buffer, add those {} 'Buffer foo{};'
-
@alter_kaker @riley Yes it's complicated
-
@alter_kaker @riley I've been into that mess posing as a programming language for so many years
-
@alter_kaker @riley Oh random thing. That #define thing. You need them much less with modern c++. "constexpr std::size_t BUFSIZE = 512;". Observes variable scoping instead of being mechanically replaced everywhere. Can still be used as array bounds.
-
@project1enigma
I have no idea what compiler this is using.
@riley -
Riley S. Faelanreplied to Yeshaya Lazarevich last edited by
@alter_kaker Do you have something like a logic probe or another Arduino to see whether the traffic between the Arduino and the SD card makes sense?
-
Riley S. Faelanreplied to Yeshaya Lazarevich last edited by
@alter_kaker I seem to have missed it, and the webpage expired.
-
Riley S. Faelanreplied to Yeshaya Lazarevich last edited by
@alter_kaker
constexprhas been around for quite a while. Unless you're specifically doing retrocomputing, your compiler has a fairly high likelihood of supporting it. You can give it a try, and if the compiler balks, work around it. -
@riley @alter_kaker IIRC one more C like way to make a constant without the preprocessor is an enum member...
-
@project1enigma Yep. Depending on how you use the constant, C++ might complain if its idea of the enum type doesn't match your use, however.
-
Yeshaya Lazarevichreplied to Riley S. Faelan last edited by
@riley
More questions! I've been reading about interrupts, and there seems to be a concern about invoking functions from a c++ class in an interrupt, and the possible need to mark the class and all its members as volatile. What do you think?If I need to do things like making a static ISR method in the c++ class with vector tables or smth, that might be more than what I want to learn right now. I could go back to using a procedural API and just refactor it a bit better.
@project1enigma -
Riley S. Faelanreplied to Yeshaya Lazarevich last edited by
@alter_kaker The basic theory is, an interrupt can happen in the middle of other calculation, and change variables that the compiler didn't know might change, and optimised your code with the assumption that they wouldn't. If you mark the variable as volatile, then the compiler will refrain from such an assumption, and translate every reference to the variable into an independent fetch.
There's also the concern that the environment you get to run your interrupt handler in might be harder to understand, or more limited, than most. A very common issue is, you might not have a lot of stack remaining in an interrupt handler. Similarly, your outer data structures might be in the middle of manipulation, in an incompletely updated state, during the interrupt. So, the general recommendation is to do as little work in the interrupt handler as you can reasonably get away with, and instead, just raise a flag suggesting that the work needs to be done, and then processing that flag later. This sort of flags are the canonical example of variables that must be marked volatile.
I wouldn't rely on being able to register a dynamically bound method as an interrupt handler, at least without checking whether the specific framework specifically promises to support this. Interrupts are kind of inherently global things, so if you rely on
this, it must be looked up somehow, and naïve implementations might just lose it, leading to weird crashes. Interrupts have some similarities with things like, say, JavaScript events, but they're a lot more primitive inside.Sorry if I missed it — what is it that you're doing?
