How much effort will it be to learn to deploy #rust on my #arduino vs learning enough C to get by?

always tired

@alter_kaker @riley Where do buf_a/buf_b point to?

Yeshaya Lazarevich

@project1enigma
haha I just fixed it, they were not pointing to anywhere... Updated to initialize in the header file as arrays. @riley

always tired

@alter_kaker @riley That's probably what you need, arrays.

Yeshaya Lazarevich

@project1enigma
It works now, so clearly you're right . I got confused by how arrays get initialized. Does this impact ctor considerations?
@riley

always tired

@alter_kaker @riley Unless you depend on certain initial values of the buffer, you could still omit the ctor (use the compiler defined default).

always tired

@alter_kaker @riley That would leave the buffers uninitialized. But the storage is allocated. That's okay as long as the first access of each cell in the arrays is a write (e.g. by File::read)

always tired

@alter_kaker @riley If you'd want to make sure zero initialization... As long as the only Buffer is a global variable, usually it'll be zero initialized anyway.

always tired

@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.

always tired

@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{};'

always tired

@alter_kaker @riley Yes it's complicated

always tired

@alter_kaker @riley I've been into that mess posing as a programming language for so many years

always tired

@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.

Yeshaya Lazarevich

@project1enigma
I have no idea what compiler this is using.
@riley

Riley S. Faelan

@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. Faelan

@alter_kaker I seem to have missed it, and the webpage expired.

Riley S. Faelan

@alter_kaker constexpr has 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.

@project1enigma

always tired

@riley @alter_kaker IIRC one more C like way to make a constant without the preprocessor is an enum member...

Riley S. Faelan

@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.

@alter_kaker

Yeshaya Lazarevich

@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. Faelan

@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?

@project1enigma