I rarely ask questions on this forum, but since I couldn't [easily] find it in the help-files, or on-line, I'm asking you guys.
I usually (like never) don't use the 'reentrant' pragma, but I think I may have to do that with a particular routine.
BUT I can't find the key-word that declares a function as reentrant. Am I missing something? Is there one for Keil's IDE tools? If so, what is its form? Can I get a link to the 'official' use of it?
Thanks in advance, and I need it asap because I need to pass this class and I don't want to really learn how to do this 'embedded' stuff anyway but the teacher keeps hounding me.
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
I guess I should catch this opportunity. (Sorry for my limited English ability.)
Stage-A: You have processor-A and compiler-A, these are able to support A1/A2/A3. Stage-B: Then, you downgrade your processor to processor-B, and get a compiler-B, these are able to support A1/A2, but do not support A3.
So, at Stage-A, you write down a cautionary about A3, and isolate A3.
But how do you know that processor-B/compiler-B do not support A3, at Stage-A? Do you have a processor-Essential and compiler-Essential as a Standard?
John Linq, that is a very good question. Its a hard one, and I chose to 'ramble' about it since it is indeed a good question.
Stage-A: You get a good idea of what the project is and how far it is expected to go... is it a one-off? is it going to sell 50 units per year?, 500,000/yr?
Ah... it will go to 250,000/yr for about three years at peak production, but before you get there, you'll need to get some funding, so you need to do a Proof of Concept. Build five prototypes for a "dog-and-pony show" and you'll get funded for the low-rate initial production (LRIP) at 5-10k/yr (enough for 'marketing to begin'), and if that goes well, they'll ramp you up as soon as possible to 250,000 units/yr. Of course that LRIP design will have to be cheaper than the prototype, so you start the cost reduction phase.
Hmmmm. Pick the processor you know that will eventually get you into an FPGA and migrate over to an ASIC. The prototype looks like you'll need the power of an ARM processor. But knowing that you can parallel process in an FPGA, an 8051 style core can handle the sequential throughput needs. The smaller processor has a small footprint on the fabric, and you'll be able to put all of those 'other' chips into it with room to spare.
Stage-A1: Off-the-shelf ARM processor. Build prototype. Impress the money people.
Stage-A2: Demonstrate the ability to get it into LRIP with a 'cheap' version
Stage-A3: Start the conversion over to the high-rate production: FPGA
(You've chosen a reputable compiler like Keil, and not some 'freeware' un-verified brand).
Stage-B1: The ARM is no longer 'needed' and an 8051 will do it. Its in "C" so those 'functions' are now sub-components within the FPGA, and the Serial Processing requirements are now to be implemented on a stripped down 8051 core.
Fortunately, you've written your source modules so that this process can be done so that software-routines can become hardware circuits, and the 'need' for serial processing is also isolated. Nice and tidy.
Hmmmm... ARM to 8051? Oh gee, that whole stack issue and reentrancy is starting to look like a problem. Almost makes you wonder if that transition will go smoothly... after all it is in "Standard C."
Well, then there is that whole host of caveats in order to fully implement the new processor. They call them "#pragma."
Oh, that's right... its right there in that isolated module, and specially identified potential "cautionary" issues per the book's section on "things to be careful of before you start monkeying around."
Stage B2: Your FPGA prototype is done and ready. You've been qualified and your investment people are convinced that it wll work and so they dump the big bucks into ramping up to the 250,000 units per year... maybe more? But you know that the market will demand a cheaper product and fast. You'll have to go full ASIC soon. The market might explode.
Stage B3: Since you were so darned careful making that "C" to HDL conversion, now all you have to do is work with an ASIC vendor and make sure the HDL is good enough for them to build an ASIC.
Stage C1: Big Bucks, and ASIC Prototype 1 Almost works... It failed a tiny little feature, and the investor's lawyers don't like it.
Stage C2: More Big Bucks, and ASIC Prototype 2 works and passes all qualification testing.
Stage C3: Your widget has ramped up to over 125,000/yr and demand is climbing fast. Your investors want more money (funny how that is), and now you can release the cheaper version while the competition is still in Stage A3.
Stage D1: You've dominated market share, gotten enough feedback, improved the design on the ASIC with Version 3. It is now "Productions" project, and now its time for you to work on another project.
This NEW project is low rate. You pick a processor that can do the job and is cheap enough. You'll never really change the processor until five years from now when *that* processor is no longer available. You pick another one in its class, (it wasn't your choice. Your boss thinks it is the best one to use, and you are now forced to use it because he can get a 'deal' on the first 2000 processors, which will last the company for another five years). But its not supported by your current IDE! Its only supported by *that* processor vendor's compiler. So you buy another compiler.
Good thing you've separated out your code properly: the *new* IDE requires lots of #pragmas to comply with "The Standards," but since you already know which ones are 'potentially' or 'likely' needed by other processors and other IDEs, it has also been isolated and well documented.
Weird how that happens.
Ramble factor: I don't care.