I read a file .caf with my program.
I use AudioFileReadBytes, but its OSStatus that return is -39, what is this??
thanks
Error number -39 (negative thirty-nine) is eofErr, a Mac OS Carbon error, which comes from the original Mac toolbox from the 1984. It's defined in MacErrors.r. That means it reached the end of the file, and there are no more bytes to read. You should note the number of bytes returned and complete whatever processing you're doing of the file at that point.
If you want to avoid the error, you can read the file length and number of samples from the various API calls, and calculate how many bytes to read, and never go past the end of the file.
Related
I have an STM32 application which uses two blocks of memory. In 0th block, I have a boot code (which runs just after power-on) and in 7th block, I have an application code (which may or may not run depending on the authorization decision given by the boot code).
Those two codes are developed hence generated by two separate projects. They are flashed on the specific blocks (boot code to 0th block and application code to 7th block) of STM32 NOR memory using openocd tool by giving an offset value to the openocd's write_image command.
What I would like to do basically in the boot code is that I want to calculate the hash of the application code and compare it with the reference digest. If they are equal, I will give the hand to the application code. For that, after I generate the executable (can be in elf, hex or bin format) of the application code, I want to:
Create another file (in any format listed above) which has 128K byte size
Copy the content of the executable file to the recently created file from its beginning (0 offset)
Write the hash of the executable to the last 32 bytes of the recently created file
Fill the gap with 0xFF
Finally flash this executable file (if it is still) to the 7th block of the memory
Do you think that it is doable and feasible? If so:
Which format should I use to generate the executable?
Do I have something that I need to give specific attention to achieve this?
Lastly, do you think that it makes sense to do that or is there any other more standard way for this purpose?
Thanks a lot in advance.
You just need to add an additional step to your building sequence. After the linking extract the binary file from elf
Then write a program in your favourite programming language which will calculate something and append the result to that bin file
I have a txt file that contains data in Common Data Format( CDF ).
Matlab has functions to read this but it does not work. I assume because the extension is .txt and not .cdf.
When I try to read it I get:
??? Error using ==> cdfinfoc
Error issued from CDF library: "NOT_A_CDF_OR_NOT_SUPPORTED: Named CDF is corrupted or
not supported by the current library version."
Error in ==> cdfinfo at 170
tmp = cdfinfoc(filename);
Error in ==> cdfread at 184
info = cdfinfo(filename);
Is there a way to trick Matlab and read it or do I need to transform somehow the txt into a .cdf? If so, how do I do that?
Thank you!
EDIT: The file that I am trying to read is from this link: http://www.ee.washington.edu/research/pstca/pf14/ieee14cdf.txt
This says that the data is in CDF: http://www.ee.washington.edu/research/pstca/pf14/pg_tca14bus.htm
If it's actually a txt file (in that it contains textual data that you can read), then it isn't really in CDF format. You can try makeCDF or some other tool to convert the textual data into a CDF file.
If that doesn't work out for you, you'll need to post more information about the actual format of the file. That text file could contain anything. Maybe provide some example lines?
EDIT
After looking at your file, this is an unrelated format which happens to also be called CDF. You can find a reader for this format here: Read IEEE Common Data Format (CDF) (Power systems, Load Flow)
In both cases I think where it's actually falling over is this call to the library:
fmt = cdflib.getFormat(cdfid);
See: cdflib.getFormat, in particular these lines:
This function corresponds to the CDF library C API routine
CDFgetFormat.
To use this function, you must be familiar with the CDF C interface.
Read the CDF documentation at the CDF Web site.
At any rate it's not due to the file extension alone; I tested this by making a copy of the MATLAB example.cdf, renaming it to example.txt, and calling cdfinfo on both. No errors, returned data is the same except for obvious things like filename/modification date.
I have two binary files that I'm trying to compare using Matlab's built-in function visdiff, but it only displays the first 2000 bytes as a default. Is there any way to force the comparison tool to display the entire contents of both files side by side?
Edit the file matlabroot\toolbox\shared\comparisons\private\bindiff.m, where matlabroot is your MATLAB installation directory. On line 149, you'll see it sets the variable MAXLEN to 2000. Change this to something bigger (even Inf seems to work).
You may need to type rehash toolboxcache after making this change, in order to get MATLAB to notice.
Please note:
As you're making a change to the MATLAB source, this is at your own risk (it seems fine to me though). Keep a backup of the file you've edited.
That truncation at 2000 bytes is there for a reason - comparing the whole of larger binary files does seem to take quite a while, so be patient. Maybe try gradually increasing MAXLEN, rather than going straight to Inf.
I only have R2011b available to me right now, so if you're on a newer version the file path and line number I mentioned above may have changed. It was very easy to trace through the code from visdiff to comparisons_private to bindiff though, so unless they've changed the deeper structure of the Comparisons Tool between 11b and now, it will probably be very similar.
Am writing an application for iphone to read a text file using NSData.
NSFileHandle *fileRead;
// this may lead to crash or memory issue, if the file size is about 10 mb or more
NSData *data = [fileRead readDataOfLength:(entire contents of the file)];
For example, if the file size is 8 kb, we can reading it in 8 iterations by 1kb per cycle.
Before reading the file, how can we find the size of the file contents.so that we can write the code in a optimized way to read the file effectively?
plz give me your suggestions....
The iPhone has all of the standard POSIX APIs, so you can use stat("file.txt", &st), where st is a "struct stat". The "st.st_size" member will give you the file size in bytes.
If you're really wanting to read the entire file, just use readDataToEndOfFile and don't worry about determining the length beforehand.
From an NSFileHandle, you can find the length by first seekToEndOfFile and then offsetInFile. If you have the actual file name, you could use NSFileManager's attributesOfItemAtPath:error: to retrieve the length (as with C's stat) instead. Or, for that matter, you could actually use stat, or fstat on the file descriptor returned by NSFileHandle's fileDescriptor method.
Is it possible (on iPhone/iPod Touch) for a file written like this:
if (FILE* file = fopen(filename, "wb")) {
fwrite(buf, buf_size, 1, file);
fclose(file);
}
to get corrupted, e.g. when app is forced to terminate?
From what I know fwrite should be an atomic operation, so when I write whole file with one instruction no corruption should occure. I could not find any information on the net that would say otherwise.
Since when fwrite is atomic? I can't find any references. Anyway, even if fwrite can be atomic, the time between fopen and fwrite is not, so if your app is forced to terminate between those times, you'll get an empty file.
As you're writing for iPhoneOS, you can use -[NSData writeToFile:atomically:] to ensure the whole open-write-close procedure is atomic (it works by writing to a temporary file, then replace the original one.)
You could make things easier for yourself and write the data using the NSData class that has a writeToFile:atomically: method waiting for you. Wrapping the raw buffer with NSData is not hard, there are the dataWithBytes:length or dataWithBytesNoCopy:length:freeWhenDone: initializers.
Data written with fwrite is buffered. So a sudden termination might not flush the buffers. fclose will flush the buffer but this does not implicate that the bytes are also written to the disk (due to OS level caches) AFAIK.