Rust and Arduino part 3

[cecton]

No description provided.

[wdullaer]

I like it :-)
It's cool to go from something simple to something more involved.

As a professional lisper, I still feel like the macro could be a function :P

[wdullaer]

Suggested change

	single address space.
	single address space. It's possible to use a single memory and divide it up into separate memory spaces for code and data.

That last sentence is my understanding of the distinction. Feel free to edit if I made a mistake there (my computer architecture knowledge is a bit rusty :P )

[cecton]

🤔 I'm really not sure. It might be wrong. I will ask

[wdullaer]

Can you ship the raw files separately and load them at runtime?
By calling include_bytes! you are embedding them into your program binary. When you invoke your program the OS will load all of it into memory, because it doesn't know where your various instructions are located inside of it.
The advantage is that you only have to ship one thing, the assets are literally part of the binary.

I suppose if you can put the assets somewhere on disk as separate files, and then load them one by one, you can avoid corrupting the stack (making sure they go out of scope so rust cleans them up and frees the memory).

[cecton]

I guess I need to work more on my wording XD

[cecton]

(Don't forget that there is no OS here: I have to use assembly if I want to access the flash memory)

There are only 2 memories: flash and RAM. The program is actually in flash so the include_bytes are fine it the compiler wouldn't put code that loads them on startup.

But even if I make a binary without it and add the assets at a specific address after the binary itself (but still inside the flash), then I would still need assembly code to actually load the data.

There are ways but they are all complicated and out-of-scope imo.

[wdullaer]

Ah, the fact that it is the compiler that loads the entire program somehow escaped me.
Loading the data without an OS would be more complicated for sure, having to rely on the raw chipset instructions / assembly.

Would you be able to get a raw pointer to the data if you used unsafe rust here (since you can control at which offset / memory location the frames are located)?
I guess this is still out of scope for the blog post, but the problem interests me :-)

[cecton]

This is fine! ^_^ It gives me ideas on how to improve this section which is the most important part of the post.

No using unsafe won't work. You can make pointer only to the SRAM, not to the flash memory (there are 2 address spaces). To read from the flash memory I would need to use asm!. But also building the binary would be a bit more complicated because I would need to add the image data somehow at the end of the code so it won't be loaded on startup

[cecton]

As a professional lisper, I still feel like the macro could be a function :P

It could be but it's not necessary and it doesn't make the code less readable. It's quite the contrary. If I make a function I will not only have to give the type of everything but also provide a ref mut to the data buffer and the i2c. I'm just being pragmatic and I have no hard feeling against macros.

On my development version I had a proper struct which hold the buffer. But I think it would have been too over-engineered for the sake of this tutorial/blog post.

[cecton]

(And yes I'm being so pragmatic that I even coded right into the example instead of making a new crate. Or maybe that's laziness 😁 Either way, I don't think I care much)

[wdullaer]

Nah, that's OK :-)
I can see how using functions makes the code a bit harder to read.
For an example like this it's nice that everything is in line and flow linearly.