What I've found to be the most helpful in eliminating such "bottlenecks" is the careful arrangement of those "short pieces of code". Sometimes changing the order can help to eliminate numerous calls. Sometimes it makes more sense, for timing reasons to replicate pieces of code a few times, with the associated code space penalty, using macros, rather than tolerating the penalty in execution time imposed by the calls and returns. I've learned that some compilers arrange things one way, others, well, another. That should not surprise anyone.


I do it too, but not so much because I'm lazy, though I am, but to ensure I haven't miscounted.


While that's true, much of the time, how the individual routines are arranged seems to make as much difference as how the algorithms are designed. Most code sequences don't amount to "algorithms" so much as simple sequences that handle individual required tasks. Once one decomposes high-level requirements into low-level functions (using the term loosely) such things become apparent.


I'm not so sure about that, but I am comfortable using ASM. While there have been cases in which I'd have used HLL, because an algorithm is more easily expressed understandably in HLL, properly commented ASM does pretty well, too.

The reason these projects were designed around DIP-40's was that, back in 1980 or so, the PLCC was the only alternative and was not yet so popular. The boards in question were purchased rather than newly designed. It's just the code and some ancillary hardware that's been added over the years. I use newer packaging when I have to provide a home for newer parts, as you can surely imagine.


So far, I've managed to outlive most of my long-time clientele, either in that they've passed on, or they've retired some time ago and their problems don't find their way back to me any longer, if they do need someone's attention. My work is very thoroughly documented, however, as is the obligation of anyone functioning in my role as a consultant. Anyone who follows rigorous engineering methods should have no difficulty understanding my code, flowcharts, HIPO (Hierarchical Input-Process-Output) charts. After all, an engineer's job is to write specifications, and not just to "make sparks" in the lab.



Over the years that I've been participating in discussions on this forum, I've repeatedly said that "Where you sit determines what you see." That's an old military addage, but applies everywhere. I've been engaged in two major sorts of work over my life, one of which has been at the very front of design and development, namely proof of concept, and the other has been "making what we've already got do the job" rather than ripping it out and replacing it. Of the ten or so businesses that I've worked for over the long-term, it's been mostly the latter, applying upgrades and extensions where it was both possible and practical. That's why I've used MCU's that fit on the old DIP-40 site in which the original 875x lived. I've tried some others, but keep coming back to them because they're familiar and because they provide amazing opportunities to keep the old hardware useful.

Only a couple of those clients from back in the late '70s and early '80's are still in operation, as they're as long-in-the-tooth as I am, and have similar backgrounds, being broadly educated and less accustomed to simply sitting down at the computer and starting to code when a problem appears on the horizon. All of them can read schematics, as that was taught back when we were trained, yet none consider themselves competent users of HLL's or HDL's.

I've bitched and griped about the frequent calls for persons presenting queries related to using what they've already got on hand to change their core concept in favor of a current-generation device. The reason for this has been that, when I'm doing proof-of-concept work, I use stuff I've already got on hand. This is (a) because I know what it does and how to make things happen with it, and (b) because it saves time that would be lost in "plowing up new ground."

Lots of people have, for example, expressed their hatred for the 8255 as a general-purpose parallel interface. Well, if it will do the job, and if it is already on hand, why not? What will it help to use a more modern device, particularly if it's already "on the board I had to buy for the class I'm taking?" Engineering, after all, is finding a way to solve problems using technology that's already available. The most available is what's already on hand. I, of course, admit that, starting from nothing, would find using modern devices a good solution to many problems.

However, because I estimate and perform my proof-of-concept work with hardware that I already believe I understand and have on hand, which includes, in large part, evaluation kits for FPGA's, CPLD's, and MCU's of many stripes. Consequently, I have considerable experience with evaluation boards, and evaluation software. Over the decades, I've learned what one can, reasonably, expect from evaluation hardware and software. I've also learned what one sometimes has to do in order to get the job done when the evaluation stuff doesn't quite do what one expects. That's what's given rise to this subthread.

The O/P has said he is a hobbyist, and, as such, it's unlikely he'd buy a multi-k-$ compiler for his hobby project. Having him go through all the perambulations required to do what I suggested, to the end that he could compile a 'C' program and subsequently program it into his target environment would not provide him with the tools that he would receive if he bought the full-up tool suite, neither would it deprive the vendor of that software of a sale, because he'd never be able to justify such an outlay for his hobby project. Now, this is a bit on the edge of what's appropriate, but there is one upside for the software vendor. If the hobbyist later discovers a commercial application for the project in which he's engaged, it will probably result in a sale of that tool set to which the hobbyist has previously been exposed, and with which he's proven his concept.

As Per has indicated, it probably violates the spirit, if not the precise language, of the licensing agreement for one to take the output from this demo-package and operate on it in such a way as to allow it to do what, normally, it wouldn't. It would, after all, not bypass the size-limit on the code in question, and would not be usable as such without considerable effort for each code module. Never having attempted this myself, I don't know which of the "features" of the package would work normally on a code set that exceeded the size limit, or operated outside the memory region that it normally supports.

Unlike Per, I think a discussion of how one can make demonstration software do what it probably should do, but doesn't, might be useful. There are ways in which the software vendor could and should protect his product without making it useless for evaluation on certain targets. It's not my place to enumerate them, though. The software vendor should consider this. While I'm not advocating trying to re-engineer that software so it becomes a "free" tool set, depriving the lawful owner of rightful profit, I do believe that it should be useable to perform a thorough evaluation, including producing code runnable on the desired target. How they make it impossible to create executable code on small-code-space MCU's has to be dealt with by their staff, and not by me.

RE