g2 icon indicating copy to clipboard operation
g2 copied to clipboard

Integration of an external memory interface for coordinate offsets

Open AVRsteffen opened this issue 7 years ago • 6 comments

I miss that after a reboot the controller forgets the offsets of the different coordinate systems. That is because the SAM3 has no internal EEPROM. It has often been discussed whether you need it or not. I think so, you need it! However, an external EEPROM has a limited number of write cycles. Now I thought of a FRAM like the FM25CL64 from RAMTRON.

You can write it as often as you like and its memory contents are preserved after removing the operating voltage.

In addition, the write speed is many times higher than with an EEPROM.

His writing interface is SPI. It is used like an SPI EEPROM interface. Only without wait states. Full 4MHz write rate.

The FRAM FM25CL64 is for 3V3 operating voltage.

Now my question: how can one implement the SPI interface for it and where can one find the whole setting variables deposited in the tinyG2 firmware.

Who can implement something like that?

The version to make it about Chillipepper I find unsuitable.

AVRsteffen avatar Feb 24 '18 10:02 AVRsteffen

That sounds like an interesting idea. Using SPI to save info (that can't be compiled in) persistently "across sessions". It might be the kind of thing needing to get done in the motate layer, which is kind of like an abstraction layer for g2.

The version to make it about Chillipepper I find unsuitable.

That bit I'm not understanding. Um... any chance of trying to describe that, but using different words ? :confused:

justinclift avatar Apr 11 '18 18:04 justinclift

Okay, I try.. With Chillipepper you can save your settings and upload if you start your connection. But I am not prefer to use this web based program.

I prefer more to use a persistent memory. But I'm realy not fit in C++ I think Motate layer is only to discriped I/O configurations.

Sorry for my bad english

AVRsteffen avatar Apr 11 '18 19:04 AVRsteffen

It's ok. I understand now. :smile:

Personally, I agree with you. It would be really useful to have just a single firmware to upload, + each machine could store its own settings somewhere persistent.

Although things don't work that way now, as you mention it would be useful to get it working .

Just as an idea... is it possible for you to ask the creator of the G-Code sender that you use, if they could store the settings and automatically send them? If they add that feature, that could make things easier for you "for now" at least. :smile:

justinclift avatar Apr 11 '18 19:04 justinclift

This is how Chilipeppr does things right now. On connect it sets up everything. I think this is how cncjs works also.

ril3y avatar Apr 11 '18 19:04 ril3y

The approach discussed in #278 sounds like it might be useful here too.

justinclift avatar Apr 12 '18 21:04 justinclift

This functionality is long overdue.

I don't want to use chilipeppr because it's web-based and the site may be unreachable for any reason while using it. I am planning to use UGS. Persisting settings should be done on the firmware so the function is not dependent on the client. Arduino Due supports writing on flash (within limitations). Grbl does it on the UNO.

norru avatar Aug 22 '19 07:08 norru