Any chance of an API to access EEPROM in the ATSHA204?

There are 512 bytes of unused EEPROM in the ATSHA204 cryptographic chip. There is a further 88 bytes of EEPROM for device information and access control of each slot in the writable EEPROM. For more info see page 4 of the datasheet (http://www.atmel.com/Images/doc8740.pdf)

As there seems to be no way to persistently store data onboard across power loss in the imp itself, is there any chance of getting an API to utilize this otherwise wasted 512 bytes?

The 512 bytes aren’t wasted; there are some reserved bits in there that we use.

It’s very slow to read and write, but we will be offering an API to get to the unused pages at some point - no date yet I’m afraid. You can always store data on the server to persist across power cycles, see server.setpermanentvalues() on the devwiki.

Of course if the Imp wakes up from having lost power and there is no internet connection (say it is a toy and the batteries are dead), then there is no way to get access to the data at the server.

As much as we like to think we live in a world of persistant internet connections, the truth is that it is all to easy to not have a connection because of circumstance. For some applications this won’t matter, but for people building consumer electronics that are designed to also operate when/where there is no connection it is a real concern. And I personally wish more thought was put into this kind of situation.

All of this is to say: please enable access to EEPROM soon.

In the mean time, for those who have the board space/room in their BOM there are EEPROMs accessible via I2C.

Believe me, more thought than you’re aware of has been put into the features and implementation order.

For devices using the imp as their only processing, they’re unlikely to be using a removable imp - and the solder-down imp does not have an atsha at all. As you say, external storage works just fine with the imp if you need it right now and we have customers doing just that.

Hugo, thank you for your response. I am glad it is something that is being considered.

I would feel very wasteful adding another EEPROM part to a project that only needs a few bytes of persistent local storage :slight_smile:

This is going to become more important when you add shallow sleep. People will want a way to temporarily store data in a power-loss-friendly way between network communication periods.

I understand what you are saying Hugo, but external memory isn’t always feasible when it comes to board space and/the BOM. I was mildly surprised to find out there wasn’t some kind of app accessible EEPROM.

Believe me, more thought than you're aware of has been put into the features and implementation order.

I do believe you, nor do I think you are fools, and I very much want you to succeed. However as someone who is using the IMP I can only judge by what is real and public right now.

Nor do I have any idea what these upcoming features are — aside from gleaning them from the forum and tidbits in the wiki — and exactly no idea when they will be coming. It would be of enormous help if you could give a vague idea what features are coming, and equally vague idea of when. Right now all I have is that they will happen sooner or later.

I have a list of 4-5 projects that I would like to use the Imp in, but I cannot because I need some kind of local storage (and don’t have the board space for an external part), the network won’t always be available, and in one case because you don’t have a privacy policy.

Please communicate more, your last blog post was in Oct. Please publish some kind of roadmap and what quarter you think they might be coming (with all appropriate disclaimers). Because right now we have a somewhat disorganized wiki, and factoids gleaned from comments and tangential information in the wiki.

@dnova Upon further reflection, this thought occurred to me: I don’t know if the Imp is talking to the ATSHA204 over the 1 wire or I2C interface (the chip supports both) but if it is I2C then you might be able to read and write to the device directly.

The squirrel API might prevent you from doing this. In fact it really should, so you can’t overwrite the parts they are using. So tread carefully, but it would be interesting to know if it were possible.

That thought had occurred to me, but as far as I know, it is some kind of bit-banged 1-wire interface built into the firmware. The ATSHA on the April board, for example, has only 3 pins - Vcc, Gnd, and SDA. Without a clock signal I don’t think I2C works.

I did see some mention of an elegantly implemented 1-wire API in the future, but even if that were to occur, who knows what problem accessing the same chip from another pin could create.

A rough roadmap would be a VERY nice guideline to have.

We’re doing our best to try and juggle the demands of customers and available resources; I’m afraid that communication has been coming further down the list than actually getting the features in though!

When we have agents ready we’ll try to give a “state of the union” type update, with more info on what’s coming both on the imp side and on the server side. We’re about to push a significant website update today, I hope.

Note on the atsha - we use 1-wire (the SOT23 package is 1-wire only), but it’s not “Dallas 1-wire”, so we actually use a single pin bidirectional UART to talk to it. Reading a 32-byte page could be ~50ms+.

I genuinely hate to beg the question, but when do you think you will have agents done, so that you can have the aforementioned state of the union?

I understand the pressures and demands on your time of being in a startup — I have been in more than a few — but I do encourage you to build in updates and rough timelines into your schedule. Besides think of all the forum posts it would save :slight_smile:

And very interesting about the single pin UART.

Just so you know, the single-pin UART in question is one that Squirrel code does not have direct access to. When we do expose the spare pages of the ATSHA204 to Squirrel, it will be via a specific API (so that we can act as a gatekeeper and prevent any accidental trouble with the pages we use); you won’t have to issue the 1-wire commands yourself.

Peter