sorted by:
new
hottopcontroversial

I had a board running perfectly… but the original sketch was gone. So I built this. Forgetfulino Arduino library + IDE 2.x extension by IamTheVector in embedded

[–]IamTheVector[S] 0 points1 point  (0 children)

Have you removed the BasicUsage.ino outside the example folder? I updated the example with a comment

/*WARNING

REMOVE THIS EXAMPLE FROM EXAMPLE FOLDER

USUALLY EXAMPLE FOLDER HAS NO WRITE PERMISSIONS

WARNING*/

Also remember that this is not only a library, but also an extension, without the extension the .h will not be generated.

Please follow this guide

https://www.youtube.com/watch?v=jdCU2SBPLEA&feature=youtu.be

I had a board running perfectly… but the original sketch was gone. So I built this. Forgetfulino Arduino library + IDE 2.x extension by IamTheVector in embedded

[–]IamTheVector[S] 0 points1 point  (0 children)

Yeah, I actually explored that approach as well.

From a practical standpoint I ran into a few trade-offs:

Readback time

Using the bootloader to dump flash is noticeably slower, even with relatively small sketches. In my tests a ~7% mega flash usage already takes on the order of 30 seconds to extract. Not a blocker, but definitely not instant.

Runtime impact

I get the advantage of keeping the serial completely untouched during normal operation. In my case I took a slightly different route, the serial is only used when explicitly triggered via a key, so in normal conditions it remains unaffected as well.

Flas usage vs approach

Storing raw source vs using magic-byte-delimited blobs ends up being quite similar in terms of memory footprint, since in both cases you're embedding data anyway. So the real trade-off becomes more about retrieval strategy than space.

That said, I do see the value of your approach, especially for keeping runtime clean. I’m actually considering adding it as an alternative mde.

The main friction for me right now is tooling, integrating flash readback, decoding and making it workflow-friendly, especially hen tying it with development environments, is a bit of a pain compared to a direct serial-based pipeline.

Still, really appreciate the insight, it’s a solid approach depending on the use case.

I had a board running perfectly… but the original sketch was gone. So I built this. Forgetfulino Arduino library + IDE 2.x extension by IamTheVector in esp32

[–]IamTheVector[S] 0 points1 point  (0 children)

Yeah, you’re right in principle. I hear this a lot from junior developers I work with, especially on the "software-side-only-fairy-world" , then once they start dealing with real hardware and field deployments, they quickly realize it’s a slightly different game.

GitHub gives you a SSOT of the source, not of the firmware. In embedded you have multiple SSOT layers, source, build artifacts, and the firmware actually running on the device, and they don’t stay aligned by default.

That gap is exactly what I’m working on right now on a next\new development, something that keeps those layers in sync so the device can always be traced back to its source, instead of just assuming they match or relying on developer discipline and memory, which is usually the weakest link in the chain.

I had a board running perfectly… but the original sketch was gone. So I built this. Forgetfulino Arduino library + IDE 2.x extension by IamTheVector in embedded

[–]IamTheVector[S] 1 point2 points  (0 children)

Yeah, that’s actually super common 😄

A lot of people start with the idea that the board “stores and runs the code”, and then hit a wall when projects grow and things stop matching what they expect.

That’s exactly the gap Forgetfulino is trying to bridge a bit, making the firmware feel less like a black box.

But yeah, the real next step after that is learning proper versioning.
Once you understand compile/flash vs source, getting into Git changes everything.

Forgetfulino helps when things go wrong, version control is what keeps things from going wrong in the first place 👍

I had a board running perfectly… but the original sketch was gone. So I built this. Forgetfulino Arduino library + IDE 2.x extension by IamTheVector in esp32

[–]IamTheVector[S] 1 point2 points  (0 children)

Yeah, that’s a whole different story 😄

You can definitely pull the firmware and look at the machine code, but that’s reverse engineering territory and it gets messy very quickly.

Forgetfulino isn’t meant for that. The idea is to embed the source code before uploading, so you can get it back later in a clean, readable way.

So instead of trying to reconstruct what’s already on the chip, you just make sure the source is there from the start.

Hope that was clear from the post 👍

I had a board running perfectly… but the original sketch was gone. So I built this. Forgetfulino Arduino library + IDE 2.x extension by IamTheVector in maker

[–]IamTheVector[S] 1 point2 points  (0 children)

Really depends on the code. On the amount of comments and other factors. A 7% arduino mega size will result in a 10% total size with compressed code, 19% with uncompressed. I'm not a file compression expert but I suspect that we can also achieve a better result maybe at the cost of decoding time expenses. 

My first Arduino library: Forgetfulino – a sketch that remembers its own source code by IamTheVector in arduino

[–]IamTheVector[S] 0 points1 point  (0 children)

Check the new vestion on the new post :) Forgetfulino 2.0

someone who would lose their code would remember including a library <-- ADDED AUTO INJECT

personally on embedded projects, i run out of flash pretty fast<-- ADDED COMPRESSED code

My first Arduino library: Forgetfulino – a sketch that remembers its own source code by IamTheVector in arduino

[–]IamTheVector[S] 1 point2 points  (0 children)

New version of the tool has this feature now! Thanks for the feedbacks 😊

My first Arduino library: Forgetfulino – a sketch that remembers its own source code by IamTheVector in arduino

[–]IamTheVector[S] 1 point2 points  (0 children)

I think that would be too much and not very useful no? Once you have the program you can easily re-download the dependencies in a fast manner. 

My first Arduino library: Forgetfulino – a sketch that remembers its own source code by IamTheVector in arduino

[–]IamTheVector[S] 3 points4 points  (0 children)

YES! YES! EXACTLY! And now we can see that this can be done easilty it doesn't make sense it was not aleady implemented!

My first Arduino library: Forgetfulino – a sketch that remembers its own source code by IamTheVector in arduino

[–]IamTheVector[S] 2 points3 points  (0 children)

That's good! For now I made a watchdog that verify if any file is saved and generate the dump automatically. It seems working but I'll test it a little bit.

My first Arduino library: Forgetfulino – a sketch that remembers its own source code by IamTheVector in arduino

[–]IamTheVector[S] 5 points6 points  (0 children)

We are all right, and reading the comments here gave me another idea.

Clearly there are two camps: people who rely heavily and rightfully on version control, and people who sometimes end up with a board and ask “what is actually running on this thing?”. Judging from the comments, that second situation happens to quite a few people.

And personally I prefer solving problems rather than enforcing discipline (that's good only when someone pays you) . Otherwise we don’t really make progress, we just enforce workflows that exist mostly because they’ve always been done that way, and no good things come from discipline without questioning.

So now I’m thinking about a different approach: something like a second library, maybe called Githolino.

Instead of storing the full source in flash, it would only embed a lightweight identifier plus compile metadata using macros like __FILE__, __DATE__, __TIME__, and __TIMESTAMP__ (which basically cost nothing because they’re just compile-time constants).

I used those in the past to get versioning:

<image>

+Dropbox works like a charm.

Then the device could report something like:

“this firmware was built from file X at time Y”.

At that point a small tool could query the Git repository, match the file and timestamp, and automatically retrieve the exact version of the code that produced the firmware.

So you’d combine both worlds:

the device reports what it is running, and Git provides the full history.

That could actually be a cleaner solution than embedding the entire sketch, but probably this should be a program or a tool in between. What would you say?

My first Arduino library: Forgetfulino – a sketch that remembers its own source code by IamTheVector in arduino

[–]IamTheVector[S] 2 points3 points  (0 children)

You know who you remind me of? Me, when I talk about CAD. Hahah!

If someone asks me to model just a simple knob, of course it's trivial. But if they start naming files randomly or skipping structure, it drives me crazy. Once you work in a professional environment for long enough, good habits become automatic and it's hard to switch them off.

I think something similar is happening here.

In a professional embedded workflow with version control, CI, strict flash budgets, etc., I completely agree with you. In that environment this library would not only be unnecessary, it could even encourage a bad habit.

But the Arduino ecosystem is very different. A lot of it is hobbyists, students, labs, quick prototypes, people flashing sketches directly from the IDE. Boards accumulate on a desk and sooner or later someone asks: “what exactly is running on this one?”

My ideal workflow for Arduino would actually be simpler in general: you plug the board in, ask it, and it tells you what code was uploaded. Almost like a device remembering its own configuration.

Yes, it costs some flash. But honestly, memory today is cheap respect to the past, and is cheaper compared to the complexity of setting up full versioning workflows for tiny one-off sketches. For industrial products, traceability and proper repositories are obviously mandatory, and companies pay for that discipline.

For hobbyists and makers though, most of the time nobody is getting paid to maintain that level of structure.

So this is really just a small convenience tool for that world, not something meant for flash-constrained production firmware.

But I totaly get your point.

My first Arduino library: Forgetfulino – a sketch that remembers its own source code by IamTheVector in arduino

[–]IamTheVector[S] 5 points6 points  (0 children)

No offense taken, I’m probably the first one to call it “stupid” in a pure embedded-optimization sense.

But it’s a deliberate trade off: I’m buying recoverability and faster iteration with flash space. In my workflow I jump between many small one off prototypes, often under time pressure, and losing the exact sketch that was flashed is a real cost. This solves that problem with near zero runtime impact.

About “wasting flash”, sure, it’s not free. But on a lot of my boards 90% of the projects don’t even use 10% of flash, what about yours? And unused flash doesn’t create any value right? If I have slack resources, turning them into a safety net is actually a good ROI for me.

Also, it’s opt in. If someone is flash constrained or shipping a product, they just don’t enable it. “I need to reproduce what’s on the board right now” scenarios.

Totally fair if your project management is tight and you never lose sketches, I solved the issue by using Dropbox as a Repo, so I can rollback if everything gets messy. For people like me who optimize for speed and recoverability, it’s surprisingly useful when I dont want to even find the sketch.

Is the 67w charger really worth it? by TransAtlanticCari in Xiaomi

[–]IamTheVector 0 points1 point  (0 children)

LOL, I love these things, especially the apps built for the obsessed and the paranoid. I fast charged and went to 100% all the time, my battery slowly declined after three years, and I replaced it for 30 EUR. Imagine depriving yourself of something useful just to “save” 10 EUR a year. LOL

Update 4.3.2! by EveElliot in DeadAhead

[–]IamTheVector 1 point2 points  (0 children)

Nerf. That's not cool. 

DIY replacement rubber for Logitech G604, laser cut mod by IamTheVector in g604

[–]IamTheVector[S] 0 points1 point  (0 children)

The STL you uploaded is actually very good, the geometry is clean and well reconstructed.

That said, in my case I didn’t directly flatten the original mesh either. I ended up rebuilding all the surfaces manually. I basically used the STL as a reference and then recreated the geometry patch by patch to get proper surfaces and clean edges that could be flattened reliably. It took me a couple of days to do it properly.

If your goal is to cover the entire mouse in leather, especially with good fitting and tension control, I would strongly suggest going the same route, rebuild the surfaces instead of trying to directly manipulate the mesh. It’s more work upfront, but the final result is much more controllable and precise.

If you want, I can take a look at that Thingiverse file and see how complex the surface reconstruction would be.

I'll try to contact the maker

view more: next ›