SD card questions
TC
Posts: 1,019
Hello all,
I have a few questions about using a SD card.
I am currently using Kwabena's FAT16/32 driver. It is nice, but I am having a lot of trouble understand how to use it, and what methods I need. Also, it is a large object. Most of the stuff I would never use for my oven.
An idea I had for the profiles. But I don't how I would set up the prop to understand it, nor do I know how to save the profile on the SD card so the prop can use it. My idea is to just have parameters for each zone of a profile. To give you an example of what I am thinking, I will be referencing this general profile
Please let me know if you have any insight, concerns, or ideas.
Thanks
TC
I have a few questions about using a SD card.
- What SD object would you recommend?
- For my project (reflow oven), I am creating a menu. But it is taking A LOT of space. Is there a way to store the menu on the SD card, and only access it when the menu is needed?
- I want to store (and edit) reflow profiles on the SD card. And the prop will use that data to run the reflow profile. What are my options for doing this?
I am currently using Kwabena's FAT16/32 driver. It is nice, but I am having a lot of trouble understand how to use it, and what methods I need. Also, it is a large object. Most of the stuff I would never use for my oven.
An idea I had for the profiles. But I don't how I would set up the prop to understand it, nor do I know how to save the profile on the SD card so the prop can use it. My idea is to just have parameters for each zone of a profile. To give you an example of what I am thinking, I will be referencing this general profile
Profile name = "General Profile" (Limit to 22 characters max) total profile time = 300 seconds (Just for displaying) Max temperature = 255 C (Sets oven Max limit) Zone1 Name = "Pre-heat" (Again, limit to 22 characters) Upper temp = 150 C (Max upper temp for profile zone) Lower temp = 150 C (Max lower temp for profile zone) zone cycle time = 90 seconds (this cycle time limit) slope = 25 C (Limit how fast oven heats up. 25 = 2.5C/sec. value = 0 if slope is not needed, and oven will heat as fast as it can ) Zone2 Name = "Soaking Zone" (I think you have the idea) Upper temp = 210 Lower temp = 210 zone cycle time = 90 slope = 10 (1C/sec) ~~ more cycles ~~ Zone10 name = "Cool down" (There would be a limit of the number of zones.) Upper temp = 0 (The prop would shut off the heater driver if set temp = 0) Lower temp = 0 zone cycle time = 0 (Prop would know that cycle is done when current oven temperature is less than 50C) slope = 0 (A slope could be added to inform me if oven is cooling off to fast or to slow) (or to control servo that is hooked to door)
Please let me know if you have any insight, concerns, or ideas.
Thanks
TC
913 x 624 - 51K
Comments
Your assumption is correct, I have a 64k eeprom. Currently, I am using the upper side of the eeprom for storing the PID values, screen brightness, etc.... But I am also storing words and display boxes. Then I just read from the eeprom, put the data in a buffer, then send it to the display. It is slow, but it works. I want to make it so every display screen is stored in the upper side of the eeprom. Right now I am using Jon McPhalen's eeprom object. I am using "wr_str" and "rd_str" methods. But I am going to have to change that. The method looks for a ending "0", and a few of the commands for the display use "$00". So the method thinks that it is at the end of the string, when in fact, it is just the beginning.
Yes, it's possible to store menu data on the SD card. My robot remote project stores menu information on a SD card.
As Mike G suggested in your menu thread, each menu is assigned an ID number. I have the menu data structured so it's easy to add additional menus. I give some details of how I structure the menu in the robot remote project thread.
I'm reasonably satisfied with the structure of my touchscreen menu data but I have another robot remote project (not documented) with a LCD. I've been surprised how hard it's been to come up with a menu structure I like for a LCD type menu.
Like many forum members, I've spent a lot of time working with menus for projects. Often times coming up with a good interface is the most challenging part of a project.
That is a really interesting project. And I have a question... How did you create the 2 master files on the SD card?
I have never used a SD card with the Prop, and I want to learn how to.
I have somewhat of an idea on what you two are explaining, but I think I am going to have to jump in head first to fully understand.... But I again have a question...
I am assuming this would be used for a method that controls your display. What is " @menuMecanum " point to?
I feel your pain, I am on my 3rd menu iteration, and there are things I want to do better. I would like it so the words on the menu shift left/right with each click of the encoder
I agree with you there. But it is nice to have others to offer there input and advice.
Once I decided to store menu data on the SD card, I tried to figure out the least disruptive (to my program) way of accessing the data.
I was tempted to make all the menu data printable ASCII characters so I could use a any text editor to generate the menu data but "ASCII only" would make the data sets larger (almost double in size). So I decided to modify my original program to record all the menu and button data to the SD card in its "raw" state.
Since your menu data won't be as large as the robot remote's data, I'd think you might want to use ASCII only characters so you can generate your menu data with a text editor.
I'm attaching the code I used but I don't think I'm doing you a favor in doing so. It's a horrific mess.
I still have to have all the menu data in a single Spin file but since I don't need the other remote code, I have enough RAM to hold all the menu data in a single file.
I started working on a program which would allow me to add a single menu item, but my initial attempt to get it to work failed.
As it is now, my robot remote requires three Spin files. The file attached to this post is used to load the menu data to the SD card. Once the menu data is loaded to the SD card, I load the "normal" remote program to the master Propeller. There's also a slave Propeller running a third program which controls the touchscreen.
I debated posted sections of the code to show you what things like the above code meant but I decide to just post the whole program.
You can use ctl-f and search for "menuMecanum". You find it's list of buttons used to generate the Mecanum wheeled robot's menu.
I like the idea of using an encoder as an input device. I've been planning to use an encoder on our kitchen oven's controller for several years but I still haven't done it. The pot I've been using is getting bad spots and it's hard to precisely set the temperature. I doubt I'll ever use a pot again as a menu input device.
Absolutely. I didn't mean to imply you needed to pay your dues or anything. I was just complaining and also letting you know (which I think you already do) writing a good menu system can be a time consuming project.
I tried to do it that way, but it would be better for me to start over making the menu
I dont think I want to go that route. I would like to have it that when the Prop needs to display something, it just passes the data from the SD card, to the display. Take this for example,
DAT '| <- Move to location 1,3 -> || <-- Font Magnification --> | | <-- Font Magnification --> | RunProfile BYTE $1F, $24, $01, $00, $03, $00, $1F, $28, $67, $40, $02, $02, "Run Profile", $1F, $28, $67, $40, $01, $01You have not seen mine.
Yep, been there.... A LOT
It is nice because it looks clean, but it is a hassle since there is only one button doing everything.
Trust me, I in no way thought that is what you implied. But it is nice to know that even though I don't have great programing skills, others have the same problems I do.
Tell me about it. I am so lost right now trying to figure a way for the menu to be on the SD card. I think I am going to drop the idea, and stick with what I am comfortable with.
Agreed. I might not be a pro at knowing where things are in memory, so I created a excel file that takes an address, I add how many bytes(characters), and it will show me the ending address with the zero at the end. And it also shows me the next address to use.
I would like to have the profiles on the SD card. And also use the SD card for data logging, for diagnostics, and PID testing. But those can come at a later date.
*** EDIT ***
I added the excel file I made and am using. All the fields but 2, are locked, but there is no password to unlock the whole sheet.
Much of the speed and small size is due to the simple structure, the SD is treated as a very big collection of 512 byte pages, and a file is simply an allocation of a number of contiguous pages. There is no FAT file system, but you could still write a program to read it fron a PC (I haven't there has not been sufficient need). There is no delete, we just save a new file with the same name, and the new version "hides" the old version. If the card ever filled up, you could reinitialize it and start from scratch again.
I've been loggin the water level in a well once every few seconds for about six months, and I have not filled my 4 Gig card. It automatically create a new logfile at midnight. You can set it to use one huge file, or create new files at whatever trigger event.
The real time clock support uses 64 bits and is based on the 32bit counter. There is some drift due to temperature but it seems better than a cheap analogue watch. Once the ca;ibration offset is determined (after a day or a week) its pretty much "close enough". The 64 bit time stamp allow for unique time stamps for 7,133 years.
So far its been plenty adequate for the type of stuff one typically wants to do on a microcontroller. And its fun.
There's only one problem TC, it's Forth
On my Tachyon Forth the file system is a breeze, I can handle FAT32 files easily, open them, treat them as a virtual memory block so that I can read or write any byte, any place, or handle it more conventionally with sequential reading and writing and appending, even treating it as character I/O like a terminal or coms port. What's more, I can have 4 files open at a time. The datalogger app along with menu screens and FTP access is a snap.
Well, there's only one problem.....
http://forums.parallax.com/showthread.php/138251-A-Propeller-OS-that-can-run-on-multiple-hardware...?highlight=propeller
My oven stores 40 time & temp settings. This is more than adequate. What I ended up doing was make each setting 10 seconds, and set the temps to match the profile required.
Once the full soldering is done, I find that the actual temp is maintained no matter what profile I use to ramp down. The last few settings I just use 1s because it is not necessary to wait the whole time.
I have decided to use the first setting as a version number so that I know which temp profile I am using.
Are you saying, that PropForth access a SD card just like a eeprom? Could I have a list of addresses for each menu item?
I would have to have a computer to be able to read the SD card(don't care about writing). There is only one way I know how to take log information and display a graph. That is using a CSV file, with excel. For previous testing, I was using the upper side of the eeprom to store the data, then when the oven was done, it would show the log data(in CSV format) on the serial terminal. I would then copy and paste the information to excel. Time consuming, but worked.
Haha.. be nice
I will have to check it out when I get home. My work blocks most of Google services (except search).
And what is the one problem?
I have added a lot of insulation to the oven. Now the oven heats up real fast. about 8-10°C/Sec, so I have to have it take a temperature reading every second.
I just used that profile as an example. That is why I want to have the option of selecting different profiles.