What is the recommended way to write/read data from files in iOS? All I see is:
Bulk I/O. E.g, contentsAtPath of NSFileManager or writeToFile of NSString. These are memory intensive and impractical for complex data structure.
Very low level buffer based I/O from NSFileHandle.
What seems to be missing is API that sits somewhere in between that can read int, float and strings (like Java's readUTF/writeUTF). The fscanf of C is a good example. I can roll my own. But, I was wondering if Foundation framework already has something that I have missed.
Thanks.
Bibhas, the low-level C API's (including fscanf) are available. For granular IO many apps utilize an RDBMS (SQLite) or NSUserDefaults. This may or may not meet your needs.
iOS also supports memory mapped files.
http://shift.net.nz/2011/04/memory-mapped-files-on-ios-worth-checking-out/
What seems to be missing is API that sits somewhere in between that can read int, float and strings (like Java's readUTF/writeUTF). The fscanf of C is a good example.
There's nothing wrong with using C's File I/O facilities if that suits your needs more appropriately than the higher level interfaces in Foundation.
(as your follow up comment shows you have discovered)
Related
I'm writing a program (C#) to read, convert, display, adjust and output point cloud data.
I can make every part of the program except for one - I am required to read in a proprietary file format. The data is coming straight from a laser scanner and we cannot get any closer to the stream than what is output to the proprietary file in binary.
I have an SDK from the manufacturer/proprietor that is well outside my scope of ability to deal with.
Firstly it is written in C++, which I can read and write to some degree but this all appears incredibly complex (there are hundred of header/source files).
Secondly, the SDK documentation says that I must create my SLN using CMake which is a nightmare for me also.
Thirdly, the documentation is scarce and horrid.
Basically my question is this:
I know that after a certain amount of header information I should find thousands of lines of "lineref,x,y,z,r,g,b,time,intensity".
Can I bypass the SDK and find another way to read in this file type?
Or, must an SDK from the proprietor be used to interact with their file type due to some sort of encryption?
I'm new to using VHDL and have run into an issue with my project. I'm trying to make an FPGA to converts from one communication protocol to a different one, and for this purpose it would be useful to be able to store (hopefully multiple) packets before converting.
Before I tried to store this data in arrays, but it became quickly apparent that this takes up far too much space on the FPGA. Therefore, I have been searching for a way to store the data on the DDR3 ram on the SP605 board (http://www.xilinx.com/support/documentation/boards_and_kits/xtp067_sp605_schematics.pdf, page 9). I however cannot find instructions on how to write or read data from this. I'm trying to store one 8bit std_logic_vector per clock cycle to later be accessed.
Can anyone advise me on how to proceed?
Xilinx offers an IP Core generator. This IP catalog contains a Memory Interface Generator (MIG) which generates an IP Core to access different memory types. Configure this core for DDR3.
Writing a DDR3 controller in VHDL is not a project for a beginner not even for an experienced designer.
The state machine is simple and well known, but the calibration logic is very costly.
You should consider a caching or burst read/write technique, because DDR memory can not be accessed in every cycle.
I haven't worked with block memories concept in Xilinx before. I want to put some simple numbers in a text file and save it. Then take those numbers and multiply by 2 and save in another file. I have written VHDL code but this is involving I/O so i have to use block RAM. But I have no clue about it. I have read tutorials and datasheet but still can't figure out how to do my task using BRAM. I am pasting my code with this question. Please let me know if we have to do some sort of programming for BRAM. when I am trying to compile the code, it is showing error that inFIle does not exist.
VHDL is not a programming language.
There are some programming-language-like features in VHDL (for example file IO), but these are only there to help write testbench code for simulation. When writing VHDL, don't think about coding software. Think about the hardware structure that you want to describe.
In hardware, there is no such thing as a "file". There is a hardware interface consisting of fixed signals (address, data, enables) to, e.g., a block RAM. You can read a word of data from the memory by specifying an address, but this will always be raw data.
To get the raw data into the block RAM, there will pretty much always be some software process running on an embedded or external CPU. The software running on the CPU can interpret the file system, and pass the relevant information for hardware-assisted processing to the hardware core (e.g., starting address in memory of data to be processed, length of data, parameterization of algorithm, etc.). Alternatively, there may be streaming data sources and sinks that pass through the hardware for processing.
This is what hardware is best at: processing a continuous stream of data and performing the same set of calculations on each data word.
I am trying to deserialize an old file format that was serialized in Delphi, it uses binary seralization. I know nothing about the structure of the file except some very high level records that are in it.
What steps would you take to solve this problem? Any tools etc?
A good hexeditor, and use the gray matter to identify structures.
If you get a hint what kind of file it is, you can search for more specialized tools.
Running the unix/Linux "file" command can be good too (*) See Barry's comment below for how it works. It can be a quick check for common filetypes like DBF,ZIP etc hidden by using a different extension.
(*) there are 3rd party builds for windows, but they might lag in versions. If you can do it on a recent *nix distro, it is advised to do so.
The serialization process simply loops over all published properties and streams their value to a text file. If you do not know the exact classes that were streamed to the file you will have a very hard time deserializing the file. (if not impossible)
A good hex editor is first. If the file is read without buffering (eg read directly from a TFileStream) you could gain some information when using ProcMon from SysInternals; You can see exactly what data is read in what chunks and thus determine more quickly where the boundaries are between the structures you already identified.
A tutorial is talking about cin and cout:
"Syntactically these streams are not used as functions: instead, data are written to streams or read from them using the operators <<, called the insertion operator and >>, called the extraction operator."
What is a 'stream'?
Consider a "Stream" as a physical hose, or pipe. At one end, someone may pour some water in. At the other end, it will come out. This is 'reading' and 'writing' to the stream.
A stream is just a place where data goes. It can be a 'socket stream' (over the internet) or a 'file stream' (to a file), or perhaps a 'memory stream', just data written to a place in-memory (ram).
A "stream" is an object that represents a source of data, or a place where data can be written.
Examples include file handles and pipes - things that you can read data from or write data to.
An important property of streams is that they share a common interface, so the same code can write to either a file or a pipe (for instance) without needing to be rewritten.
You should look at streams as abstractions on underlying 'sources' or 'sinks' of data. A source is something you read data from, and a sink is something you write data to.
The concept of streams allows you to perform I/O on various forms of media, network connections, pipes between applications, files, etc.
The stream abstraction is very valuable to us as developers as it allows us to simplify input and output, and it gives us the flexibility to arrange and reconnect the sources and destinations of these streams.
A good analogy is that of a hose. You can send and receive data through hoses, and you can connect these hoses to various things.
By allowing programs to talk through hoses, we allow all sorts of programs to talk to each other, and we increase interoperability and utility vastly.
This is at the heart of the UNIX philosophy, and supports some very powerful programming idioms.