 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 : Reading binary files from SD Card
| Author | Message | ||||
Mal_M Newbie  Joined: 08/08/2011 Location: AustraliaPosts: 6 |
Does anyone know a way of reading binary files (one character at a time) from the SD Card? I thought I would be able to use the INPUT$ function to do this. It seems to work OK with all binary values except H'00. I had a brief look through the source code and I can see that function fun_inputstr uses a pointer to a null-terminated string (sret) to return the byte/bytes that have been read from the SD Card. Perhaps I need to define a new function to read binary values from the SD Card (using fret to return the data as a float), or is there a way of reading binary values (including H'00) using the existing functions? |
||||
Geoffg Guru  Joined: 06/06/2011 Location: AustraliaPosts: 3194 |
This could be a real problem, something that I did not anticipate. All strings (such as the output of INPUT$) are stored in C style strings which use a zero valued byte to terminate the string, therefore you cannot return a zero valued character. At the moment I believe that there is no way to read a zero byte. I will look into it but the fix may take some time. Geoff Geoff Graham - http://geoffg.net |
||||
haiqu Senior Member  Joined: 30/07/2011 Location: AustraliaPosts: 152 |
You'd have to know the exact size of the file and import it without scanning for null termination characters. Text and binary data are always handled separately. Rob unzip, strip, touch, finger, grep, mount, fsck, more, yes, fsck, fsck, fsck, umount, sleep |
||||
| seco61 Senior Member Joined: 15/06/2011 Location: AustraliaPosts: 205 |
Hi. The storage of string data can be done in 2 ways - the "standard" C way with a terminating NULL (ie 0x00) or with length prefixed strings. The latter has the benefit of all 256 byte values being able to be used in a string. However, there are 2 utility commands/functions that I supplied as part of the I2C implementation: NUM2BYTE and BYTE2NUM. These are documented at the end of the I2C information in appendix A of the user manual. These allow 4 consecutive bytes of information to be converted to and from a 4 byte float number (the native number format of MMBasic). If the "binary" file can be made a multiple of 4 bytes (with a pad character or 3) then by reading or writing a float (or multiple floats) at a time the data could be transferred too and from an array of numbers. This would "waste" 3 bytes for each array member, but does allow access to the individual byte data. It means you have to read and write 4 bytes of data at a time - but you can access each byte of data separately. Regards Gerard (vk3cg/vk3grs) Regards Gerard (vk3cg/vk3grs) |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6093 |
The problem will appear again when the RS232 is available. I know that some of the devices I want to talk to will require CHR$(0) to be sent and received via serial. I also see the requirement to read BMP files from the SD card and send them to the PC. If a fixed length from the file could be read into a section of memory, PEEK and POKE are available to get to the individual bytes. Jim VK7JH MMedit MMBasic Help |
||||
| seco61 Senior Member Joined: 15/06/2011 Location: AustraliaPosts: 205 |
Hi Jim. Be aware that MMBasic has no "address of" capability, so there is no way of knowing where in memory data, variables etc are located. This makes using PEEK and POKE somewhat difficult.... Also, depending on the implementation of RS232, it could still be possible to send and receive bytes of data - you just supply the command with numbers that are constrained in value to 0 - 255. See the I2C implementation in appendix A for an example. regards Gerard (vk3cg/vk3grs) Regards Gerard (vk3cg/vk3grs) |
||||
| Mal_M Newbie Joined: 08/08/2011 Location: AustraliaPosts: 6 |
Thanks for the feedback. I have experimented a little further with this. What I have found is that the INPUT$ function definitely won't work with multi-byte reads that have a H'00 byte within the string. However, INPUT$ does work ok for a single-byte read. Here's some code (a simple hex-dump program) that can dump a binary file from the SD Card to screen. I've only tested it over the USB interface. There may be formatting issues on VGA/Composite monitors. 10 REM HEXDUMP.BAS VERSION 1.0
20 REM 30 REM THIS PROGRAM WILL PROVIDE AN ON-SCREEN HEX DUMP OF ANY FILE ON 40 REM THE SD CARD. 50 REM 60 REM WRITTEN FOR GEOFF GRAHAM'S MAXIMITE COMPUTER. 70 REM 80 REM BY MALCOLM MACLEOD - AUGUST 2011 90 REM 100 REM MALCOLM@AVITECH.COM.AU 110 REM 120 PRINT "Hexdump version 1.0 by Malcolm Macleod" 130 INPUT "Enter name of input file: "; f$ 140 OPEN f$ FOR input AS #1 150 adrs =0 160 IF EOF(#1) GOTO 420 170 b$=HEX$(adrs) 180 t$="" 190 IF LEN(b$)=1 THEN 200 b$="000"+b$ 210 ELSEIF LEN(b$)=2 THEN 220 b$="00"+b$ 230 ELSEIF LEN(b$)=3 THEN 240 b$="0"+b$ 250 ENDIF 260 PRINT b$; " : "; 270 FOR i = 1 TO 16 280 IF NOT EOF(#1) THEN 290 a=ASC(INPUT$(1,#1)) 300 IF ((a<32)OR(a>127)) THEN t$=t$+"." ELSE t$=t$+CHR$(a) 310 b$=HEX$(a) 320 IF LEN(b$)=1 THEN b$="0"+b$ 330 PRINT b$; " "; 340 ELSE 350 PRINT " "; 360 t$=t$+" "; 370 ENDIF 380 adrs = adrs + 1 390 NEXT i 400 PRINT ": "; t$ 410 GOTO 160 420 CLOSE #1 |
||||
| wizard Newbie Joined: 29/07/2011 Location: United StatesPosts: 38 |
Hi All, A simple way to achieve your goal without too much change is to provide a way to send and receive one byte at a time. i.e.- when you receive 1 byte you check a flag for zero byte received. I do this with a single word that has 0x100 instead of a byte with 0x00. Sending can be done even more easily with an escape code. The details are hopefully obvious at least to Geoff? Wiz. Simple Ideas -- Powerful Solutions p.s.- Is there a repository with cutting edge MMBasic? I have MMC and ethernet running on pic32, but have yet to get MMBasic really running on my breadboard. |
||||
 Print this page |
