ELF file: linking in large binary data

The current version seems to be "everything is an object".

Paul

Reply to
Paul Keinanen
Loading thread data ...

On the contrary, the systems I am talking about were often small, with minimal overhead. They rarely contained more than 8k of code, and 8k of data space, and were based on the 8080. Their hallmark was reliability, since they were used in medical systems. Everything was in ROM, and the user turned on the power switch.

A new device was integrated by filling in one row of a six column table, specifying routines for open/close, read/write, status/control. Simple devices could have no more than a return instruction for a routine. To return an error (e.g. write on read/only) they did "stc; ret;". A simple byte oriented serial device could be implemented in 20 bytes of code or less. A buffered interrupt driven device took slightly more.

You realize, of course, that a file system does not imply an operating system, although the reverse seems universal.

I also had the totally unstructured raw port access embodied as non-portable system routines for the high level languages.

One instrument where the data capture etc. was very handy could be described by:

The operator sets an identification (digiswitches), feeds a sample, and presses an 'inject' button. The sample disappears into the maw. The next sample may be injected no sooner than about 10 seconds later. After about two minutes (a few seconds window) the results appear in the form of several analog voltages. These have to be captured, computed, and the results associated with the original ID number. Note the pipeline. Some particular ID numbers constitute calibration samples, which must be analyzed and calibrate the overall machine, using a least squares analysis and various 'goodness' criteria. The results appear both on a local hard copy, and are transmitted to a central data collection system with error protection. If for any reason the remote collector is unavailable results are buffered until they can be shipped.

I have only had one system that ever needed 100k or so of initialized data, and that had to do with rapid response to encrypted challenges.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!
*
Reply to
CBFalconer

Those are operations needed for a filesystem. Believe me, this sort of implementation makes life much easier in the future. I am naturally extremely lazy.

A LED may be a device within a filesystem. It is write-only. It requires very few operations to prepare for use, or to discontinue use. It communicates with the outside world. It may be virtuallized.

I suggest you look at my response to David Brown. BTW, please don't strip attributes for material you quote.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!
Reply to
CBFalconer

This may be a quibble, but for the sake of terminolgy isn't this just treating everything as a stream rather than as a file?

At MPE we call this Generic I/O - it avoids the overhead issues you're being accused of. It's a great approach, but I'm not sure I'd use it as intensively as you do when performance is an issue.

Stephen

-- Stephen Pelc, snipped-for-privacy@INVALID.mpeltd.demon.co.uk MicroProcessor Engineering Ltd - More Real, Less Time

133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web:
formatting link
- free VFX Forth downloads
Reply to
Stephen Pelc

Wow. Lots of good suggestions. I appreciate your replies.

Just to summarize, we have the following options:

  1. Generate pre-initialized C-source arrays, possibly using some scripting language like python or tools for generating PNM or pbm images.
  2. Use armasm's INCBIN directive.
  3. Declare an uninitialized fix-sized array inside the code, with some "magic" string at the start of the memory area. After compilation, paste the binary data into the object file starting at the point where the "magic" string is located.
  4. Load binary data dynamically from filesystem.
  5. Use GNU objcopy to copy the binary file into the executable.

I've tried the armasm INCBIN directive and so far, it seems to be working correctly. I'll stick to this option for now since it's the simplest.

Thanks all.

Will =>barry

Reply to
Will Barry

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.