Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
|
Forum Index : Microcontroller and PC projects : UNI/O EEPROM Driver
Page 1 of 3 | |||||
Author | Message | ||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
Attached is a CFunction for the UNI/O protocol. This protocol is used by Microchip for their 11XX series of EEPROMs. These are great little devices: - Only one I/O pin is required to communicate with them - Simple TO-92 or SOT-23 packages (they look like a transistor) - Capacity up to 2 KBytes - Cost just 28 cents in single quantities from Microchip - And best of all, up to a million writes per cell. The main downside with the UNI/O protocol is that it is very hard to implement in a microcontroller. It is complicated and the timing is extremely critical so this is why a CFunction is required. Using the CFunction is reasonably straight forward: status = UNIO(pin, cmd, addr, nbr, data) where pin is the I/O pin to use, cmd is the operation (eg, read/write/erase), addr is the location in the EEPROM, nbr is the number of bytes to read/write and data is the data (eg, variable or array). The function returns true for success or false for failure. The code for the CFunction and full description is in the attached pdf file: 2017-07-16_014800_UNIO.pdf With the one million writes per cell you can use this little device to frequently log readings like temperature and pressure without requiring an SD card or battery backed memory. At 28 cents it is a good solution. Geoff Geoff Graham - http://geoffg.net |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5923 |
You make it look easy to talk to those chips. Thanks, I will have to get a few to play with. Jim VK7JH MMedit MMBasic Help |
||||
astro1 Regular Member Joined: 26/06/2016 Location: AustraliaPosts: 51 |
Works great on a mm+100. |
||||
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9084 |
Very clever! I will have to get some of these with my next Microchip Direct order. EDIT: As with just about all EEPROM, these ones also have page boundaries, which in this device's case, is 16-bytes. Therefore, you should not attempt to write more then 16 bytes to this device in any one operation, assuming you start at the beginning of any one page. As with standard EEPROM chips, you can read as much as you like, you just need to be careful not to create page errors by writing across a page boundary. See the PDF for this device, page 12 - gray box on right. Cfunction PDF for this talks about writing 21 bytes - this would fail, as it would cross a page boundary even if you start writing from the first byte on any one page(because 21 bytes is bigger then the 16-byte page buffer). Something to be aware of, is all. EDIT: Unless the Cfunction takes care of that for us? Geoff? Smoke makes things work. When the smoke gets out, it stops! |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
This is MMBasic Graeme, everything is taken care of. I would not make a dumb mistake like that Page boundaries are automatically handled by the driver, you can write hundreds of bytes in one go without worrying about pages, write wait times, wakeup from sleep, ACKs, NACKs and all the other hassles of dealing with the chip. The driver will even automatically retry operations if they are disrupted by noise or timing errors Geoff Geoff Graham - http://geoffg.net |
||||
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9084 |
That's REALLY awesome. The standard I2C EEPROM's you still have to beware those boundaries - even in MMBASIC, but the fact you handle that inside the Cfunction makes this and those EEPROM's even more attractive. Quite keen to play with one or two of these now... Smoke makes things work. When the smoke gets out, it stops! |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1995 |
+1 I have 50 arriving tomoz with any luck |
||||
drkl Senior Member Joined: 18/10/2015 Location: HungaryPosts: 102 |
Helo, help me... where is my mistake, unio doesn't operate. MM44, MMBasic 5.4.04 UNIO C function is in the library chip: 11LC160 with filter resistor 'TEST 'WRITING THE STRING NAME$ WHICH WILL HAVE A MAXIMUM OF 30 CHARACTERS. DIM NAME$ AS STRING, STATUS AS INTEGER NAME$="THIS IS A STRING" STATUS=0 DO WHILE STATUS=0 STATUS = UNIO(23,03) LOOP ? STATUS STATUS = UNIO(23,02,0,31,NAME$) ? NAME$,"S=",STATUS NAME$="33" STATUS = UNIO(23,01,0,31,NAME$) ? NAME$,"S=",STATUS END endless loop.... drkl |
||||
drkl Senior Member Joined: 18/10/2015 Location: HungaryPosts: 102 |
Hello, For further work: Uploading memory with 0 or 1 and the reading is working, but not writing data. Where is the problem? drkl |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
Your test program worked fine for me. This is the result I got: > RUN 1 THIS IS A STRING S= 1 THIS IS A STRING S= 1 > So this is NOT a bug in the UNIO CFunction. Have you got the right chip (a 11AA160 not a 11AA161)? Is it connected correctly? I noticed that the PDF mangled the hex codes by inserting random newlines when I copied and pasted the text. In the future I will distribute CFunctions as a text file (ah well, it seemed like a good idea at the time). This is the UNIO CFunction as a text file: 2017-07-20_020429_UNIO.zip Try using this instead. Geoff Geoff Graham - http://geoffg.net |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5923 |
I can't see any difference between the file in the ZIP and copy and paste from the PDF. It will be a week or so before I have any chips to test with. Jim VK7JH MMedit MMBasic Help |
||||
drkl Senior Member Joined: 18/10/2015 Location: HungaryPosts: 102 |
Hi Geoffg, Using the new contents of the zip file, the problem remained. (erase/fill and read OK, writting is NOT! But: I use chip: 11LC160 with filter resistor (as you suggested) instead of 11AA160! It can be any difference between two chips? Studying the datasheet I can't see any difference. drkl |
||||
astro1 Regular Member Joined: 26/06/2016 Location: AustraliaPosts: 51 |
Hi Geoff, I'm using 11AA010T and it is reading fine on the MM with a status of 1 , but it is not writing, status is 0. Option explicit Dim integer data, status, i Dim string s$ Print "write file" Open "eprom" For input As #1 For i = 0 To 127 s$ = Input$(2, #1) data = Val("&H"+s$) status = unio(43, 02, i, 1, data) Print status, data Next i Close #1 Print "read eeprom" For i = 0 To 127 status = unio(43,01,i, 1, data) Print status, Hex$(data,2) Next i |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
Hi drkl/astro1, All that I can say is that the driver works perfectly for me. When I was developing it I did get a lot of errors which I put down to the rough breadboard test bed that I was using. But even with this the final driver worked well. I don't think that your problems are in the driver, it must be something environmental. Try a different power supply (say 5V), a decoupling cap close to the chip, a pullup resistor and make sure that the signal lead and ground are short. EDIT: It occurred to me that the test chips that I have are the 11AA161 (with the UNIO address of 1) and there could be something strange and different with yours that have a UNIO address of 0. Please try the attached version, this ignores the difference between the two and forces the address to zero. I don't think that it will make a difference but it is worth a test. 2017-07-22_081205_UNIO.zip Geoff Geoff Graham - http://geoffg.net |
||||
drkl Senior Member Joined: 18/10/2015 Location: HungaryPosts: 102 |
Hi Geoff, Again: filling the chip with 0 or 1 is OK. STATUS=1 The reading is ok, STATUS=1 The ROM content is all 0 or all 1 The writing is problem, STATUS=0 I try to use CPU 48, and i try to use 5V without success. Can the timing of the writing be inappropriate? drkl |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
The timing of both the read and write is very accurate (within 1%) - this was something that I found was necessary for reliable operation. I tested the driver from 30MHz to 48MHz on the MX170 but it was optimised for 40MHz and so it would be worthwhile trying it at 40MHz. Geoff Geoff Graham - http://geoffg.net |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5923 |
It might be worth trying different values for OPTION CLOCKTRIM depending on your room temperature. Jim VK7JH MMedit MMBasic Help |
||||
astro1 Regular Member Joined: 26/06/2016 Location: AustraliaPosts: 51 |
Hi Geoff, New code has 2 'End CFunction' lines (107/115), looks like a copy/paste issue? Reading ok, writing shows an error. astro1 |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
I don't know what is going on here, it should work for you, it works fine for me. OPTION CLOCKTRIM should not make a difference, the chip is sensitive to timing jitter, not the actual frequency. Have you tried my suggestions for reducing noise on the power and signal lines? Geoff Geoff Graham - http://geoffg.net |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5923 |
My 11AA160 TO-92 arrived today. Testing on a MX170 running 5.0404 Clear to all zeros works. Clearing to all FF works. Writing strings or numbers of any length fails. Reading any length works. I did notice that reading to a string variable, you end up with a 255 character string padded with zeros. You have to do a LEFT$() to tame it. I put a 0.01 capacitor across the supply pins close to the chip. I put the cro on and did some experimenting with different values of pull-up resistor. With no resistor, one direction goes from ~zero to a high of ~2.5V With a 10k pull-up it goes from ~0.5V to 3.3V That seems to agree with the data sheet. I tried a 100k resistor and got close to full voltage swing so will stay with that. Unfortunately, nothing gets the write data to work. I will try with a different micromite (Explore64) later. Jim VK7JH MMedit MMBasic Help |
||||
Page 1 of 3 |
Print this page |