1. Home
  2. Embedded Programming
  3. Position independent code with position dependent data ?
  4. Page 2

Position independent code with position dependent data ?

I should probably clarify... :<

To us, customer was the OEM. *They* would design new assays, debug them (in terms of the chemistry) and code up the "QBASIC" routines to implement those assays for *their* customers ("end users"). So, it was reasonable to expect them to have certain tools available for that process (though they surely wouldn't want to be dealing with "raw iron").

I don't think the end user ever *saw* QBASIC. They would typically purchase "Paks" (ROM based) for each assay. FDA issues, etc. (though there was no reason why, from

*our* standpoint, this utility couldn't be "exposed")

Yes, I find that to be true of "modern" languages. :< They try to be overly friendly instead of overly *efficient*. Hence my comments regarding fixing/declaring string sizes, integer only math, etc. You can do a *lot* in an environment thusly constrained *if* you are made aware of those constraints. Often, a "user" only needs the ability to do calculations, handle conditionals and "print" (emit?) formatted text with "results". So, a lot of the flowery features of modern languages are wasted...

Nowadays, I would look into support for connectivity as more and more devices talk to each other (or *should*! :> )

One advantage of Limbo/Inferno is the application can extend beyond the confines of the device itself. E.g., you can "export" the hardware from the device/instrument and actually run the *application* external to the device (remotely!)

Reply to
D Yuniskis
Loading thread data ...

Basically the same here except that when the customer snaps his fingers we jump. Very few customers and all big. In one case we have something like 14 versions of an instrument. Actually, more than one case, because often the casework and badge is the the main difference. Part of the problem though is that each "Method" or assay has a lots of UI parameters to set, and lots of languages to work in (including Chinese and Japanese).

[snip]
Reply to
Peter Dickerson

I was suggesting putting data _AND_ code into the 8 KiB RAM. Assuming

4 KiB for data and 4 KiB allocated for code, you could use functions up to 4 KiB in length. When a function is called, it is copied from a unique address in FLASH into RAM starting at address 0 and this function is then executed starting at 0.

When this function calls something else that needs to be loaded, the current segment ID and offset from start must be saved, so that the calling function code can reload the code and continue execution after the call instruction. With the fast flash read times would make such systems much faster than the old overlay loading systems loading from slow disk drives.

Why do you need a DATA section ?

Think about the system initialization routine as the "main" function and within that function, allocate all variables as automatic local variables that needs to be shared between the tasklets.

The tasklets can then be called as subfunctions and each call will then pass pointers to the "main" local variables as call parameters. In order to keep the tasklet parameter list length reasonable, the "main" local variables are grouped into structures.

Reply to
Paul Keinanen
[8>>> Yes, we wrote/implemented a "QBASIC" for some of our instruments

Ah. In our case, *one* customer (the instrument was designed to fit their needs). But, from their (and our!) perspective, fiddling around with chemistries and tweaking assays just didn't make sense for *us* to be doing. Their folks could tweak the reagents used in the assay, observe the results and create their own "test criteria" to present *their* results to *their* customers far more efficiently than if we were in the middle of the process.

We made some special "ROM Paks" with BBSRAM (and a "write protect" switch) to facilitate their development efforts but otherwise stayed clear of it all.

I suspect it made sense economically (though I am sure the decision was made more from an *engineering* perspective -- being engineers, we didn't want to be "bothered" with the boring details of assays ;> )

[frankly, I wouldn't have wanted to be *around* some of the things (bugs!) they were testing for...]
Reply to
D Yuniskis

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.