 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 : Saving Variables for basic logging etc.
Page 1 of 2   |
|||||
| Author | Message | ||||
| Phil23 Guru  Joined: 27/03/2016 Location: AustraliaPosts: 1667 |
This was a limitation I was aware of, but was a midnight plan for short a bit of quick recording. (Probably over 7,000 writes in hindsight if I'd let it run a while). I had previously wondered how useful the AT24C32 found on most DS3231 RTC modules is. I know it's not a lot of memory space, but it does have a very high write cycle life. What is the opinion of the Experts on using this memory for simple forms of data logging, considering many project already use an RTC module. Does a cFunction to make this possible sound like a useful addition to the list of MM cFunctions. Presume it could be something basic like:- [Code] RTCVAR SAVE var [, var]… or RTCVAR RESTORE or RTCVAR CLEAR [/code] I know it's only 4k, but for given situations that is a huge amount, I'm not thinking thousands of lines of logged data here, just 10, 20 variables etc. It's something way out of my league, but those who routinely write these functions will know if it's bit of coffee break code or something way more major to implement that the effort is worth. I know Peter M has written something that way exceeds this suggestion in capabilities, but for application requiring something much more basic, and without an additional chip (presuming an RTC is present), does this idea have merit for some very basic logging. Not thinking of file based logging, just variables. Maybe at a real stretch possibly saving & restoring Arrays. Interested in hearing comments. Thanks Phil |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Hi Phil, I can tell you from personal experience, this is a great way to go. It is twice the size of what var save can do (28 pinner) and works EXTREMELY well. Give it a try, and bonus, you get a RTC also for a couple of bucks and you don't have to worry about wearing out your pic32's flash. Try it, you'll like it! Do a search on this forum, you'll find some good info to be able to use it. I'm not at my setup so I can't share code right now. Sent from my iPhone 6 Jim |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1667 |
Interesting, Have been reading thru the 2 related threads, this one and this one. What I'm not quite clear on is how do you choose what address to write to & read from? Also interested to hear what the thoughts are on doing it with a cFunction that works like:- [Code] RTCVAR SAVE var [, var]... and RTCVAR RESTORE or maybe RTCVAR RESTORE var [,var]... and maybe RTCVAR CLEAR [/code] Cheers Phil. |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1667 |
Peter M? You'd understand what's really involved in a function like this. Does this sound like a useful addition to the libraries? There must be plenty on situations where users want to save a hand full of variables that they need recall at a later date, or restore on reboot. Does using the AT24C32 on the RTC sound like a good way to go about it, or are there other better equally as simple options to use? What would be your suggestion for something basic, like in my case saving about 8 maximum & minimum temperatures from the last 24 hours, and is not lost in power outages or reboots? Thanks Phil. |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9642 |
Have you considered matherp's Cfunctions for his SPI logging here? It is very easy to get working, and involves little effort from your program to make it work. One of those SPI memory chips will have MORE then enough room for logging, and will retain the data when power is turned off. The 1MB SPI IC's are cheap as chips. Unless you want to do page-writing stuff like I was pestering matherp about on that thread, you can safely stop reading one you hit the end of page 3 of the thread. Smoke makes things work. When the smoke gets out, it stops! |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2948 |
 |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9642 |
Cheap as POTATO chips, I probably should have said.....  Smoke makes things work. When the smoke gets out, it stops! |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1667 |
Yes looked at that, but thought all the functions & extra chip is an over kill to just record a few dozen variables without wearing out the PIC's flash. Will go & look over those first pages again though. If an RTC is present why not make it's storage usable. Particularly on an MX170. As far as any serious logging is concerned, my requirement for that would simply lead to the decision to use a MicroMite Plus, along with it's other benefits. Already have 3 Snad PICs & an Explorer 64 sitting here, yet to be touched, & from what I understand, logging should native to the Basic in them. The 5.2 Beta has only destine to get better. Simply using VAR SAVERESTORE would simple suffice for these few dozen variables with the 170's if it didn't wear out the flash, so RTCVAR SAVE/RESTORE sounds like a simple & code parallel solution. Cheers. Phil. |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1667 |
Will add, I'm thinking of basic users here, people not up on advanced coding that just want a simple command to record a few things to display , or recall later. Just wanting to be able to have a save/restore option. |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9642 |
Fair comment. The problem with any external memory to store MMBASIC variables, is in how you go about saving them. Also just about all I2C or SPI memory is 8-bit, so any one address cannot store any number larger then 255. The memory may use two-byte word addressing, but the actual data store at any memory array address is still only 8-bit. If you had lots of variables, and some were large integer variables like 462735624 or something, that would have to be split up into blocks of 255 in some formulaic way before being written to the memory - and re-combined back into the appropriate variable when you read the data back as part of a restore. ...not easy... That is not to say it can't be done, but it does become really tricky if you have any variable at all with a value greater then 255 - pretty easy to do with the 32-bit MM device! 
Standard ASCII or other 8-bit data is dead easy, but large MMBASIC variables are something you need to consider if you are using any in your program. VAR SAVE, on the other hand, will take whatever you have and save it. Even if that variable is a large integer, so VAR SAVE and VAR RESTORE are extremely useful commands - so long as you don't overuse them. Smoke makes things work. When the smoke gets out, it stops! |
||||
twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1629 |
Hi Grogster, that's not completely correct (sorry!  ).
With my functions you can easily write and read floats. eeSaveF : writes a 32 bit floatinpoint number
' eeSaveF4: writes a 32 bit floatinpoint number ' at EEPROM addresses divisible by 4 ' (faster then eeSaveF) ' eeLoadF : reads a 32 bit floatinpoint number ' back from EEPROM using PEEK and POKE ' needs eeWriteB and eeReadB Even 64 bit integers should not be a problem (using peek(VAR x,y) and poke VAR ...). IMHO a AT24C32 can be helpful in many cases. BTW. Peters solution for SPI EEPROMS (W25QXX) is fantastic! 
Regards Michael causality ≠correlation ≠coincidence |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
in any design that i was going to 'release into the wild', i would be inclined to avoid writing to the PIC32's onboard flash like the plague! quite simply, while writing to onboard flash the device is in a vulnerable/fragile state. the one exception is calibration data that is written once when setting up, or only once in a blue moon. geoff: i assume that when VAR SAVE and non-volatile OPTION commands are avoided in a program, nothing else in micromite basic will cause a write to the onboard flash? would a custom function that operates like VAR SAVE var [, var]... be possible? ie, can a custom function take a vairable number of parameters? or would it be possible for user code to hook into the existing VAR commands and redirect flash read/writes to an external I2C device, a bit like a device driver? cheers, rob :-) |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9642 |
I stand corrected.
Nice one. 
I had not noticed that detail in your thread. The members can please ignore what I wrote above. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1667 |
I think the point being missed here is the "People" factor. I'm sure I can get any of the alternate solutions working once I get my head a round a few things like the addressing, page boundaries & other terms I'm not quite clear on. I'm thinking about the solution from point of view outside my own requirements though. Basic first time users. I've shown my backpack with a few items attached to 4 people now, all who I know can instantly find a use, and their own pet plan. (One now has chips). All hands on people, very competent in their field. They can understand the simple connections; Things like variables are Ok with them; Basic logic of IF & THEN commands makes sense; They don't have a lot of trouble with how inputs & output work at the basic level; Subroutines, starts to get a slightly vague look from a few, but not a complete blank; They totally get the fact that a little battery powered clock is plugged in; Something as simple as SAVEVAR, READVAR & CLEARVAR they would easily understand too; Saving simple variables happens all the time in every day life; Be it a builder, electrician, mechanic, plumber, they all save data every day. The media ranges from a scrap of paper or pocket notebook, to digital mediums, but all in all it's just saving data. And, the quickest & simplest method is generally used. This is not intended as a criticism of anyone or their suggestions, There is a general issue with some of the thinking in here; Everybody here, including myself already has background in these areas, and generally very solid knowledge in many areas. But many new & potential users don't have any of that. I'd almost go as far as saying a SAVE type command is as important as a PRINT command to new users. And for new & potential users, a Real Time Clock is probably one of the first devices added; even if just on the basis that almost everything has a clock these days. I could go on & on, but main thoughts are for other potential users. Cheers Phil. |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Hi Phil23 I quickly read your post and kind of agree with a few points. When the uMite first came out as beta, one of the first things that kept me excited was being able to interface a keypad and an lcd display. Back then, that was not a built in function of mmbasic, but some of the intelligent folks on this forum used what was available and wrote code to make things happen. These abilities became part of mmbasic over time, ie, keypad, lcd, rtc, temp, etc... If I were to venture a guess, a higher percentage of users use the ds3231 rtc when implementing an rtc in their uMite project. Since beta days, I've been using these after getting too much drift with the 1307. This is now my only module I use for accuracy and price. Works great and mmbasic's built in functions were added by Geoff due to their popularity and usefulness. I think that it would be great to have a simple built in function for using the onboard I2C 4k eeprom that comes with most DS3231 RTC modules for logging or other var save type operations and I think it would fit in great with the other "built in" functions of mmbasic, especially for the 28 pin 170 type setups a lot of people start with. I know we can build code to make this happen also, and I currently do that. But I have to agree, following built in coolness like temp, keypad, rtc, ir, lcd, encoder, servo, etc... this would be a great mmbasic "function" for the 170 for simple saving stuff using the rtc module that comes with 4k worth of eeprom for a couple of bucks. A great idea, that more than one user can benefit from. If not, then because of Geoff's efforts and people on the forum, it still works great and is just a few lines of code to make work. Win Win either way. Just for the record, this is the most I have ever typed on an iphone. Can't wait to get back to a real keyboard!!!! |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1667 |
Typing that much on a keyboard with a bandaged up left index finger was a challenge too; but have had a whole week of experience now.... A similar topic & one of my previous requests was for the enhancement of TEMPR, to read multiple sensors. I considered that of value internally in MMbasic. I was wrong. It can already be done & very easily, AND, it's really not something a first timer totally needs. It all works now, just 12 lines of code in a function to process the serial numbers of the sensors I need to read. But, Saving simple stuff is much more a grass roots beginners thing, that's why I tried to draw the notepad or piece of paper analogy. Cheers |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9642 |
Perhaps matherp could write EEPROM SAVE and EEPROM READ Csubs, which would save all MM variables to an I2C or SPI memory chip dedicated to the task? I don't know how practical or possible that is, but..... Smoke makes things work. When the smoke gets out, it stops! |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1667 |
Other side benefit I see for beginners & basic apps is that data would not be lost between reboots & programming updates. Users starting out are bound to be sending their programs over & over again and losing information the code has acquired. Seeing a device acquire information is a highlight for new users, I know I've been logging things for years & there's always a mental high in seeing the information you've been looking for. Losing that information is always disappointing. If something like EEWRITE or WRITERTC did ultimately become internal to MMbasic, I'm sure there would be the possibility of setting whether the EEPRom data was erased or not. And I should add, that from a simplicity point of view for simple task, the thought of just going ahead with using VAR SAVE for saving a few variables half hourly will no doubt enter a lot of new users minds. Based on the simple theory that they could just replace the chip every 12 months before the flash wears out. Reality would dictate that this really wouldn't happen, and ultimately it would fail. Not at all suggesting I'd use or recommend that approach. Cheers |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1667 |
On what already exist internally in MMbasic, I've always been aware that RTC SETREG & RTC GETREG already exist, but have yet to see any examples of their usage, and the manual tends to suggest they are more related to manipulation of the clock. Am I right in reading that this writes & reads to & from the DS3231 & not the AT24C32. In any case would the already existence of this code in the firmware mean that only minor enhancement would be required to extend the capabilities to read & write to the eeprom? Cheers. PS. Just on the 4k sizing limit, I earlier browsed thru my old OA2 & OA3 data directories; Some might remember SPI's Open Access from the 1980's. The directories contained quite a few data file ranging from 1k to 4k in size. |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3303 |
Yes, you are correct. As a general statement, it is impossible to make any programming environment do every high level function that everyone might want. There are just too many functions and everyone's requirements will be different. This might sound obvious but you need to write a program to meet your particular needs. On the AT24C32. There are many different flash chips on the market and that makes it hard (if not impossible) to write a universal driver. PeterM has done a great job of writing a driver for one of the more popular chips and using that will get your job done much faster than waiting for a driver for a non supported chip. Geoff Geoff Graham - http://geoffg.net |
||||
| Page 1 of 2 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
