 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 : Data statements on SD card
| Author | Message | ||||
| busa Regular Member  Joined: 12/02/2015 Location: AustraliaPosts: 81 |
Explore 100: Is it possible to read Data statements from an SD card or do they have to be embedded within the program. I can read and write ordinary text files on an SD card ok but having no luck with Data statements.  Regards |
||||
TassyJim Guru  Joined: 07/08/2011 Location: AustraliaPosts: 5911 |
You can't read "DATA statements" but you can certainly save your data in text files (usually comma separated files) and read the data in using: INPUT #fnbr, list of variables The text files will look the same as DATA statement lines without the DATA at the start of the line. Jim VK7JH MMedit MMBasic Help |
||||
| busa Regular Member Joined: 12/02/2015 Location: AustraliaPosts: 81 |
Thanks Jim, That's what I thought but when doing it that way I get "Error:Line too long" after a certain number of variables. How does one start a new line in text files or do I need to open another file and save a certain number there? Regards |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985 |
for text files (CSV, as Jim recommends above, is a text file) generally lines are separated by Carriage return (CR - CHR$(13)), Line Feed (LF - CHR$(10)) or a combination. *NIX and MAC tend to use just LF, Windows tends to use CR+LF Create your text file (just the data from your DATA statements) with a text editor (Notepad will do - it doesn't have to be anything fancy) with the data grouped on individual lines or a single entry on each. So in your program, you might have something like: FOR n=1 TO 3 READ a,b,c NEXT DATA 10,20,30 DATA 40,50,60 DATA 70,80,90 If you take the data in the DATA statements and create a file called "fred.csv", you could replace the above code with ...(having opened your file as #1) FOR n=1 TO 3 INPUT#1,a,b,c NEXT This would work equally well if your text file looked like 10,20,30 40,50,60 ... or (but beware of "line too long") 10,20,30,40,50,60,... or even 10 20 30 40 50 60 ... Off the top of my head, I would expect MMBasic uses CRLF (two characters) to end a line because of it's Microsoft work-a-like approach. These will be inserted invisibly by your text editor that you use to create the text file. If you use a clever editior that can save files with different line endings, you could experiment with the three different ways and see what MMBasic is happy with. hth h |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
I like LINE INPUT for this kind of work. Here is how I am doing it in one of my programs running on the E100: DIM AS INTEGER G1_S,G1_E,G1_FRED,G1_FGRN,G1_FBLU,G1_BRED,G1_BGRN,G1_BBLU DIM AS INTEGER G2_S,G2_E,G2_FRED,G2_FGRN,G2_FBLU,G2_BRED,G2_BGRN,G2_BBLU Sub CONFIG Timer=0 LOCAL AS STRING LINE1$,LINE2$,LINE3$,LINE4$,LINE5$ LENGTH 50 LOCAL AS STRING LINE6$,LINE7$,LINE8$,LINE9$,LINEA$ LENGTH 50 Open "COLOURS.INI" For Input As #4 Line Input #4,LINE1$ 'Group 01 colours Line Input #4,LINE2$ 'Group 02 colours Line Input #4,LINE3$ 'Group 03 colours Line Input #4,LINE4$ 'Group 04 colours Line Input #4,LINE5$ 'Group 05 colours Line Input #4,LINE6$ 'Group 06 colours Line Input #4,LINE7$ 'Group 07 colours Line Input #4,LINE8$ 'Group 08 colours Line Input #4,LINE9$ 'Group 09 colours Line Input #4,LINEA$ 'Group 10 colours Pause 50 'Allow all data to arrive from cache Close #4 Print LINE1$ Print LINE2$ Print LINE3$ Print LINE4$ Print LINE5$ Print LINE6$ Print LINE7$ Print LINE8$ Print LINE9$ Print LINEA$ G1_S=Val(Mid$(LINE1$,1,3)) G1_E=Val(Mid$(LINE1$,5,3)) G1_FRED=Val(Mid$(LINE1$,9,3)) G1_FGRN=Val(Mid$(LINE1$,13,3)) G1_FBLU=Val(Mid$(LINE1$,17,3)) G1_BRED=Val(Mid$(LINE1$,21,3)) G1_BGRN=Val(Mid$(LINE1$,25,3)) G1_BBLU=Val(Mid$(LINE1$,29,3)) G2_S=Val(Mid$(LINE2$,1,3)) G2_E=Val(Mid$(LINE2$,5,3)) G2_FRED=Val(Mid$(LINE2$,9,3)) G2_FGRN=Val(Mid$(LINE2$,13,3)) G2_FBLU=Val(Mid$(LINE2$,17,3)) G2_BRED=Val(Mid$(LINE2$,21,3)) G2_BGRN=Val(Mid$(LINE2$,25,3)) G2_BBLU=Val(Mid$(LINE2$,29,3)) ... ... End Sub I am only showing the first two groups. Groups G3 to GA are exactly the same as these two. The text file(called COLOURS.INI) is formatted as ASCII-decimal thus: 001-025|255,255,255|000,000,000 WHITE on BLACK 026-050|255,255,255|255,000,000 WHITE on RED 051-075|255,255,255|000,255,000 WHITE on GREEN 076-100|255,255,255|000,000,255 WHITE on BLUE 101-125|255,255,255|000,255,255 WHITE on CYAN 126-150|255,255,255|255,255,000 WHITE on YELLOW 151-175|255,255,255|255,000,255 WHITE on MAGENTA 176-200|255,255,255|128,128,128 WHITE on GRAY 201-225|255,255,255|128,064,000 WHITE on BROWN 226-250|255,255,255|255,128,000 WHITE on ORANGE This file contains the colour-table data for the system. The first 10 lines of this file MUST exist, and they MUST define the colour groups. If you need less then 10 colour-groups, then ensure that the remaining lines are blank. The system ignores the rest of this file except for the first ten lines at the top. Line Format: [START,END,F-RED,F-GREEN,F-BLUE,B-RED,B-GREEN,B-BLUE] START = First number of the group END = Last number of the group F-RED = Foreground(font) Red Intensity, 000-255 F-GREEN = Foreground(font) Green Intensity, 000-255 F-BLUE = Foreground(font) Blue Intensity, 000-255 B-RED = Background Red Intensity, 000-255 B-GREEN = Background Green Intensity, 000-255 B-BLUE = Background Blue Intensity, 000-255 To define the foreground colour and background colour, you need to state six bytes in ASCII. These bytes MUST be in plain decimal. Do NOT use HEX. The system will read in the three ASCII bytes such as "123" and convert this to a single byte with the value of 123 for example. The system will ignore dashes, commas and pipes in the line. They are only there to visually separate the data and make it easier to decipher for the human. The dashes, commas and pipes still need to be there within the line, they are just ignored when read by the system. DO NOT omit them, or the system will fail to correctly setup the colours. RICTECH LTD. 27/06/2017 - 10:08PM This "Data" lives on the SD card as an INI file, to allow anyone to easily change the colours used for showing numbers on the LCD, without needing any sort of firmware update. I post this code and example data-file in the hope it might help you work out how to do a similar operation within your code. Because in my example above, the data is in a known format, the code can then strip out what it wants and ignore the rest. This is but one example, and is by no means the most efficient way of doing things.  It would be neater if I had used an array to hold this data, but you get the general idea I expect.......Smoke makes things work. When the smoke gets out, it stops! |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985 |
yes personally I too prefer LINE INPUT and chop it up myself as it provides greater control over how the data is treated (like INPUT getting string data when the recipient variable is numeric) but it is the road to "string too long" without care, hence I avoided it above |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
Completely agree and understand.  However, I have never had an issue chopping up a long data string, into smaller "Lines" for easier processing.As I mention above, my example is actually rather inefficient - I should have used an array along the lines of DIM COLOURS (6,10) and stashed my six colour bytes for the ten different groups in there - but I was lazy, basically! I must have a play with arrays a bit more - multi-dimensional arrays are something I have never got around to teaching myself how to use properly - I get lost after two dimensions or so!  Smoke makes things work. When the smoke gets out, it stops! |
||||
| busa Regular Member Joined: 12/02/2015 Location: AustraliaPosts: 81 |
Thanks Grogster for the very detailed reply. In my case I find that by saving each item on a separate line in my text file thus one two three four etc etc etc and then using this code snippet Dim nam$(50) Open "C:\users\martin\desktop\names1.txt" For input As #1 For n = 0 To 50 Input #1, nam$(n) next n Close #1 Print nam$(5) it seems to work ok. Not sure if it is the right way but hey, it's working |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
There is no "Wrong" way, really - if it works...... Clean, compact easy to read code is preferred, especially if this is something you ever plan to release to others, but if it is just for yourself or your business interests(closed source), then you can really do it any way you like that works - even if it is hard to read from another programmer's perspective.  I like that you are using a one-dimensional array - that is the way to do it, and much cleaner and neater then my mess.  Currently, your nam$ will be gobbling up 50*256 bytes, or 6.4K of RAM. If you KNOW your data will be a certain length, you can drastically reduce this RAM consumption by using the LENGTH parameter with your DIM. If your data was 50 bytes or less per "Line" you are reading into the array, you could use DIM name$(50) LENGTH 50 which would assign 50 bytes to each element rather then 256 bytes by default, thus only gobbling 2.5K of RAM for exactly the same purpose - a saving of 3.9K of RAM. Depends on how long or short your data lines are likely to be, but if they are short, you can drastically save on RAM by doing the above. If your code is not that big anyway, it won't matter, but to many people, RAM becomes valuable once your program gets big and starts doing lots of things, so saving RAM needs consideration. Smoke makes things work. When the smoke gets out, it stops! |
||||
 Print this page |
