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 : Help for data logging with MM2 and SD card
Page 2 of 2 | |||||
Author | Message | ||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 3420 |
Dear Peter, I would like to appologize if by any text I wrote I offended you. It is absolutely amazing what Geoff and You have created. And the ongoing support that both are giving, so many years afterwards. The SDCARD libraries where from 2015/2016 and still you contribute as if it where new developments. So my remark about them not being robust was inappropriate. Excuses. Similar the fact that I did not understand that there was only 1 set of libraries, and the commands where result of creating aliases. I hope you continue to contribute to MMbasic. Regards, Volhout PicomiteVGA PETSCII ROBOTS |
||||
Frank N. Furter Guru Joined: 28/05/2012 Location: GermanyPosts: 812 |
Hi Peter, the behaviour has changed/improved significantly with your new driver!! It now takes most several seconds (10-20 seconds) until the error message "Error: Not Ready" or "Error: Disk Error" appears. But now it works much more often very well! Also my 16GB INTENSO is working now - this had not worked at all before!!! ...but it's not as stable - after a longer disconnection, I couldn't access it again... If it does not work, the only thing that helps is to disconnect the power supply and wait several seconds. Very rarely that a "CPU RESTART" works. If it works, it works again even after a short disconnection of the power supply or after a "CPU RESTART". Somehow there seem to be problems with the powerup of the card. Do you access the card immediately after starting the Micromite or only when a file is opened? Thanks for your new driver - it works much better now! Frank Update: If it works I can interrupt it with CTRL+C, swap the two cards and start it again with RUN - it still works then! I use a "#" as end marker and append the new data at the end. This is my program: Pause 1000 Option AUTORUN ON Option EXPLICIT Option default integer ' Constants defining SD card calls Const fileopen=1 Const readfile=2 Const writefile=3 Const opendir=4 Const readdir=5 'Micromite - SD Card '=================== 'Pin2 - SS 'Pin3 - MOSI 'Pin14 - MISO 'Pin25 - SCK 'SDCard fileopen,filename$ SDCard fileopen,"Timelog.csv" Dim DTA$ Dim filepos Integer Dim Zaehler Integer Zaehler=-1 Do Zaehler=Zaehler+1 Print Zaehler SDcard readfile,DTA$,Zaehler,1,filepos Print Dta$ Loop Until DTA$="#" filepos=Zaehler Print "filepos=",filepos 'Mainprog Do RTC GETTIME Dta$=Date$+";"+Time$+";test"+Chr$(13)+"#" Print Dta$ Pause 500 SDcard writefile,DTA$,filepos,Len(DTA$) Print"data written" ' maintain the file pointer - this must be done in the Basic program filepos=filepos+Len(DTA$)-1 Pause 1000 Loop Edited 2020-01-16 23:26 by Frank N. Furter |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8516 |
No problem - I probably over-reacted anyway. Perhaps if I explain a bit about CFunctions. When you call a CFunction from MMBasic it gets passed a series of memory addresses, one for each parameter, nothing else. There is nothing it can do to establish what is actually being passed. It only knows what it expects. Say you pass me an integer and I'm expecting a string in which I'm going to return some data. I take the address and start writing the data from that address. What has now happened is that I've overwritten a bit of the MMBasic variable table with my data and there is now a very high probablity that MMBasic is going to crash. It is therefore essential with CFunctions that they are used precisely as intended and with precisely the type of variable expected. The SDcard CFunction is more complex than most. For example to read data you pass it a string for reads < 256 characters and an integer array for reads >=256 character. Moreover, the use of the parameters differs between the various modes 0-7. So lots of scope to crash things but if you pass the correct parameters in the correct way then I believe it works as expected. If not, it is a bug which I'll try and fix but without a specific sequence of events that can be replicated I have no way of knowing if it is a bug or operator error |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8516 |
Only after a file is opened. Did you try the 2R2 Resistor in the power to the SDcard? (or try 4R7). It does sound like a power issue particularly given that the 220uF cap helped. I've never needed anything that big but always use a 10uF ceramic or tantalum with a 100nF ceramic fed through a resistor. Do you have the pullup resistors installed? Is so try without. You can solder 1206 ceramic caps directly across the power pins on the SDcard module. Edited 2020-01-17 00:35 by matherp |
||||
Frank N. Furter Guru Joined: 28/05/2012 Location: GermanyPosts: 812 |
Hi Peter, I added a 10µF 0603 ceramic capacitor directly between the power pins on the card board and 10K pullups on SCK, MOSI and MISO before you updated your driver. Now I tried 3x 12R parallel in the powerline of the SD card - then I had no access at all. I added a 10K pullup on the CS line - no change. The following powerup sequencing now works: - First I connected my powersupply or USB-power - After some seconds I connected my board (with RTC and SD card holder WITHOUT SD card inserted) - Again after a few seconds (when the program has started to run and produces the first error messages) I insert the SD card into the holder => then it works!!! This works reproducibly, but only with my HAMA card, not with the INTENSO!!! If the card is inserted from the beginning or the board is connected to the power supply from the beginning, nothing works! Not even after removing/inserting the SD card or hard resetting the controller! I have changed the program a little bit so that it does not crash every time an error occurs: Pause 1000 Option AUTORUN ON Option EXPLICIT Option default integer ' Constants defining SD card calls Const fileopen=1 Const readfile=2 Const writefile=3 Const opendir=4 Const readdir=5 'Micromite - SD Card '=================== 'Pin2 - SS 'Pin3 - MOSI 'Pin14 - MISO 'Pin25 - SCK 'SDCard fileopen,filename$ On ERROR SKIP 1 SDCard fileopen,"Timelog.csv" If MM.Errno<>0 Then Print MM.ErrMsg$ Print"=> CPU RESTART" CPU RESTART EndIf Dim DTA$ Dim filepos Integer Dim Zaehler Integer Zaehler=-1 Do Zaehler=Zaehler+1 Print Zaehler On ERROR SKIP 1 SDcard readfile,DTA$,Zaehler,1,filepos If MM.Errno<>0 Then Print"CPU RESTART" CPU RESTART EndIf Print Dta$ Loop Until DTA$="#" filepos=Zaehler Print "filepos=",filepos 'Mainprog Do RTC GETTIME Dta$=Date$+";"+Time$+";test"+Chr$(13)+"#" Print Dta$ Pause 500 On ERROR SKIP 1 SDcard writefile,DTA$,filepos,Len(DTA$) If MM.Errno<>0 Then Print"CPU RESTART" CPU RESTART EndIf Print"data written" ' maintain the file pointer - this must be done in the Basic program filepos=filepos+Len(DTA$)-1 Pause 1000 Loop Frank |
||||
Frank N. Furter Guru Joined: 28/05/2012 Location: GermanyPosts: 812 |
Peter, you are right!!! I have now tried a third, better power supply - now everything works perfectly with both cards! Thank you very, very much for your effort!!! Frank |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 3420 |
Hi Frank, I can also confirm it works. I have one suggestion to make. In case there is a power interrupt, and a restart, it is possible the interrupt corrupts a flash card write. In that case the old "#" is overwritten, and the new '#" is not written yet. In that case your algorythm will search to the end of the file without finding a '#'. You could prepare the empty file full of '#' so it would find one at the earliest non-written position. Or you could change your search algorythm to include finding the charactervalue that is used in the empty file. (did not check, is it full of spaces ? or full of ???? It is filled with 98k of ???? What data are you writing to EEPROM? If it can be managed into a fixed length, the '#' can only be at fixed positions. That would improve the search speed for '#'. @ Peter, Am I correct to assume you are not touching the FAT32 FAT (file allocation table), only reading it ? Is the decision to not touch the FAT the reason that we need to use existing files, and we cannot change the file size ? Is this limitation caused by the fact that the Cfunction must interface with MMBasic, and that there is no variable type you can use (a struct) if not provided by MMbasic ? Just trying to understand where the limitations come from. There is a sdfatlib from william greiman (arduino uses it) that supports adding files and removing, but if you cannot interface with MMbasic, it makes no use to look at it. Volhout PicomiteVGA PETSCII ROBOTS |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8516 |
The MM+ (and all the Armmites) uses FatFS as the SDcard manager. This is pretty much the industry standard and, for example, ST use within their own code. This is full function but is a lot of code. Chan, the author of FatFS, also provides a cut down version called PetitFS. This is what the CFunction uses. This is MUCH smaller precisely because it has removed the extensive code needed to update the FAT32 file system. If I implemented the full version it would 1: be very hard in a CFunction. 2: Use most of the MM2 memory making it unusable anyway. |
||||
zeitfest Guru Joined: 31/07/2019 Location: AustraliaPosts: 368 |
just in passing - Interesting Cornell uni SD card project running on Microstick II. At a guess it'd take too much flash+ram to use with other programs much. But, if anyone wants to type it in and try it - please post it !! |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8516 |
[grouch mode on] If that is the standard of a design project for a Masters at Cornell then they are giving degrees away. They are using (in 2017) a seriously out of date development environment which means the code can't be ported to any of the newer processors. Then they are re-inventing a wheel that has been invented so many times before that it is ridiculous. Assuming the code isn't plagiarised then all they have proved is that they can read a Microsoft spec and code a very small part of it. |
||||
Frank N. Furter Guru Joined: 28/05/2012 Location: GermanyPosts: 812 |
@Volhout: Thanks for your suggestion! I will fill the file with "#" in the future. Now I have a brand new INTENSO 32GB card here - it does not work either! ...main thing the 16GB cards run stable... Frank |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8516 |
Check it isn't formatted exFAT which isn't supported |
||||
CircuitGizmos Guru Joined: 08/09/2011 Location: United StatesPosts: 1421 |
This works differently than I anticipated. If I run this code: DIM s$ as string DIM bytesactual as integer s$="ABCDEFGHIJKLMNOP" SDcard 3,s$,0,16,bytesactual ' write SDcard 2,s$,0,50,bytesactual ' read PRINT s$ s$="123" SDcard 3,s$,0,3,bytesactual ' write SDcard 2,s$,0,50,bytesactual ' read PRINT s$ I get this output: ABCDEFGHIJKLMNOP 123 I expected: 123DEFGHIJKLMNOP The write function only works as an append. A sector's worth of data after the "123" is set to null. Am I misinterpreting something, or is write only an append to the end of the file? Micromites and Maximites! - Beginning Maximite |
||||
Page 2 of 2 |
Print this page |