I wrote an RTOS designed for ARM Cortex-M series processors. Much of its build process modifies source file templates producing code to be compiled. A configuration file specifies the number and sizes of FIFO buffers. Adding a task, or changing its priority or stack requirements modifies multiple files – most often via a generated header file. It switches tasks quickly and uses minimal ROM and RAM and even works okay on Cortex-M0 products. I would sell the source code with an NDA that prohibits distribution. Use on substantially similar products is allowed. I.e. first use is the brain of a coffeepot. No second fee for use in a toaster. Extra fee for use as an IoT security appliance or as part of a bowling alley pinsetter. I expect any sales would begin with a contract to teach about my RTOS followed by hands on assistance in developing the embedded application.

From my limited experience as a user Amazon eBooks have most of what you want.

Good thoughts: pacemaker or long running app where shutting down the computer is how to exit. But what about running under a multitasking OS like this: while(true)

{
osWaitMilliseconds(x);
doStuff();
}

No need to spawn a task every x milliseconds when one is waiting to be resumed. Or how about PIC code that looks like this:

mainLoop:
call sub1
call sub2
...
call subN
goto mainLoop

Near the top of a C++ module say const int zzz = 3; Then zzz acts just like a non-global (int)3. The compiler may (and should) attempt to avoid allocating a storage location for zzz. This is better than... #define zzz 3 ...because scope rules do not apply to the #define form. However, in an object definition const int zzz = 3; is illegal. I understand the workaround which forces every object instance to have storage for zzz. I also understand how an unchangeable data item might need to be different in each instance of an object. There is also some related Mickey Mouse™ stuff related to enum and constants, which I have not thought about for a long time. Please forgive any C/C++ syntax errors. I have been working with $.50 processors lately. C++ and processors with less than 30 bytes of RAM go together about as well as pregnancy and poll vaulting.

If you are using Rexx then interpret say "string" Except you first need to write sin(x) and other functions you use in Rexx. You also need to use Rexx rules for syntax. Rexx can compile and execute on the fly. With just a little more detail in dos one might type rexx math 1.2*4.7 5.64 prints The file math.cmd contains /* execute incomming statement */ numeric digits 40 arg cmd interpret say cmd It's been a while but saving x to a environment variable or some such is not that hard. My 40 digit ln() in ln.cmd is /* ln(x) */ numeric digits 40 arg x /* prescale to put x into reasonable range */ xp = 0 if x > 2 then do until x < 2 xp = xp + 1 x = x / 2 end /* now that x <=2 compute ln(x) method from Abramowitz etal section 4.1.39 ln(2) to 40 places takes 26 loops */ z = x-1 val = 0 do t = 26 to 1 by -1 t2z = t*t*z val = t2z / (t+t+val+1) val = t2z / (t+t+val) end val = z / (val+1) /* account for prescale */ if xp = 0 then return val return (const(ln2)*xp) + val

Perhaps I’m just going over semantics here but...are not public keys supposed to be public? The public key for your device can be public. Your device needs the public keys of authorized senders. And perhaps its own RSA key pair if it needs to say much in return. In the following E(key, msg) is RSA encryption of msg with public key and D(key, msg) is RSA decryption using public key. E’() and D’() are the same except they use the private RSA key. msg = D’(key, E(key, msg)) Alice: (plain text) I am Alice, an authorized sender. Device: Oh? Prove it. Here is a time stamp... Alice sends D’(keyAlice, Oct 9 2007 2228) Note – Alice uses her private DEcryption key here. (Device computes E(keyAlice, above message. All is okay.) Note – Device encrypts to decrypt. I know it sounds strange. Alice sends E(deviceKey, long random Blowfish key) + Blowfish encrypted message using the just sent key. Device recovers Blowfish key with D’(deviceKey, key part of prior message) The point is simple. The device needs only the public keys of trusted senders. If you need a CA for that then you need a CA. You might find that Twofish is easier to implement. In particular you do not need over 4000 bytes of pi. And a place to keep them for the next encryption. But if you have a hard drive that should not be a problem. On a machine large enough to be reasonable to do Twofish I would hardcode q0 & q1 and generate a table of already permuted MDS stuff on the fly. I.e. 512 bytes of hard coded constants + 4096 bytes of table generated as part of your key setup. Twofish ain’t that complex if I can implement the thing in both x86 and ARM assembly. I’ll do it for the Z80 or a PIC with several hundred bytes of RAM if someone will pay me. I bought Schneier’s book “used.” It made that nice cracking sound when I first opened it. My overall comments on Twofish: it appears more than a little over designed. And you don’t need 3 different encode / decode procedures for different key lengths. . . . . Oh wait. After writing the above I just reread your original message. Apparently you have multiple devices needing public keys. You can only allow trusted public keys into your system. Start with your public key. Your machines trust you. Only you or someone you delegate may enter new authorized users. In effect YOU are the CA. Don’t forget about physical access and how that can compromise your devices. -Peter

Steve_Harris, Equ is a simple equate which on this assembler had better (and does) work as expected on this 32-bit processor. Mike Dimmick, Quite a while ago ARM used to be pure 32-bit instructions. Then came the 16-but Thumb instructions. Subroutines called ARM code using address ending in 00 (two zero bits) and called Thumb code with addresses ending in x1. You had to tell the assembler which type of code you were using. #pragma’s allowed tweaking compiler output for speed (ARM) or code size (Thumb.) The Cortex-M3 is supposed to be the best of both worlds. In a 32-bit instruction one can get r9=r2+r3 with optional PSW setting. In a 16 bit instruction one can do r2=r2+r3 and set the PSW. With only 6 bits to hold register numbers the destination and one source must be r0-r7 and the other register must be r0-r7. Thus by avoiding the higher numbered registers a compiler (and even a person) can generate shorter code while still having access to the upper registers as needed. BTW, the I2CMICR register has only one bit that means anything. In my code fragment at the top of this thread storing 0x01 clears the interrupt condition. BUT MY INSIDIOUS BUG had nothing to do with that at all. . LAST CHANCE spoiler coming up . . . . . . The problem is the backslash at the end of the line just before where I interned to load r1 with 0x01. In this assembler and MSVC++ ver 6 and many other languages and makefiles a backslash at the end of a line makes the next line a continuation of the line ending with a backslash. Thus my movs r1,#1 was looked at as a part of the comment beginning on the prior line. The low bit of whatever was in r1 at the time of the interrupt was what cleared or did not clear the interrupt. Thus when I exited the interrupt with “bx lr” (which more than anything else sets pc=lr) I came right back. But somehow it continued as if the interrupt had been cleared when I was single stepping. (Side note: The funky “address” put into lr when entering the interrupt when moved to pc does the reload r0-r3, PSW and the rest of returning from an interrupt.) When debugging this I clicked on the processor pause icon and run alternately. I always paused in the early instructions of my handler. Finally I set a breakpoint on the str (store register) instruction and looked at r1. It was far from 0x01. A quick glance at the disassembled code, followed by !@#$% and I had the last clue needed. Clearly the movs was not getting into my object file. Then I saw the backsla

ied assumed incorrectly. The bug is among the mundane things that no one suspects. Consider the following C/C++ do nothing program that does NOT generate a compile time error. But to its credit my MSVC++ ver 6 does issue a warning which if read, points the reader in the right direction. void main(void) { int i; i=0; // \ what? // > no error on this line?? return; // / } Had the IAR assembler issued a similar warning I would have muttered a thank you toward its install directory. Hey, there is no excuse not to be polite – even to software. But for software that does not catch my mundane errors there is always The Code Project Subtle Bugs forum. Does everybody see it now? -Peter

Depending on interrupt priority your #1 could happen. Likewise #2a. But ISR code is supposed to play nice. And because I wrote all the code involve (save for an unused strlen and other simple library stuff I don’t know how to get rid of) my other ISR only reads the ADC and works a few GPIO line for the analog mux. #3 and #4a could happen subject to interrupt priority but that ADC ISR knows nothing of my I2C use. ARM Cortex-M3 will leave pending interrupts at the same or lower priority until the current ISR ends with its special link register value. This ARM variant will interrupt lower priority interrupt service to run a higher priority handler. Well behaved ISR’s do not step on stuff that ain’t theirs. So that is not the answer. Everything needed to solve the problem is in my post. To leave out an external misbehaving ISR would not be fair. Strange off the wall hint posed as a chemistry question . . . Q what is HIJHLMNO? Scroll down for answer . . . . . . . . . Is that far enough? . . A: its H2O – HtoO Sorry for the silly chemistry thing but the fewer details you know about interrupt handlers and the diverse conflicts they can lead one into the easier it might be to find this little nasty. Just as someone who knows little chemistry might say H . . . to . . . Oh . . .

I wrote a decent 5x5 Boggle game and felt that the problem was the dictionary. So...I kept multiple partial matches going always working the partial match with the lowest lexical value. Finds game buried in some oddball directory... Discovers it does not work in xp. Posting an old result... A L E R E O O T S T T G L U T N Z O Y E S C E N F alert alertest alertly ales aloe alter alto alts colog cols colt colter coly cone coney cony coulter couter cozen cozey enfetter enol erst ester eyen eyne fets fetter fetus feus fytte glue gluey glut gluten goal goer goes gone gout gouty lest lets logo loot looter lots lotus lust luster lustre lusty lute nets nett netter neuter nolo nous oleo oles oots ousel oust ouster outer outgo outgoes outre outs outsert outset oyez reset rest result retool rets retuse scene scone scouse scout scouter sere sloe slog slot slue slut stela steno stere stereo stey stoa stole stool strette stutter stye suet suety sutler tela terse test tester testy toes tola tole tolu toluene tool tooler toot tooter tootle tootler tote toter tots trestle tret tuts tutty tyne ulster user utter yett youse zone

This little snippet of ARM Cortex-M3 assembly code has an insidious bug. It cost me multiple hours of debug time including unnecessarily playing with interrupt priorities.; equates used below I2CMaster equ 0x40020000 I2CMCS equ 0x004 ;R/W I2C Master Control/Status I2CMICR equ 0x01C ;WO I2C Master Interrupt Clear ; my ISR began like this... I2CHandler ldr r0,=I2CMaster ;\ movs r1,#1 ; > reset that int now str r1,[r0,#I2CMICR];/ ldr r1,[r0,#I2CMCS] ands r1,r1,#0x01 it ne bxne lr ;return if busy ; ... ;code continues...
For those who wonder about I2CMICR and I2CMCS, they are defined correctly. FWIW, I am using The Luminary Micro Stellaris™ LM3S811 Evaluation Kit with its enclosed ILR “Jump Start” IDE. (I call the that IDE the “get to know us for free before we surprise you with how much the full version costs” version.) ARM Cortex-M3 processors are setup to use raw C code directly in an ISR. Specifically, an interrupt saves r0-r3 along with the (subroutine return) link register and the PSW. The link register is loaded with a funky value such that the normal C subroutine return restores what was saved. Bottom line on this: an ISR using only r0-r3 does not have to concern itself with register saves and restores. ARM Cortex-M3 has an if/then instruction. After the opcode “it” up to 4 instructions are conditional on the operand condition. In my code snippet that condition is (PSW not equal) ne, using the result of the previous ands instruction. Those not familiar with this processor may safely assume that my ands instruction performs r1=and(r1,0x01) with PSW setting. Many years ago I had the same bug in another assembler for a totally different processor. After a few days I will share some detail debug info. For now I will only say that my system appeared to stop working. And nothing I remembered doing should have had any effect. -Peter

Why not start with a $1 CPU. Get a PIC 16F57. It has all of 80 bytes of RAM and more than enough code space to do something useful with all that RAM. I wrote firmware for a pellet stove - in assembly - on that CPU. And Microchip has a free IDE for that and most of the chips they make. There is more to assembly than x86. I have written assembly in the IBM 1620, 1440, 7090/94. I wrote floppy disk controller PCB firmware firmware on an 8085 and plotter firmware on a Z80. Large OS code for both CP & PP on CDC 6000/Cyber 70 - all in assembly. -Peter Butler

If you want the elements themselves simply sort your list. If you also need the original index values you will have to sort element numbers along with the elements. After sorting the problem becomes trivial.

This hysteresis would prevent rapid chattering. But restart would begin from 93C. This would feed pellets at a high rate into an already hot burn pot. The auto-start heater would turn on but given that the fire is still burning the heater is a nop. Once the stove reached 95C again the pellet feed would stop and restart would be aborted. Restart would start again at 93C. The stove would be running hot with an improper fuel / air mixture. Not good. My fix (being tested as I write this) is to pause the “we don’t need to restart timer” when the stove is in an overheat situation. Thus when the temperature drops below the official definition of overheat the stove resumes normal operation.

I agree with Cees Meijer 100%. The world is analog. Disk drive recording / read channels are analog. I have a Silicon Valley hardware engineer friend who is VERY fussy about analog circuits. Unless reminded of cost and actual requirements he fails to consider the concept of “good enough.” Had he designed the PCB and specified the sensors, this totally unintended feedback would never have happened. But the only thing I could change in my client’s existing product was the controller code. Indeed, I would rather use a microcontroller with interrupts and more than a 2 level stack. When I agreed to do this code I knew what the PIC16C57 (OTP version) could and could not do. I bought PIC16F57 (flash version) parts and added wires to the existing PCB so I could flash in place. Better sensors would cost more and every dollar the product does not cost to make is important. A redesign of the 15-year-old PCB is certainly called for. Example: their PCB uses two serial load parallel output parts with R2R ladders with individual resistors to set analog voltages for motor control. Modern components would go a long way to pull cost out of the product. And it would be easier to write the controller code. I asked for a complete description of what the microcontroller would see and what it was supposed to do about what it saw. The company owner did not know that the only time the LEDs next to the user mode selection buttons would flash is when the pellet heater was turned on. It has been a slow process.

Thanks for the comment. Try kicking up the text size. (^+ in Mozilla.) I will have to try reading my stuff in IE on a display set well below the 1600x1200 I use on my machine. I use ^+ with many sites. High res, small display 65yo eyeballs....

I write embedded code for devices that don’t look like computers. A LITTLE BACKGROUND My client is in the Los Angeles, California area. I live in the Silicon Valley area just south of San Francisco Bay. It takes 6 hours driving to go between the two locations. (More if LA traffic is its usual horrible mess.) If all goes well I will never meet my client face to face. I will, however, see his signature on a check. I am replacing the software that controls a pellet stove. Once the stove is fired up and running I use a timer to be forgiving about accidental pressing of stop or other non run button. If the stove is out of run mode for >60 seconds the stove will restart when a run mode button is pressed. Fewer than 60 seconds and I simply return to the already up and running mode. Part of restarting - if I need to restart - is saving the current temperature + 15C as the target temperature. Another part is turning on the 350-Watt heater used to ignite pellets. A STRANGE PROBLEM With the controller code all but done a client employee started a stove using my code. It worked well until the relay used to control the heater started going crazy. He tried the existing code that I am replacing. No chatter. Back to my code. No chatter. I spent the weekend staring at my code trying to find some kind of stupid bug. On Monday the owner of the company fired up a stove with my code and finally got the problem to reproduce. The heater relay chattered randomly about 10 clicks in 20 seconds. With sometimes 5 clicks in 2 seconds. WTF! There is simply NO WAY my code can do that! A DESIGN ISSUE There were two problems. One was a bit of a software design issue the other was hardware. But any fix, quite naturally, has to be software. The design issue is related to 95C and up is over temperature. When that point is reached I stop the pellet (fuel) feed motor and put the fan into a medium speed per directions from the owner. When I stop feeding pellets I stop resetting the 60-second timer that forgives accidental pressings of the stop button. Thus 60 seconds after over temperature is reached the stove is willing to startup again as soon as we drop to 94C. Ignore the fact that 94C + 15 degrees is well into over temperature territory. HARDWARE Consider what causes the heater relay to chatter. My guess (and I’ve been doing this a long time) is that the 350 Watt heater changes the analog to digital reference voltage or the supply voltage to the LM35 temperature sensors. That hardw

http://www.hmtown.com/random.htm[^] Feel free to comment here or to PICguy@hmtown.com.

My Zeos keyboard. (The 386 that came with it is LONG gone.) I have a heavy hand and like the sound the keys make when I hunt and peck.

My only experience with any of this was quite nice. I received a call from Master Card Fraud department asking if I had ordered anything from a Colorado bicycle parts store. The bicycle parts were to be shipped to New York. (I live in Santa Clara, California – Silicon Valley.) I suggested that an exploding package be sent. No? Well, send some sort of package and the local cops. I had to change my card number but that was it.