Apology: Unix, 2.11BSD Thread

It makes it easier for them to excuse themselves when the datasheets don't correspond to reality. So when you find that the chip doesn't actually work, it's an "undocumented feature" and not a fault in the design.

Agreed, keep it up Don. When the group got a quiet a few months back I saw your posts as you maling an effort to promote activity - a good thing.

I've never seen any contribution positive or otherwise from our drop in critic Hans-Knobhard Bender.

That is the classic Philips practice. In 1972, I designed a circuit around a Philips chip (TAA 320, IIRC). The datasheets were marked 'Preliminary'. When the thing went into production, the data sheets were already marked 'Obsolete, maintenance only'.

--

Tauno Voipio

You are a bad evil man, Don :)

You need rights to post on Usenet? Are you loco, seh? :)

I tort it was cool as I had never heard of such animals - so newsworthy to me.

Always wanted to find out what PICs could do - so newsworthy to me.

Heard of Unix on many processors but never heard of such an animal - so newsworthy to me.

Yes, yes, yes, we have already said you are a bad evil man. OK OK OK, you want more? Right, if there was a hell, you'd burn there as well. Feel better? :)

Oooyyy, steady on there, old chap. No need to be rash like that. :)

Define expensive.

The LPC3131 has 192KB of RAM and Olimex produce a header board, called the LPC-H3131, which also has 32MB of external RAM.

They show a list price of 69.95 Euros (+VAT/P&P).

(Plus the cost of whatever programmer you would want to use of course.)

Details, including pricing and Olimex distributors, available at:

I've got one of these but I have not done anything with it yet so I don't have any real world experiences for you.

I've read sections of the LPC3131 datasheet and the one thing I did notice is that the GPIO input interrupt appears to need configuring in advance for interrupt on one of either low->high or high->low.

You appear not be able to have a Atmel SAM7S style interrupt on any GPIO change which may or may not be a issue for you.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

In the early 1970's the PDP-11/34 single rack minicomputer with a maximum of 256 KiB core memory was quite popular.

With some well known disk operating system, such as the RSX-11 family, it was quite convenient to perform overlay loading and only load those code segments actually needed into core.

Unfortunately, it appears that everyone has forgotten how to do overlay loading properly.

I wouldn't call that unfortunate. Good riddance, I'd say.

Agreed.

American Automation had a linkage editor and runtime package that would allow you to build ~1MB executables on the Z180 (which suffers from the Z80's 64K memory space limitation). It was convenient and (relatively) pain free to use.

But, the performance hits and design aspects of having to deal with all that behind-the-scenes bank switching left you wondering when things were going to break -- or, when your code was going to attain a character that would be incompatible with the memory partitioning you had selected (the Z180 supports three concurrent regions of memory with adjustable logical boundaries)

It is indeed a lost art. Last time I used overlays was with a TurboPascal 3.x project. You were limited to 64K of memory even if you had a whooping 640K installed. (And I have, from a reliable source, that nobody will ever need more memory than that.)

First time was when porting the Software Tools packages (Ratfor and family) to an HP-21mx mini with 64K memory. One overlay for initialization, second for the application proper, third for cleanup. Otherwise they wouldn't fit.

Overlays don't make sense anymore in 32bit embedded systems with no file system and were all the code is accessible in single span of flash memory.

-- Roberto Waltman

[ Please reply to the group. Return address is invalid ]

Overlays and bank switching are two very different things, even tough the latter can be used to implement the first.

I agree, getting task switching to work transparently, (as in calls/returns across banks,) can be a nightmare.

Overlays are more akin to sequentially running several programs, that happen to share non-volatile data segment and maybe some code. Maybe more limited, but much easier to design and implement correctly.

-- Roberto Waltman

[ Please reply to the group. Return address is invalid ]

I was commenting on the LPC32xx family. Limiting myself to the '3250 (256K internal + Ethernet + LCD controller) I found a few boards, all above $400. There is a basic "core" board from Embedded Artists for ~ $100, but you need to plug it into a carrier board to get access to the peripherals.

-- Roberto Waltman

[ Please reply to the group. Return address is invalid ]

Yes, of course. Bank switching is typically a "load once, execute repeatedly" operation whereas overlays (may) require multiple (re)loads for similar results (though overlays typically tend to be "load once, then discard").

But, both present the same sort of design issues -- how do I get access to something that may reside "under" (as in, "obscured by" my current code/data). Since the costs of switching banks or overlays are >> normal access/execution times, you can't just arbitrarily put things "wherever they fit" (i.e., NUMA)

Or, even data accesses!

I think it depends on the character of the application as well as the size of the overlay region. I.e., a tiny overlay region can severely cripple an overlay-based design. By contrast, a similarly sized bank-switched region just means you may end up spending more on the "overhead" than you might otherwise have liked/planned

(e.g., the Z180's COM1 and BANK areas can be resized to accommodate larger/smaller "objects" -- CODE/DATA -- while trading off the overhead to access and manipulate those objects. By contrast, if you can't fit each of your objects into an overlay region, you need to do some serious rethinking about how the application is designed)

First time for me was with the HP 2116/2114 -- pre-21MX, which didn't exist at the time.

But there are cases today where they _may_ make sense on

32-bit cpus. There may be a certain amount of internal flash that has enough room for the "application proper" as you write, but not enough room for less needed and slower 'utilities' or 'functions' which can be loaded into RAM and executed.

An example of this might be in a BASIC system placed on chip like those available from Parallax, but where certain low-use functions that can afford a delay are placed in external, serial FRAM or flash. An example of such might be matrix inversion or determinate support or FFT, which inherently may take a little time to execute and where the loading overhead time is low (despite being serial) compared to the execution time and keeping them in the flash would require a more expensive processor that may also not have a lower pin count package available at that size (or simply be unavailable.)

That's only an example to stimulate the imagination, not definitive proof. But if you use your imagination a little, I think you could come up with even better examples where it may still make some sense.

Just to be argumentative. :)

Jon

.....

You have forgotten the MOST used and implemented overlay of all Boot/flash loader...

Overlays can be useful if you have opposed functions, that cannot or will not be needed at the same time. In early wordprocessor days common overlays were spell checkers and mailmerge, as neither were done at the same time. Probably should have been, but were not done at same tiem.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate

Valid points, but I believe the range of applications were techniques similar to overlays are a good choice is (very?) small and shrinking.

Of course, my views are probably colored by the type of projects I have been involved with the last few years.

Some were Linux or Windows CE based, with a conventional "boot from storage device and copy to executable RAM memory" startup process, and more than enough memory for the application(s), so no overlays were needed.

Others used ARM chips with built-in flash memory, so, if any code is there it can be executed in-place without "overlaying" with anything.

For the second group, if at any point it looks that overlays are needed, (add external flash/copy from ext flash to RAM) the correct solution, (which may or not be doable,) would be not to implement overlays, but to use another processor with more memory. (Yes, I agree. And more expensive. And larger pin count.)

Regarding Paul's comment. I am on the fence on that. Bootloader + after-bootloader doesn't smell like overlays any more than having a dual boot Linux/Windows system would.

Finally, the real overlay killer was none of the above but the wide availability of systems with virtual memory support.

-- Roberto Waltman

[ Please reply to the group. Return address is invalid ]

One modern descendant is cache locking for real-time systems. Virtual memory systems and cache systems now do (by HW assist) the equivalent of main-memory overlays, but their worst-case performance can be hard to verify. Lockable caches were introduced to ensure that critical code or data are in cache when needed. If the program locks different data or code in the cache, depending on what the program is currently doing, this is very similar to an overlay scheme.

Even more so if the fast memory is a scratchpad instead of a cache.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Not an embedded example but the IBM Cell processor had some overly support.

The Cell chip has a (relatively slow) PowerPC core to run the control software and 8 SPU vector units for the actual computation. The SPU's only have 256K of high speed local memory (each) which needs to be loaded/stored from/to main memory via DMA.

Needless to say this can be a problem for the average programmer (who probably shouldn't be using Cell). One "solution" was to support overlays that the "system" would manage via the linker. The first version was complex, ugly and I think done by people who didn't have overlay experience. The second version I think was done by some "gray beards" from the 70's who knew what they were doing. Even the overlay terminology was familiar.

It was like the old days except main store was used instead of disk for program storage.

Disclaimer - I never user the overlay system other to run one of the later samples. The first version was so ugly I couldn't stand to even try it.

For maximum performance the programmer really needed to understand the problem and schedule the DMA of code and data between local memory and main store themselves. DMA was asynchronous with local processing which gave many opportunities for performance improvements (and synchronization errors).

What if you've got 64KB of RAM, and a several hundred KB of code in a serial flash chip?

--
Grant Edwards               grant.b.edwards        Yow! This ASEXUAL PIG
                                  at               really BOILS my BLOOD
                              gmail.com            ... He's so ... so
                                                   ... URGENT!!

I think I mentioned that case in this very thread about 12 hours ago. :)

Jon