text:
For novel ideas about building embedded systems (both hardware and firmware), join the 40,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe. |
Great Watchdog Timers For Embedded Systems
By Jack Ganssle
Sept 2011 - updated
July 2016 - Added reference to Niall Murphy article
Launched in January of 1994, the Clementine spacecraft spent two very successful months mapping the moon before leaving lunar orbit to head towards near-Earth asteroid Geographos.
A dual-processor Honeywell 1750 system handled telemetry and various spacecraft functions. Though the 1750 could control Clementine's thrusters, it did so only in emergency situations; all routine thruster operations were under ground control.
On May 7, 1994, the 1750 experienced a floating point exception. This wasn't unusual; some 3000 prior exceptions had been detected and handled properly. But immediately after the May 7 event downlinked data started varying wildly and nonsensically. Then the data froze. Controllers spent 20 minutes trying to bring the system back to life by sending software resets to the 1750; all were ignored. A hardware reset command finally brought Clementine back on-line.
Alive, yes, even communicating with the ground, but with virtually no fuel left.
The evidence suggests that the 1750 locked up, probably due to a software crash. While hung the processor turned on one or more thrusters, dumping fuel and setting the spacecraft spinning at 80 RPM. In other words, it appears the code ran wild, firing thrusters it should never have enabled; they kept firing till the tanks ran nearly dry and the hardware reset closed the valves.
The mission to Geographos had to be abandoned.
Designers had worried about this sort of problem and implemented a software thruster timeout. That, of course, failed when the firmware hung.
The 1750's built-in watchdog timer hardware was not used, over the objections of the lead software designer. With no automatic "reset" button, success of the mission rested in the abilities of the controllers on Earth to detect problems quickly and send a hardware reset. For the lack of a few lines of watchdog code the mission was lost.
Though such a fuel dump had never occurred on Clementine before, roughly 16 times before the May 7 event hardware resets from the ground had been required to bring the spacecraft's firmware back to life. One might also wonder why some 3000 previous floating point exceptions were part of the mission's normal firmware profile.
Not surprisingly, the software team wished they had indeed used the watchdog timer, and had not implemented the thruster timeout in firmware. They also noted, though, that a normal, simple, watchdog may not have been robust enough to catch the failure mode.
Contrast this with Pathfinder, a mission whose software also famously hung, but which was saved by a reliable watchdog. The software team found and fixed the bug, uploading new code to a target system 40 million miles away, enabling an amazing roving scientific mission on Mars.
Watchdog timers (WDTs) are our failsafe, our last line of defense, an option taken only when all else fails - right? These missions (Clementine had been reset 16 times prior to the failure) and so many others suggest to me that WDTs are not emergency outs, but integral parts of our systems. The WDT is as important as main() or the runtime library, it's an asset that is likely to be used, and maybe used a lot.
Outer space is a hostile environment, of course, with high intensity radiation fields, thermal extremes and vibrations we'd never see on Earth. Do we have these worries when designing Earth-bound systems?
Maybe so. Intel revealed that the McKinley processor's ultra fine design rules and huge transistor budget means cosmic rays may flip on-chip bits. The Itanium 2 processor, also sporting an astronomical transistor budget and small geometry, includes an on-board system management unit to handle transient hardware failures. The hardware ain't what it used to be - even if our software were perfect.
But too much (all?) firmware is not perfect. Consider this unfortunately true story from Ed VanderPloeg:
"The world has reached a new embedded software milestone: I had to reboot my hood fan. That's right, the range exhaust fan in the kitchen. It's a simple model from a popular North American company. It has six buttons on the front: 3 for low, medium, and high fan speeds and 3 more for low, medium, and high light levels. Press a button once and the hood fan does what the button says. Press the same button again and the fan or lights turn off. That's it. Nothing fancy. And it needed rebooting via the breaker panel."
"Apparently the thing has a micro to control the light levels and fan speeds, and it also has a temperature sensor to automatically switch the fan to high speed if the temperature exceeds some fixed threshold. Well, one day we were cooking dinner as usual, steaming a pot of potatoes, and suddenly the fan kicks into high speed and the lights start flashing. "Hmm, flaky sensor or buggy sensor software", I think to myself."
"The food happened to be done so I turned off the stove and tried to turn off the fan, but I suppose it wanted things to cool off first. Fine. So after ten minutes or so the fan and lights turned off on their own. I then went to turn on the lights, but instead they flashed continuously, with the flash rate depending on the brightness level I selected."
"So just for fun I tried turning on the fan, but any of the three fan speed buttons produced only high speed. "What 'smart' feature is this?", I wondered to myself. Maybe it needed to rest a while. So I turned off the fan & lights and went back to finish my dinner. For the rest of the evening the fan & lights would turn on and off at random intervals and random levels, so I gave up on the idea that it would self-correct. So with a heavy heart I went over to the breaker panel, flipped the hood fan breaker to & fro, and the hood fan was once again well-behaved."
"For the next few days, my wife said that I was moping around as if someone had died. I would tell everyone I met, even complete strangers, about what happened: "Hey, know what? I had to reboot my hood fan the other night!". The responses were varied, ranging from "Freak!" to "Sounds like what happened to my toaster...". Fellow programmers would either chuckle or stare in common disbelief."
"What's the embedded world coming to? Will programmers and companies everywhere realize the cost of their mistakes and clean up their act? Or will the entire world become accustomed to occasionally rebooting everything they own? Would the expensive embedded devices then come with a "reset" button, advertised as a feature? Or will programmer jokes become as common and ruthless as lawyer jokes? I wish I knew the answer. I can only hope for the best, but I fear the worst."
One developer admitted to me that his consumer products company could care less about the correctness of firmware. Reboot - who cares? Customers are used to this, trained by decades of desktop computer disappointments. Hit the reset switch, cycle power, remove the batteries for 15 minutes, even pre-teens know the tricks of coping with legions of embedded devices.
Suggestion: Subscribe to my free newsletter which often covers watchdogs and similar subjects. |
Crummy firmware is the norm, but in my opinion is totally unacceptable. Shipping a defective product in any other field is like opening the door to torts. So far the embedded world has been mostly immune from predatory lawyers, but that Brigadoon-like isolation is unlikely to continue. Besides, it's simply unethical to produce junk.
But it's hard, even impossible, to produce perfect firmware. We must strive to make the code correct, but also design our systems to cleanly handle failures. In other words, a healthy dose of paranoia leads to better systems.
A Watchdog Timer is an important line of defense in making reliable products. Decent embedded systems design means that, if your system needs a WDT, it better be of exceptionally high quality.
Well-designed watchdog timers fire off a lot, daily and quietly saving systems and lives without the esteem offered to other, human, heroes. Perhaps the developers producing such reliable WDTs deserve a parade. Poorly-designed WDTs fire off a lot, too, sometimes saving things, sometimes making them worse. A simple-minded watchdog implemented in a non-safety critical system won't threaten health or lives, but can result in systems that hang and do strange things that tick off our customers. No business can tolerate unhappy customers, so unless your code is perfect (whose is?) it's best in all but the most cost-sensitive apps to build a really great WDT.
An effective WDT is far more than a timer that drives reset. Such simplicity might have saved Clementine, but would it fire when the code tumbles into a really weird mode like that experienced by Ed's hood fan?
Internal WDTs
Internal watchdogs are those that are built into the processor chip. Virtually all highly integrated embedded processors include a wealth of peripherals, often with some sort of watchdog. Most are brain-dead watchdog timers suitable for only the lowest-end applications.
Let's look at a few.
Some of TI's Stellaris series of ARM controllers, like the LM4F110B2QR (how's that for a part number!) have a lock out register. Program the right code into register WDTLOCK and the code cannot change any WDT control register. That's a great feature! Alas, it's easy enough to unlock the WDT registers. A pessimist will note that a program running insanely could simply disable the watchdog.
Toshiba's TMP96141AF is part of their TLCS-900 family of quite nice microprocessors, which offers a wide range of extremely versatile on-board peripherals. All have pretty much the same watchdog circuit. As the data sheet says, "The TMP96141AF is containing watchdog timer of Runaway detecting."
Ahem. And I thought the days of Jinglish were over. Anyway, the part generates a non-maskable interrupt when the watchdog times out, which is either a very, very bad idea or a wonderfully clever one. It's clever only if the system produces an NMI, waits a while, and only then asserts reset, which the Toshiba part unhappily cannot do. Reset and NMI are synchronous.
A nice feature is that it takes two different I/O operations to disable the watchdog timer, so there are slim chances of a runaway program turning off this protective feature.
Motorola's widely-used 68332 variant of their CPU32 family (like most of these 68k embedded parts) also includes a watchdog. It's a simple-minded thing meant for low-reliability applications only. Unlike a lot of WDTs, user code must write two different values (0x55 and 0xaa) to the WDT control register to ensure the device does not time out. This is a very good thing - it limits the chances of rogue software accidentally issuing the command needed to appease the watchdog. I'm not thrilled with the fact that any amount of time may elapse between the two writes (up to the timeout period). Two back-to-back writes would further reduce the chances of random watchdog tickles, though once would have to ensure no interrupt could preempt the paired writes. And the 0x55/0xaa twosome is often used in RAM tests; since the 68k I/O registers are memory mapped, a runaway RAM test could keep the device from resetting.
The 68332's WDT drives reset, not some exception handling interrupt or NMI. This makes a lot of sense, since any software failure that causes the stack pointer to go odd will crash the code, and a further exception-handling interrupt of any sort would drive the part into a "double bus fault". The hardware is such that it takes a reset to exit this condition.
Motorola's popular Coldfire parts are similar. The MCF5204, for instance, will let the code write to the WDT control registers only once. Cool! Crashing code, which might do all sorts of silly things, cannot reprogram the protective mechanism. However, it's possible to change the reset interrupt vector at any time, pretty much invalidating the clever write-once design.
Like the CPU32 parts a 0x55/0xaa sequence keeps the WDT from timing out, and back-to-back writes aren't required. The Coldfire datasheet touts this as an advantage since it can handle interrupts between the two tickle instructions, but I'd prefer less of a window. The Coldfire has a fault-on-fault condition much like the CPU32's double bus fault, so reset is also the only option when watchdog timer fires - which is a good thing.
There's no external indication that the WDT timed out, perhaps to save pins. That means your hardware/software must be designed so at a warm boot the code can issue a from-the-ground-up reset to every peripheral to clear weird modes that may accompany a WDT timeout.
Philip's XA processors require two sequential writes of 0xa5 and 0x5a to the WDT. But like the Coldfire there's no external indication of a timeout, and it appears the watchdog reset isn't even a complete CPU restart - the docs suggest it's just a reload of the program counter. Yikes - what if the processor's internal states were in disarray from code running amok or a hardware glitch?
External Watchdog Timers
Many of the supervisory chips we buy to manage a processor's reset line include built-in WDTs.
TI's UCC3946 is one of many nice power supervisor parts that does an excellent job of driving reset only when Vcc is legal. In a nice small 8 pin SMT package it eats practically no PCB real estate. It's not connected to the CPU's clock, so the WDT will output a reset to the hardware safe-ing mechanisms even if there's a crystal failure. But it's too darn simple: to avoid a timeout just wiggle the input bit once in a while. Crashed code could do this in any of a million ways.
TI isn't the only purveyor of simplistic WDTs. Maxim's MAX823 and many other versions are similar. The catalogs of a dozen other vendors list equally dull and ineffective watchdogs.
But both TI and Maxim do offer more sophisticated devices. Consider TI's TPS3813 and Maxim's MAX6323. Both are "Window Watchdogs". Unlike the internal versions described above that avoid timeouts using two different data writes (like a 0x55 and then 0xaa), these require tickling within certain time bands. Toggle the WDT input too slowly, too fast, or not at all, and a timeout will occur. That greatly reduces the chances that a program run amok will create the precise timing needed to satisfy the watchdog. Since a crashed program will likely speed up or bog down if it does anything at all, errant strobing of the tickle bit will almost certainly be outside the time band required.
Characteristics of Great Watchdog Timers
What's the rationale behind an awesome watchdog timer? The perfect WDT should detect all erratic and insane software modes. It must not make any assumptions about the condition of the software or the hardware; in the real world anything that can go wrong will. It must bring the system back to normal operation no matter what went wrong, whether from a software defect, RAM glitch, or bit flip from cosmic rays.
It's impossible to recover from a hardware failure that keeps the computer from running properly, but at the least the WDT must put the system into a safe state. Finally, it should leave breadcrumbs behind, generating debug information for the developers. After all, a watchdog timeout is the yin and yang of an embedded system. It saves the system, keeping customers happy, yet demonstrates an inherent design flaw that should be addressed. Without debug info, troubleshooting these infrequent and erratic events is close to impossible.
What does this mean in practice?
An effective watchdog is independent from the main system. Though all WDTs are a blend of interacting hardware and software, something external to the processor must always be poised, like the sword of Damocles, ready to intervene as soon as a crash occurs. Pure software implementations are simply not reliable.
There's only one kind of intervention that's effective: an immediate reset to the processor and all connected peripherals. Many embedded systems have a watchdog that initiates a non-maskable interrupt. Designers figure that firing off NMI rather than reset preserves some of the system's context. It's easy to seed debugging assets in the NMI handler (like a stack capture) to aid in resolving the crash's root cause. That's a great idea, except that it does not work.
All we really know when the WDT fires is that something truly awful happened. Software bug? Perhaps. Hardware glitch? Also possible. Can you ensure that the error wasn't something that totally scrambled the processor's internal logic states? I worked with one system where a motor in another room induced so much EMF that our instrument sometimes went bonkers. We tracked this down to a sub-nanosecond glitch on one CPU input, a glitch so short that the processor went into an undocumented weird mode. Only a reset brought it back to life.
Some CPUs, notably the 68k and ColdFire, will throw an exception if a software crash causes the stack pointer to go odd. That's not bad . . . except that any watchdog circuit that then drives the CPU's non-maskable interrupt will unavoidably invoke code that pushes the system's context, creating a second stack fault. The CPU halts, staying halted till a reset, and only a reset, comes along.
Don't forget to reset the whole computer system; a simple CPU restart may not be enough. Are the peripherals absolutely, positively, in a sane mode? Maybe not. Runaway code may have issued all sorts of I/O instructions that placed complex devices in insane modes. Give every peripheral a hardware reset; software resets may get lost in all of the I/O chatter.
Consider what the system must do to be totally safe after a failure. Maybe a pacemaker needs to reboot in a heartbeat (so to speak) . . . or maybe backup hardware should issue a few ticks if reboots are slow.
One thickness gauge that beams high energy gamma rays through 4 inches of hot steel failed in a spectacular way. Defective hardware crashed the code. The watchdog properly closed the protective lead shutter, blocking off the 5 curie cesium source. I was present, and watched incredulously as the engineering VP put his head in path of the beam; the crashed code, still executing something, tricked the watchdog into opening the shutter, beaming high intensity radiation through the veep's forehead. I wonder to this day what eventually became of the man.
A really effective watchdog cannot use the CPU's clock, which may fail. A bad solder joint on the crystal, poor design that doesn't work well over temperature extremes, or numerous other problems can shut down the oscillator. This suggests that no WDT internal to the CPU is really safe. Most share the processor's clock.
Under no circumstances should the software be able to reprogram the WDT or any of its necessary components (like reset vectors, I/O pins used by the watchdog, etc). Assume runaway code runs under the guidance of a malevolent deity.
Build a watchdog that monitors the entire system's operation. Don't assume that things are fine just because some loop or ISR runs often enough to tickle the watchdog timer. A software-only watchdog should look at a variety of parameters to ensure the product is healthy, kicking the dog only if everything is OK. What is a software crash, after all? Occasionally the system executes a HALT and stops, but more often the code vectors off to a random location, continuing to run instructions. Maybe only one task crashed. Perhaps only one is still alive - no doubt that which kicks the dog.
Think about what can go wrong in your system. Take corrective action when that's possible, but initiate a reset when it's not. For instance, can your system recover from exceptions like floating point overflows or divides by zero? If not, these conditions may well signal the early stages of a crash. Either handle these competently or initiate a WDT timeout. For the cost of a handful of lines of code you may keep a 60 Minutes camera crew from appearing at your door.
It's a good idea to flash an LED or otherwise indicate that the WDT kicked. A lot of devices automatically recover from timeouts; they quickly come back to life with the customer totally unaware a crash occurred. Unless you have a debug LED how do you know if your precious creation is working properly, or occasionally invisibly resetting? One outfit complained that over time, and with several thousand units in the field, their product's response time to user inputs degraded noticeably. A bit of research showed that their system's watchdog properly drove the CPU's reset signal, and the code then recognized a warm boot, going directly to the application with no indication to the users that the time-out had occurred. We tracked the problem down to a floating input on the CPU, that caused the software to crash - up to several thousand times per second. The processor was spending most of its time resetting, leading to apparently slow user response. An LED would have shown the problem during debug, long before customers started yelling.
Everyone knows we should include a jumper to disable the WDT during debugging. But few folks think this through. The jumper should be inserted to enable debugging, and removed for normal operation. Otherwise if manufacturing forgets to install the jumper, or if it falls out during shipment, the WDT won't function. And there's no production test to check the watchdog's operation.
Design the logic so the jumper disconnects the watchdog timer from the reset line (possibly though an inverter so an inserted jumper sets debug mode). Then the watchdog continues to function even while debugging the system. It won't reset the processor but will flash the LED. The light will blink a lot when breakpointing and singlestepping, but should never come on during full-speed testing.
Using an Internal Watchdog Timer
Most embedded processors that include high integration peripherals have some sort of built-in WDT. Avoid these except in the most cost-sensitive or benign systems. Internal units offer minimal protection from rogue code. Runaway software may reprogram the WDT controller, many internal watchdogs will not generate a proper reset, and any failure of the processor will make it impossible to put the hardware into a safe state. A great WDT must be independent of the CPU it's trying to protect.
However, in systems that really must use the internal versions, there's plenty we can do to make them more reliable. The conventional model of kicking a simple timer at erratic intervals is too easily spoofed by runaway code.
A pair of design rules leads to decent WDTs: kick the dog only after your code has done several unrelated good things, and make sure that erratic execution streams that wander into your watchdog routine won't issue incorrect tickles.
This is a great place to use a simple state machine. Suppose we define a global variable named "state". At the beginning of the main loop set state to 0x5555. Call watchdog routine A, which adds an offset - say 0x1111 - to state and then insures the variable is now 0x6666. Return if the compare matches; otherwise halt or take other action that will cause the WDT to fire.
Later, maybe at the end of the main loop, add another offset to state, say 0x2222. Call watchdog routine B, which makes sure state is now 0x8888. Set state to zero. Kick the dog if the compare worked. Return. Halt otherwise.
Suppose the code crashes and for inscrutable reasons probably having to do with Murphy's Law and the perversity of nature vectors into wdt_b() just before the kick_dog command. The protection mechanism of the state machine won't help.
Perhaps it's safe to assume that the code will again crash when wdt_b() returns, so the system will miss the next watchdog tickle. But. . . . perhaps not - who knows what evil lurks in the mind of runaway software?
Is this fear paranoid? You bet. But the WDT might be the last line of defense between deflecting the Earth-bound asteroid and utter disaster, or at least in rebooting the pacemaker before grandpa collapses. Assuming that crashed code will operate in any benign mode is na�ve.
So wdt_b() double-checks variable "state" to ensure the system halts (so the watchdog can issue a reset) even if rogue code wandered into wdt_b() just before issuing the kick_dog.
This is a trivial bit of code, but now runaway code that stumbles into any of the tickling routines cannot errantly kick the dog. Further, no tickles will occur unless the entire main loop executes in the proper sequence. If the code just calls routine B repeatedly, no tickles will occur because it sets state to zero before exiting.
Add additional intermediate states as your fear of litigation dictates.
Normally I detest global variables, but this is a perfect application. Cruddy code that mucks with the variable, errant tasks doing strange things, or any error that steps on the global will make the WDT timeout.
Do put these actions in the program's main loop, not inside an ISR. It's fun to watch a multitasking product crash - the entire system might be hung, but one task still responds to interrupts. If your watchdog tickler stays alive as the world collapses around the rest of the code, then the watchdog serves no useful purpose.
If the WDT doesn't generate an external reset pulse (some processors handle the restart internally) make sure the code issues a hardware reset to all peripherals immediately after start-up. That may mean working with the EEs so an output bit resets every resettable peripheral.
If you must take action to safe dangerous hardware, well, since there's no way to guarantee the code will come back to life, stay away from internal watchdogs. Broken hardware will obviously cause this . . . but so can lousy code. A digital camera was recalled recently when users found that turning the device off when in a certain mode meant it could never be turned on again. The code wrote faulty info to flash memory that created a permanent crash.
An External Watchdog Timer
The best watchdog is one that doesn't rely on the processor or its software. It's external to the CPU, shares no resources, and is utterly simple, thus devoid of latent defects.
Use a PIC, a Z8, or other similar dirt-cheap processor as a system health monitor. These parts have an independent clock, on-board memory, and the built-in timers we need to build a truly great WDT. Being external, you can connect an output to hardware interlocks that put dangerous machinery into safe states.
But when selecting a watchdog CPU check the part's specs carefully. Tying the tickle to the watchdog CPU's interrupt input, for instance, may not work reliably. A slow part - like most PICs - may not respond to a tickle of short duration. Consider TI's MSP430 family or processors. They're a very inexpensive (half a buck or so) series of 16 bit processors that use virtually no power and no PCB real estate.
Tickle it using the same sort of state-machine described above. Like the windowed watchdogs (TI's TPS3813 and Maxim's MAX6323), define min and max tickle intervals, to further limit the chances that a runaway program deludes the WDT into avoiding a reset.
Perhaps it seems extreme to add an entire computer just for the sake of a decent watchdog. We'd be fools to add extra hardware to a highly cost-constrained product. Most of us, though, build lower volume higher margin systems. A fifty cent part that prevents the loss of an expensive mission, or that even saves the cost of one customer support call, might make a lot of sense.
In a multiprocessor system it's easy to turn all of the processors into watchdogs. Have them exchange "I'm OK" messages periodically. The receiver resets the transmitter if it stops speaking. This approach checks a lot of hardware and software, and requires little circuitry.
Watchdog Timers for Multitasking
Tasking turns a linear bit of software into a multidimensional mix of tasks competing for processor time. Each runs more or less independently of the others. . . which means each can crash on its own, without bringing the entire system to its knees.
You can learn a lot about a system's design just be observing its operation. Consider a simple instrument with a display and various buttons. Press a button and hold it down; if the display continues to update, odds are the system multitasks.
Yet in the same system a software crash might go undetected by conventional watchdog strategies. If the display or keyboard tasks die, the main line code or a WDT task may continue to run.
Any system that uses an ISR or a special task to tickle the watchdog but that does not examine the health of all other tasks is not robust. Success lies in weaving the watchdog into the fabric of all of the system's tasks - which is happily much easier than it sounds.
First, build a watchdog task. It's the only part of the software allowed to tickle the WDT. If your system has an MMU mask off all I/O accesses to the WDT except those from this task, so rogue code traps on an errant attempt to output to the watchdog.
Next, create a data structure that has one entry per task, with each entry being just an integer.
When a task starts it increments its entry in the structure. Tasks that only start once and stay active forever can increment the appropriate value each time through their main loops.
Increment the data atomically - in a way that cannot be interrupted with the data half-changed. ++TASKi (if TASK is an integer array) on an 8 bit CPU might not be atomic, though it's almost certainly OK on a 16 or 32 bitter. The safest way to both encapsulate and ensure atomic access to the data structure is to hide it behind another task. Use a semaphore to eliminate concurrent shared accesses. Send increment messages to the task, using the RTOS's messaging resources.
As the program runs the number of counts for each task advances. Infrequently but at regular intervals the watchdog task runs. Perhaps once a second, or maybe once a msec - it's all a function of your paranoia and the implications of a failure.
The watchdog task scans the structure, checking that the count stored for each task is reasonable. One that runs often should have a high count; another which executes infrequently will produce a smaller value. Part of the trick is determining what's reasonable for each task; stick with me - we'll look at that shortly.
If the counts are unreasonable, halt and let the watchdog timeout. If everything is OK, set all of the counts to zero and exit.
Why is this robust? Obviously, the watchdog monitors every task in the system. But it's also impossible for code that's running amok to stumble into the watchdog timer task and errantly tickle the dog; by zeroing the array we guarantee it's in a "bad" state.
I skipped over a critical step - how do we decide what's a reasonable count for each task? It might be possible to determine this analytically. If the WDT task runs once a second, and one of the monitored tasks starts every 50 msec, then surely a count of around 20 is reasonable.
Other activities are much harder to ascertain. What about a task that responds to asynchronous inputs from other computers, say data packets that come at irregular intervals? Even in cases of periodic events, if these drive a low-priority task they maybe suspended for rather long intervals by higher-priority problems.
The solution is to broaden the data structure that maintains count information. Add min and max fields to each entry. Each task must run at least min, but no more than max times.
Now redesign the watchdog task to run in one of two modes. The first is the one already described, and is used during normal system operation.
The second mode is a debug environment enabled by a compile-time switch that collects min and max data. Each time the WDT task runs it looks at the incremented counts and sets new min and max values as needed. It tickles the watchdog each time it executes.
Run the product's full test suite with this mode enabled. Maybe the system needs to operate for a day or a week to get a decent profile of the min/max values. When you're satisfied that the tests are representative of the system's real operation, manually examine the collected data and adjust the parameters as seems necessary to give adequate margins to the data.
What a pain! But by taking this step you'll get a great watchdog - and a deep look into your system's timing. I've observed that few developers have much sense how their creations perform in the time domain. "It seems to work" tells us little. Looking at the data acquired by this profiling, though might tell a lot. Is it a surprise that task A runs 400 times a second? That might explain a previously-unknown performance bottleneck.
In a real time system we must manage and measure time; it's every bit as important as procedural issues, yet is oft ignored till a nagging problem turns into an unacceptable symptom. This watchdog scheme forces you to think in the time domain, and by its nature profiles - admittedly with coarse granularity - the time-operation of your system.
There's yet one more kink, though. Some tasks run so infrequently or erratically that any sort of automated profiling will fail. A watchdog that runs once a second will miss tasks that start only hourly. It's not unreasonable to exclude these from watchdog monitoring. Or, we can add a bit of complexity to the code to initiate a watchdog timeout if, say, the slow tasks don't start even after a number of hours elapse.
Some Decent WDTs on MCUs
MCU watchdogs are getting better. For instance Freescale's 32 bit Coldfire+ line, like the MCF51Qx. Instead of "watchdog" Freescale prefers the awkward phrase "Computer Acting Properly" (COP). But it does offer a very intriguing feature. In general, one pets the watchdog, uh, COP, by writing 0x55 and then 0xaa to the control register. But in one mode that sequence must be sent in the last 25% of the COP timeout period. A premature write results in a reset. Odds of a errant program getting the timing Goldilocks-correct (not too often, nor too infrequently) are tiny.
The part also generates a reset is any attempt is made to execute an illegal instruction. That's somewhat different from most CPUs, which issue an illegal op code interrupt. I rather like Freescale's approach, since interrupt handlers are not guaranteed to work if the code crashes. A blown stack, corrupt PC (on some CPUs if the PC is odd a fault is taken), or a vector base register changes. This also suggests that it's a good idea to fill unused flash at link time with an illegal op code, and on power-up fill all of RAM with a similar instruction, so that errant code waltzing through memory is likely to generate a reset.
Another nice touch is that the reset pin is open drain and is asserted when any of these errors occur. Tie it to the peripheral reset inputs. Even if wandering code issues output instructions their potentially scrambled little brains will be straightened out.
ST Microelectronics has a line of Cortex-M3 devices. The M3 has become extremely popular for lower-end embedded devices, and ST's STM32F is representative of these parts (though the WDT is an ST add-on, and does not necessarily mirror other vendors' implementations). The STM32F has two different protection mechanisms. An "Independent Watchdog" is a pretty vanilla design that has little going for it other than ease of use. But their Window Watchdog offers more robust protection. When a countdown timer expires, a reset is generated, which can be impeded by reloading the timer. Nothing special there. But if the reload happens too quickly, the system will also reset. In this case "too quickly" is determined by a value one programs into a control register.
Another cool feature: it can generate an interrupt just before resetting. Write a bit of code to snag the interrupt and you can take some action to, for instance, put the system in a safe state or to snapshot data for debugging purposes. ST suggests using the ISR to reload the watchdog -- that is, kick the dog so a reset does not occur. Don't take their advice. If the program crashes the interrupt handlers may very well continue to function normally. And using an ISR to reload the WDT invalidates the entire reason for a window watchdog.
The WDT cannot be disabled once enabled -- good thinking, folks! But oddly, the other configuration registers can be changed at will, which can make the watchdog behave incorrectly.
Summary and Other Thoughts
For some thoughts on the possible future of watchdogs, see this.
I remain troubled by the fan failure described earlier. It's easy to dismiss this as a glitch, an unexplained failure caused by a hardware or software bug, cosmic rays, or meddling by aliens. But others have written about identical situations with their vent fans, all apparently made by the same vendor.
When we blow off a failure, calling it a "glitch" as if that name explains something, we're basically professing our ignorance. There are no glitches in our macroscopically deterministic world. Things happen for a reason.
The fan failures didn't make the evening news and hurt no one. So why worry?
Surely the customers were irritated, and the possible future sales of that company at least somewhat diminished. The company escalated the general rudeness level of the world, and thus the sum total incipient anger level, by treating their customers with contempt. Maybe a couple more Valiums were popped, a few spouses yelled at, some kids cowered till dad calmed down. In the grand scheme of things perhaps these are insignificant blips. Yet we must remember the purpose of embedded control is to help people, to improve lives, not to help therapists garner new patients.
What concerns me is that if we cannot even build reliable fan controllers, what hope is there for more mission-critical applications?
I don't know what went wrong with those fan controllers, and I have no idea if a watchdog timer - well designed or not - is part of the system. I do know, though, that the failures are unacceptable and avoidable. But maybe not avoidable by the use of a conventional watchdog. A WDT tells us the code is running. A windowing WDT tells us it's running with pretty much the right timing. No watchdog, though, flags software executing with corrupt data structures, unless the data is so bad it grossly affects the execution stream.
Why would a data structure become corrupt? Bugs, surely. Strange conditions the designers never anticipated will also create problems, like the never-ending flood of buffer overflow conditions that plague the net, or unexpected user inputs ("we never thought the user would press all 4 buttons at the same time!").
Is another layer of self-defense, beyond watchdogs, wise? Safety critical apps, where the cost of a failure is frighteningly high, should definitely include integrity checks on the data. Low threat equipment - like this oven fan - can and should have at least a minimal amount of code for trapping possible failure conditions.
Some might argue it makes no sense to "waste" time writing defensive code for a dumb fan application. Yet the simpler the system, the easier and quicker it is to plug in a bit of code to look for program and data errors.
Very simple systems tend to translate inputs to outputs. Their primary data structures are the I/O ports. Often several unrelated output bits get multiplexed to a single port. To change one bit means either reading the port's current status, or maintaining a copy of the port in RAM. Both approaches are problematic.
Computers are deterministic, so it's reasonable to expect that, in the absence of bugs, they'll produce correct results all the time. So it's apparently safe to read a port's current status, AND off the unwanted bits, OR in new ones, and output the result. This is a state machine; the outputs evolve over time to deal with changing inputs. But the process works only if the state machine never incorrectly flips a bit. Unfortunately, output ports are connected to the hostile environment of the real world. It's entirely possible that a bit of energy from starting the fan's highly inductive motor will alter the port's setting. I've seen this happen many times.
So maybe it's more reliable to maintain a memory image of the port. The downside is that a program bug might corrupt the image. Most of the time these are stored as global variables, so any bit of sloppy code can accidentally trash the location. Encapsulation solves that problem, but not the one of a wandering pointer walking over the data, or of a latent reentrancy issue corrupting things. You might argue that writing correct code means we shouldn't worry about a location changing, but we added a WDT to, in part, deal with bugs. Similar concerns about our data are warranted.
In a simple system look for a design that resets data structures from time to time. In the case of the oven fan, whenever the user selects a fan speed reset all I/O ports and data structures. It's that simple.
In a more complicated system the best approach is the oldest trick in software engineering: check the parameters passed to functions for reasonableness. In the embedded world we chose not to do this for three reasons: speed, memory costs, and laziness. Of these, the third reason is the real culprit most of the time.
Niall Murphy has an excellent article about watchdogs.


text:
Thank you for stopping by - and for your interest in learning more about us!
We started as a retail photo lab in Midland, Texas as a processor of photo prints. After many successful years in the business, we introduced our FreePrints mobile app to solve a seemingly obvious problem: All of our most important photos live on our phones and tablets, and yet there's never been an easy way to get them printed. After one too many fights with USB sticks, photo kiosks and unreliable retailer websites, we set out to solve the problem: Enter FreePrints. We always had great expectations for our app, but we never anticipated the community that would evolve around it.
We want to welcome you to the growing FreePrints family. We're glad you're here! We believe you'll find our apps, products and services to be the very best in the business. We're humbled by a recent survey ranking FreePrints #1 among the world's 137 photo printing apps. We hope you enjoy using FreePrints!

subset: commoncrawl


text:
We would like to hear from you, although we cannot represent you until we know that doing so will not create a conflict of interest. Also, we cannot treat unsolicited information as confidential. Accordingly, please do not send us any information about any matter that may involve you until you receive a written statement from us that we represent you (an "engagement letter").
The best way for you to initiate a possible representation is to call our Business Development team at 617-439-2314. They will first take you through our conflict of interest procedure and see that you are put in touch with the lawyer best suited to handle your matter. When you receive an engagement letter from that lawyer, you will be our client, and we may exchange information freely.
By submitting this form you agree that we may review any information you transmit to us. You recognize that our review of your information, even if you submitted it in a good faith effort to retain us, and, further, even if it is confidential, does not preclude us from representing another client directly adverse to you, even in a matter where that information could and will be used against you. All information submitted to Nutter via this Web site shall be deemed and remain the property of Nutter, and Nutter shall be free to use, for any purpose, any ideas, concepts, know-how, or techniques contained in information a visitor provides to Nutter through this Web site.
Seaport West |
1471 Iyannough Road |
In this blog, Nutter's Executive Compensation and Employee Benefits attorneys will provide updates on key developments and offer practical tips and best practices relating to executive compensation, employee benefits, and corporate governance matters.


text:
The Weekender in SHARK
- Regular price
$163.00 - Regular price
$163.00 - Sale price
Your go to bag for a spontaneous weekend getaway or a long anticipated adventure. Large enough to carry clothes and necessities for several days. The perfect bag for weekend road trips. Also styles well as an oversized daily use bag.
Two short duffel handles for handheld carrying. Two long shoulder straps to carry tote style.
Made from durable and water resistant cotton canvas and lined in soft brushed canvas.
Two deep slip pockets 7"w x 9"d
One wide zip pocket 14"w x 9"d
One key clip
24"w x 15.5"t x 8"d
Waxed canvas exterior
Soft brushed cotton interior
Heavy waxed canvas bottom
Highly water resistant
1. Where is this made
Every Moop bag is designed and small batch manufactured in Seattle, Washington. For over 15 years, we have been producing bags designed for your day to day use. US made, small batch manufactured, made from durable materials, built to hold up for years on end. Born in Western Massachusetts, raised in Pittsburgh, PA and now happily making bags in Seattle, WA.
est: 2007
2. About our fabrics
Waxed Canvas
100% cotton canvas has wax integrated into the fibers during the weaving process and finished with a top coat of wax for added water resistance. Waxed canvas has a distressed look that will age and change over time. We source ours from a 7th generation family owned and operated manufacturer, an industry leader in coated fabrics. Waxed canvas was originally developed in the late 1800's for long shore fishermen who needed to stay warm and dry. We like that legacy.Water resistance: High
Water Resistant Canvas
100% cotton canvas. Much like waxed canvas, a water resistant coating is integrated into the fibers during the weaving process but, there is no top coat wax finish. This results in a surface that is only slightly distressed and will look the same, day in and day out. It has a water resistant coating which makes it extremely durable and able to withstand the elements, keeping the contents of your bag dry.Water resistance: High
Corded Canvas
100% cotton canvas with a corded weave. Corded canvas is similar to corduroy only it has no pile, does not pill and breaks in like your favorite denim. Corded canvas has not been treated with any water resistant coatings.
Water Resistance: low
Brushed Canvas
100% cotton canvas with a slightly brushed surface. Soft to the touch. Our brushed canvas has not been treated with any water resistant coatings.Water resistance: low
Cordura® is a high performance, highly water resistant fabric. It is light weight, extremely durable and will not absorb water. We use Cordura® brand nylon which is all made in the USA.Water Resistance: High
Our leather comes from a handmade shoe manufacturer in upstate New York. We have partnered with them to upcycle their scraps when we can. The leather detailing may have marks and scars due to this process but, it will never lose structural integrity. Leather hides are sourced from Horween, the famous Chicago tannery founded in 1905.
Our full leather bags are made from leather we custom designed, from color to finish with a small family owned and operated tannery based in Los Angeles, CA. We had the aging process in mind with this leather. It will break in and age for each person in a slightly different way, carrying the marks of your daily life as it builds character.
Wool Felt
Our wool felt is a dense industrial wool felt. 100% merino. German milled and dyed. Felt is shock absorbent and water resistant.Made in Seattle
Sustainable / Local / Small Batch Manufacturing, all within a few miles of where we live and work.
Woman Owned
100% Female Owned.Easthampton / Pittsburgh / Seattle
Built to last
Durbale / Water Resistant / Designed for Daily Adventure / since 2007


text:
5x Sunflower Fur Pelts
5x vibrant sunshine yellow rabbit fur pelts, ethically sourced and tanned, ready for the production of clothing, accessories, hats, rugs, blankets, and so much more. The dyeing process ensures colour consistency for vibrant, ultra-soft pelts.
Average size: 30 x 40cm
Average thickness: 1.2mm
Gloriously soft and silky fur - they look as good as they feel!
Important: Source of rabbit fur skins
The rabbits are killed for the primary demand of human meat consumption and/or pest control. The breed of rabbit we source the fur from is commonly known as 'New Zealand' and 'Pardo' rabbits.As with all natural products, there will be some variation in texture and size.


text:
Custom cedar arbor to cover your patio or deck
We can build as simple or complex and ornate a gate you'd like.
Use cedar fencing to divide property and add privacy.
Cedar fencing can be stained light or dark to meet your custom specs and needs.
Cedar fencing around any shape or size yard.
Metal framed cedar gate accents your fence and provide safe, secure and sturdy access.
We can build a custom cedar gate to blend well with your new cedar fence.
Cedar gates with or without arbors to match your needs.
Cedar fencing provides excellent privacy for your side yard, backyard or front yard.


text:
Article Index | Summary | Author Bio | Book Reviews | Discussion Questions | Full Version |
Discussion Questions
1. Abraham Verghese has said that his ambition in writing Cutting for Stone was to "tell a great story, an old-fashioned, truth-telling story." In what ways is Cutting for Stone an old-fashioned story-and what does it share with the great novels of the nineteenth century? What essential human truths does it convey?
2. What does Cutting for Stone reveal about the emotional lives of doctors? Contrast the attitudes of Hema, Ghosh, Marion, Shiva, and Thomas Stone toward their work. What draws each of them to the practice of medicine? How are they affected, emotionally and otherwise, by the work they do?
3. Marion observes that in Ethiopia, patients assume that all illnesses are fatal and that death is expected, but in America, news of having a fatal illness "always seemed to come as a surprise, as if we took it for granted that we were immortal" (p. 396). What other important differences does Cutting for Stone reveal about the way illness is viewed and treated in Ethiopia and in the United States? To what extent are these differences reflected in the split between poor hospitals, like the one in the Bronx where Marion works, and rich hospitals like the one in Boston where his father works?
4. In the novel, Thomas Stone asks, "What treatment in an emergency is administered by ear?" The correct answer is "Words of comfort." How does this moment encapsulate the book's surprising take on medicine? Have your experiences with doctors and hospitals held this to be true? Why or why not? What does Cutting for Stone tell us about the roles of compassion, faith, and hope in medicine?
5. There are a number of dramatic scenes on operating tables in Cutting for Stone: the twins' births, Thomas Stone amputating his own finger, Ghosh untwisting Colonel Mebratu's volvulus, the liver transplant, etc. How does Verghese use medical detail to create tension and surprise? What do his depictions of dramatic surgeries share with film and television hospital dramas—and yet how are they different?
6. Marion suffers a series of painful betrayals—by his father, by Shiva, and by Genet. To what degree is he able, by the end of the novel, to forgive them?
7. To what extent does the story of Thomas Stone's childhood soften Marion's judgment of him? How does Thomas's suffering as a child, the illness of his parents, and his own illness help to explain why he abandons Shiva and Marion at their birth? How should Thomas finally be judged?
8. In what important ways does Marion come to resemble his father, although he grows up without him? How does Marion grow and change over the course of the novel?
9. A passionate, unique love affair sets Cutting for Stone in motion, and yet this romance remains a mystery—even to the key players—until the very conclusion of the novel. How does the relationship between Sister Mary Joseph Praise and Thomas Stone affect the lives of Shiva and Marion, Hema and Ghosh, Matron and everyone else at Missing? What do you think Verghese is trying to say about the nature of love and loss?
10. What do Hema, Matron, Rosina, Sister Mary Joseph Praise, Genet, and Tsige—as well as the many women who come to Missing seeking medical treatment—reveal about what life is like for women in Ethiopia?
11. Addis Ababa is at once a cosmopolitan city thrumming with life and the center of a dictatorship rife with conflict. How do the influences of Ethiopia's various rulers—including Italyand Emperor Selassie—reveal themselves in day-to-day life? How does growing up there affect Marion's and Shiva's worldviews?
12. As Ghosh nears death, Marion comments that the man who raised him had no worries or regrets, that "there was no restitution he needed to make, no moment he failed to seize" (p. 346). What is the key to Ghosh's contentment? What makes him such a good father, doctor, and teacher? What wisdom does he impart to Marion?
13. Although it's also a play on the surname of the characters, the title Cutting for Stone comes from a line in the Hippocratic Oath: "I will not cut for stone, even for patients in whom the disease is manifest; I will leave this operation to be performed by practitioners, specialists in this art." Verghese has said that this line comes from ancient times, when bladder stones were epidemic and painful: "There were itinerant stone cutters—lithologists—who could cut into either the bladder or the perineum and get the stone out, but because they cleaned the knife by wiping their blood-stiffened surgical aprons, patients usually died of infection the next day." How does this line resonate for the doctors in the novel?
14. Almost all of the characters in Cutting for Stone are living in some sort of exile, self-imposed or forced, from their home country—Hema and Ghosh from India, Marion from Ethiopia, Thomas from India and then Ethiopia. Verghese is of Indian descent but was born and raised in Ethiopia, went to medical school in India, and has lived and worked in the United States for many years. What do you think this novel says about exile and the immigrant experience? How does exile change these characters, and what do they find themselves missing the most about home?
(Questions issued by publisher.)
top of page (summary)
Site by BOOM
LitLovers © 2024


text:
The NATO defense alliance will be bigger by two.
NATO leaders are at a summit in Madrid, rethinking how they can best counter Russia's threats in Europe and, obviously, the war in Ukraine. Turkey has not wanted to approve the membership applications of Finland and Sweden. But in a last-minute deal, Turkey has dropped its objections, and the two countries are now on their way to full membership. President Biden, meanwhile, has already been talking with NATO Secretary General Jens Stoltenberg, outlining what the U.S. plans are in Europe for the next few months or longer.
MARTÍNEZ: NPR's Frank Langfitt is in Madrid. Frank, what did President Biden have to say?
FRANK LANGFITT, BYLINE: He said that, you know, since the war began, the U.S. has actually already sent another 20,000 troops to Europe, bringing the total to 100,000. And then he talked about the other things that the U.S. plans to do to be able to deter Russia - adding two destroyers to Spain, bringing the number up to six. And this is very interesting, establishing a permanent headquarters for the U.S. Army Corps in Poland. And I've talked to a general in Poland about this. They're very excited there. They plan to work and build a base for the United States. And as to last night's announcement, I think that it's very helpful to NATO because it allows them to present sort of a stronger, more unified image.
One of the questions, though, is it could take some time in terms of letting in Finland and Sweden into the alliance. And that's because all 30 parliaments of the allies will have to vote on this. But it is seen very much as a done deal, and it has a lot to do, I think, with the optics that NATO wanted to be sending as the war continues to grind on in Ukraine.
MARTÍNEZ: Frank, these meetings in Europe, the G-7 first and now this NATO meeting, I can't imagine that Russia's too thrilled by this.
LANGFITT: No. It hates all of this, for obvious reasons. I mean, one of the reasons that President Putin said that he sent troops into Ukraine was to prevent Ukraine from joining NATO. So it does seem to be backfiring. And one way Russia seems to respond is by firing more missiles. You know, in recent days there have been increased missile strikes. And many people think it was timed to the summit here and the G-7 meeting earlier in Germany. And earlier this week, missiles killed 18 people at a shopping mall in Ukraine and also hit an apartment building for the second time in Kyiv.
MARTÍNEZ: Thing is, Sweden and Finland's decision to join NATO was triggered by Russia's invasion of Ukraine. So what do they bring to the table?
LANGFITT: Analysts that I've talked to say they are helpful because they've also - they've been very close to NATO all along and have worked in exercises, things like that. This is what NATO Secretary General Jens Stoltenberg said yesterday about the role that they could play.
JENS STOLTENBERG: Finland and Sweden also brings to NATO advanced, well-developed, well-equipped forces and stable, strong political institutions.
LANGFITT: And, A, I've got to say, you know, Finland has a very large, well-trained army. Sweden has very good intelligence gathering. They also control Gotland Island, which is in the middle of the Baltic Sea. And strategically, this is really, really important.
MARTÍNEZ: What's happening at the summit today?
LANGFITT: Well, I think we're to see more announcements. I think what we saw from President Biden was kicking off a series of announcement of increased NATO troop deployments to the eastern flank of the alliance. And this is part of a major shift. And, you know - got to remember, since the end of the Cold War, the eastern flank has been pretty quiet because Russia wasn't seen as much of a threat. And I think what we're going to hear is more troops going to the Baltic States. And, of course, Russia will be watching this very closely.
MARTÍNEZ: And NATO's going to be putting out a strategy blueprint for the next decade. Anything new in that thing?
LANGFITT: I think you're going to see a big focus on China. President Biden has said while he's obviously very, very concerned about Russia, China remains a big, long-term challenge to the alliance and to the United States.
MARTÍNEZ: That's NPR's Frank Langfitt in Madrid. Frank, thanks.
LANGFITT: Great to talk, A. Transcript provided by NPR, Copyright NPR.


text:
Alcohol and the law - which road users are worst?
For some months I've had an irregular correspondence with a Polish cycle campaigner who relates that the police treat drunk cycling under the same laws as they treat drunk driving.
In Poland - as with most of the rest of Europe - the legal blood alcohol limit is far lower than in the UK: you can be fined at over 20 mg/100ml of blood and jailed at 50. In the UK the limit is still 80, despite a recent report recommending reduction to 50.
Incidentally, in this country the legal limit is imposed only on motor vehicle operators - an offence of 'cycling when under the influence' exists, but evidence of this can only come from the opinion of police or witnesses, not a breath or blood test.
According to my contact in Poland, the police crackdown on drunk cycling heavily, and he maintains that there are more drunk cyclists in prison than drunk drivers.
He also pointed me to German data from 2010, which provides some startling figures - almost 5% of cyclists injured there were under the influence of alcohol, compared to just 2.5% of drivers. However, cyclists are subject to a higher legal limit (160 mg/100ml blood) than drivers, so more of those people would, technically, be riding legally. Cyclists are, however, more likely to have very high levels of alcohol with almost a quarter of all drunk cyclists having between 200 and 250 mg of alcohol per 100ml blood.
So is drunk cycling a serious problem in Britain that we are failing to detect?
Curiously, it seems not. Police suggested that the cyclist was 'impaired by alcohol' in just over 1% of cyclists' crashes - only 219 in 2009 - compared to 3% of cars involved in crashes (5,337).
Even more interesting are figures from coroners, who investigate the blood alcohol levels of the victims of fatal crashes:
This graph shows that of all fatalities, cyclists are the road user group that have consistently the lowest level of blood alcohol at the legal limit and are generally the lowest, with the exception of motorcyclists at 200 mg/100ml whereas almost a quarter of dead drivers were found to be over the limit.
Of course, this isn't an invitation to go out, get smashed and then try and cycle home - remember that riding drunk is still an offence and can put you and others at risk.
However, it seems sensible that drunk cycling doesn't receive the amount of enforcement activity as drunk driving, and I'd much rather potential drink drivers went by bike (where they were unlikely to put others at risk) than by car.


text:
Who would you become if you lost the only person who ever mattered?
For twenty-six year old Dylan Hopkins, the answer is easy. He's become no one. Memories of the happier times are all he has left as he finds himself meandering numbly through his now dull life. Though he cares about his work and family dearly, he's yet to let himself find love again. Afraid of letting go of what he once had, Dylan chooses to keep his heart buried, where it belongs, having died a long time ago.
Conner Michelson is about to change everything Dylan knows. He's every bit the bad boy persona - tatted up, ex-MMA fighter, but after an injury leaves him unable to fight, he has to rethink his goals. Having just opened his own gym, Conner can cross his first major life accomplishment off his very short list. Next up: find a man he can settle down with and build a family. Seems simple enough - a dream most people have, but when he meets Dylan, his carefree, easy-going life is thrown into a tailspin.
Determined to keep Dylan in his life, Conner vows to resurrect Dylan's long ago buried heart and let love live once more.
Melissa Collins has always been a book worm. Studying Literature in college ensured that her nose was always stuck in a book. She followed her passion for reading to the most logical career choice: English teacher. Her hope was to share her passion for reading and the escapism of books to her students. Having spent more than a decade in front of a classroom, she can easily say that it's been a dream.
Her passion for writing didn't start until more recently. When she was home on maternity leave in early 2012, she read her first romance novel and her head filled with the passion, angst and laughter of the characters who she read about it. It wasn't long before characters of her own took shape in her mind. Their lives took over Melissa's brain and The Love Series was born.


text:
We invite you to the Global Day of Coderetreat 2019 in Cluj-Napoca, organised for the 8th consecutive year! This year, the global event will take place on November 16th, 2019.
Coderetreat is a day-long, intensive practice event, focusing on the fundamentals of software development and design. By providing developers the opportunity to take part in focused practice, away from the pressures of 'getting things done', the coderetreat format has proven itself to be a highly effective means of skill improvement. Practicing the basic principles of modular and object-oriented design, developers can improve their ability to write code that minimizes the cost of change over time.
Global Day of Coderetreat is a world-wide event celebrating passion and software craftsmanship. Last year, many passionate software developers from Cluj-Napoca joined developers in cities around the world in spending the day practicing the craft of software development using the coderetreat format.
Find more about this event! Reserve your seat, here!


text:
Wispy Lisp
From: Alexy
Dear Rabbi,Did Moshe have a speech impediment?
Dear Alexy,
From a simple reading of the Torah verses and Talmudic teachings, it would seem that he did. However, we'll see that's not necessarily the case.
When G-d charges Moshe through the burning bush to demand that Pharaoh let the Jewish People go, Moshe replies, "I beseech You, O Lord. I am not a man of words...for I am heavy of mouth and heavy of tongue" (Ex. 4:10).
Moshe seems to be demurring G-d's command because of an inability to speak well enough to convince Pharaoh of such a great request.
Similarly, Talmudic sources also seem to indicate that Moshe had a speech impediment.
One teaching describes that Pharaoh suspected Moshe wanted to usurp his throne. He placed before the lad his glittering crown of gold on one side (which if he took, he'd be put to death) and glittering red coals on the other. Moshe went to reach for the crown, but an angel turned his hand toward the fiery coals instead. Moshe instinctively cooled his burning fingers in his mouth, which then impaired his speech.
Another tradition informs us that Moshe could not pronounce certain of the Hebrew letters – namely bet, vav, mem and peh.
However, on the other hand, we also find that Moshe had a very highly developed "power of speech". When Moshe slew the Egyptian taskmaster who was mercilessly beating the Jewish slave, our sources explain that he did so by pronouncing a Divine name to incur G-d's judgment over the person. (This is based on a possible reading of the continuation of the verses, where the next day, when rebuking a Jew who was beating his fellow Jew, the offender replied to Moshe, "Will you kill me by speaking as you did to the Egyptian?")
And even regarding G-d's sending Moshe to Pharaoh, after Moshe recalls his so-called speech impediment, G-d replies, "Is there not Aaron your brother, the Levite? I know that he will surely speak, and behold, he is coming forth toward you....You shall speak to him, and you shall put the words into his mouth....And he will speak for you to the people, and it will be that he will be your speaker, and you will be his leader". If Moshe was such a bad talker, how was he to put the words in Aaron's mouth?
The explanation is as follows: Moshe did not have a speech impediment in the normal sense of the word. Rather, he was so spiritually elevated that he was not able to communicate in a way that average people could understand. This is what is meant by Moshe being heavy of mouth and tongue – the regular instruments of speech were too clumsy and course to express his level of lofty comprehension. So G-d sent him Aaron who was elevated enough to comprehend Moshe but "low" enough to convey his ideas to other people. This is the meaning of Aaron "coming toward" Moshe and in turn speaking for him to the people. And it is for this reason that Aaron is described as the speaker and Moshe as the "leader" where the Hebrew word used is "elohim". Moshe is so elevated that he is likened to Aaron what G-d is to Moshe. As G-d later communicated the Torah through Moshe, Moshe communicates G-d's message through Aaron.
So in this light, how are we to explain the teachings regarding Moshe's burning his mouth and his inability to pronounce certain of the letters?
Moshe was certainly destined to replace Pharaoh. However, as a youth raised in his palace, he could have indulged in the glitter of Egyptian wealth until he himself gained physical control of the crown. But this would not have ensured the physical and spiritual redemption of the Jewish People. For this Moshe would have to rise to great spiritual mastery. This is represented by the challenge of choosing the golden crown or the fire, where fire represents spiritual fervor. Had Moshe chosen the material manifestation of kingship, his mission would have been terminated. The spiritual force within him pushed him toward the fire (despite having all the sensuality of the fleshpots of Egypt at his fingertips) for which he ultimately merited the revelation of the burning bush, but which simultaneously impeded his ability to communicate with ordinary people.
Similarly, this is also the deeper meaning of the teaching regarding Moshe's inability to pronounce certain of the letters. The Hebrew letters are divided into five groups based on where they're enunciated: throat, palate, tongue, teeth, lips. Since the letters make up the Torah, these different groups correspond to different levels of Torah ideas where the guttural letters are the deepest and those expressed by the lips correspond to the more external meanings. The fact that these labial letters – bet, vav, mem, peh ("bumaf") — are specifically the ones Moshe is described as having difficulty pronouncing refers to the way in which Moshe's extremely deep level of comprehension impeded his ability to communicate such subliminal understandings to the outside world!


text:
As a family-loving culture, Filipinos will certainly find ways to meet up with relatives safely. Now that pandemic restrictions are starting to ease, Pinoys are truly looking forward to what is about to come — reuniting with their families.
Along with family reunions, you might have to face yet another hurdle — meeting the titos and titas once again.
For the younger members of the family, it's not just a reunion with loved ones — it's also a reunion with your tito and tita's usual greetings.
While this can be scary at times, you are never alone. Here we list common lines that every pamangkin probably encountered at least once:
1. "Wow, dalaga/binata ka na!"
Every Pinoy kid has definitely heard this once from a tita or a tito. This is because some relatives rarely attend reunions — but when they do, they definitely emphasize their surprise as to how much you've grown.
Traditionally, family reunions are done at least once a year during national or religious holidays — and attendance isn't always perfect.
Some family members could be an Overseas Filipino Worker (OFW) and couldn't come home, while some have other priorities that need to be attended to.
At the end of the day, though, it is all the same greetings: "Wow, dalaga/binata ka na!". To make matters even funnier, it usually comes with "Huling kita ko sayo, binubuhat pa kita!", implying that you were still an infant the last time they saw you.
Nevertheless, this is a warm welcome from the titos and the titas — and hey, they're just really surprised and proud of your growth, physically and everything else in between.
2. "Kaninong anak ka?"
The older titas and titos might ask you this, especially if you come from a very big family. All the farther relatives may be hard to remember especially when you do not get to meet them often.
Naturally, when titos and titas with an age meet you, it's also most likely they don't remember you. Either they last saw you as a child and couldn't remember you, or they never really met you at all.
For others, it can be scary to introduce yourself to older relatives. However, this is also an opportunity to *lowkey* create a good image of yourself in the family. You can tell them who your parents are and a very brief fast track of how much you've grown — typically what you do and how you got to the reunion.
A bonus would be — letting the titas and titos know the positive things you've heard about them. Who knows, you might end up as their favorite pamangkin.
3. "What are you wearing, hija/hijo?"
Coming from a very conservative generation with religious and patriarchal roots, it is understandable that titas and titos may greet you with immediate comments about your clothing.
Sometimes, it can be related to your skirt being short, or your haircut not being styled according to your "gender".
This can be offensive and hurtful when hearing it at times, but it is best to understand the tito and tita's standpoint. Nevertheless, keep wearing what you want. Reunions are only once a year, but you are yourself every day.
4. "Kailan ka mag-aasawa?"
The older titas and titos probably got married early during their time, so they could be expecting the same from their nieces and nephews.
Correspondingly, for the pamangkins in their 20s, there is also sort of an expectation that marriage is "in the works" or "in the mind" — so much that it has become a greeting already.
In comparison to the dating trends among the young generation, many millennials and gen Zs find it difficult to get married in their early to mid 20s. Some would rather prioritize their personal well-being or careers, which is why this question seems a little bit hard to answer.
Worry less, though — your cousins may have been greeted with this too. So the next time you have a reunion, make sure to draft a group response with your cousins.
5. "May boyfriend/girlfriend ka na?"
One of the classics — if you're too young to get married but old enough to date, this question is the natural "hello" for titas and titos in reunions.
Usually it comes with a follow-up question, asking if there's a manliligaw, or any dating prospects. If you're lucky enough, a tita will even offer to introduce you to their friends' child who's in a similar age as you.
Titos and titas might just be in their Marites mode, or they just genuinely care about your lovelife, but nonetheless this is probably a sincere question.
6. "Join ka wine night, ha!"
For the young-at-heart titos and titas — drinking is probably the best way to spend time, and most especially with their pamangkins. So before the reunion actually starts, they greet you with an invite: an invitation to drink, typically wine for the titas, and beer for the titos.
This is usually an invitation to get in touch with the latest family chika, or just an opportunity to relax and have fun conversations with relatives.
If the situation allows, they sometimes hold surprise activities while drinking, much for the happiness of the younger members of the family, like you.
7. "Hoy, tumataba/pumapayat ka."
The most iconic of them all and every tito and tita's favorite greeting — it's either you're growing healthier, or you're getting slimmer as you age.
Every pamangkin must have heard this, and this is probably the most relatable line out of all that has been listed here. While this can be very trivial for the titos and titas, the younger generation may not take it as lightly as it seems.
When you hear this, own your body and show off your beauty. So the next time they meet you, they know how else to see you apart from your body. Mindset ba, mindset?
Pinoy reunions can be chaotic at times, but still fun and fulfilling. Most typically, it ends with "Message me on Viber, ha!" — like the real titos and titas they are.
So before your family arranges your post-pandemic reunion party, make sure to download the tito and tita apps and prepare your scripts for a flawless response to their incredible greetings.
Find out more of these stories at http://themindanaolife.com/ or you can visit http://politico.ph/ for the latest news and updates.


text:
Episode 56 – Original 13 Ciderworks – John Kowchak and Petra Manchina
This episode features John Kowchak and Petra Manchina of Original 13 Ciderworks. John's Grandfather Charles Steckel worked in apple orchards and learned how to make hard cider. John's journey began as a home brewer of beer. On a fateful day he had a conversation with his grandfather who shared with him that he made hard cider in his basement. John pays tribute to has grandfather with the Sir Charles line. John saw opening a cidery in Philadelphia as a continuation of his families entrepreneurial roots. In 2013 Original 13 was born and at the time there were no cideries in Philadelphia. In 2017 they opened the doors. In this episode John and Petra share their take and vision on the cider and mead that they are creating. The cocktail program, tasting room and restaurant. They are producing some incredible and complex cider. Full of flavor, character and some wonderful surprises.1526 N American St, Philadelphia, PA 19122 –
(215) 765-7000 – www.original-13.com – Facebook
Available on:
🎧 Apple https://lnkd.in/evcgwJv
🎧 Google https://lnkd.in/ebknpCM
🎧 Spotify https://lnkd.in/ee5ymky
🎧iHeart Radio https://lnkd.in/eZdxV89
and more…
Highlights from our discussion:


text:
Home Links Message Board DB/Z/GT • Goku • Gohan • Goten • Trunks • Goten and Trunks • Vegeta • Gotenks • Misc. characters Case Closed Devil Children Digimon Fooly Cooly - FLCL Full Metal Alchemist Hunter x Hunter Inu Yasha Naruto Ouran Host Club Sonic the Hedgehog Trigun Yu-Gi-Oh! Yu Yu Hakusho Zatch Bell Other/Misc. Featured Artists • BabyElliot (Ronin) • Daniel Barinas • Nappyjunior • My Own Junk Art Gifts • More to Come! |
DBZ in Diapers : HomeLast Updated: 9/18/2014Hello everyone, remember little ol'me? It has been, without a doubt, too long that I have been away. I never really fell out of love with my site or my goal to diaper cute images of anime boys, cleaning up the nasty smut out there on the interwebs, and I have in no way fallen out of love with all of you, my friends and fans. It still somewhat humbles me to see that, even after the time that has passed, I still have loyal members and "check-in'ers" that still keep the message board clinging to life. RL has taken several tolls on me in the years passed, some good and some bad, but throughout everything, I always wanted, always kicked myself, always hoped to start back up and do some more editing, even if it will be on my spare time. I do hope to ramp up production once again, however, I would not expect anyone to hold their breath for regular daily or weekly updates. I intend to take it slow, work my way back into it, hopefully try and improve and be a little more available once again.. Those that have stuck around, I am amazed and thank you for keeping my torch lit. For those that find their way back, I want to welcome you back and apologise for leaving you wanting for so long. And for those that are new, I hope you find yourselves among friends in this tiny community! |


text:
And if you're just joining us, this is WEEKENDS on ALL THINGS CONSIDERED from NPR News. I'm Guy Raz.
We just heard about the jobs numbers, but now a little more about the data point that actually moves those numbers - hiring. The unemployment rate is at its lowest point since January 2009, and this time, the size of the workforce didn't shrink, so more people are working and more people are looking for work.
And of those looking, technology may pose a slight obstacle. Most big companies now use screening software to scan through resumes, and so it could make it even harder to catch an employer's eye. Here's reporter Ben Bradford with more.
BEN BRADFORD, BYLINE: It's estimated about 90 percent of large companies use some form of screening software. So I asked Barbara Safani, a Manhattan career consultant, how does my resume stack up against the machine.
BARBARA SAFANI: There are a lot of things I see here that could immediately just kick it out just because the software can't read it.
BRADFORD: Like what?
SAFANI: For example, on your resume, you have your dates of employment going across columns.
BRADFORD: Mm, the eye reads left to right, and it goes left to right. Apparently, this is not as great an idea as I'd hoped. It turns out, my resume has all kinds of problems. It's a PDF. That's harder for machines to digest. My dates are in the wrong place. My work experience goes the wrong direction, and I have this beautiful side column showing off my impressive digital skills, but because it's not offset below my job experience, the software might think it's another job that I worked at some company called Digital Skills. Thankfully, Safani says these things are easy to fix, and that it's not that hard to create a resume the software can read.
SAFANI: I think it can add a layer of complexity to the process. It's not rocket science, though.
BRADFORD: Eric Lochner is an executive at Kenexa, one of the biggest employment software companies. And Kenexa has some big clients: Wal-Mart, General Electric and Starbucks.
ERIC LOCHNER: Our largest client receives over a million candidates a month. Our average client will receive anywhere from 15 and 40,000 candidates a month.
BRADFORD: Lochner says automation means companies can find quality candidates in a day where it used to take weeks. And job hunters benefit too.
LOCHNER: The process is so much more simplified and streamlined. All of these CVs go into one database. And the CV doesn't get put in an outbox or accidentally deleted.
BRADFORD: Once it's in the database, a resume can be filtered, graded or ranked by how well it matches a job so recruiters only spend time looking at the best fits. But even as more and more companies turn to these programs for their searches, many still aren't finding the people they want. Up to half of all employers say they can't find qualified workers. University of Pennsylvania professor Peter Cappelli says the software actually plays a part in this.
PETER CAPPELLI: There may be people who haven't done exactly this job but have done similar jobs, and it's a sort of a judgment call as to whether the combination of those jobs are enough. So the software can't make those judgment calls, so all those people are tossed out.
LOCHNER: I disagree with that.
BRADFORD: Kenexa's Kevin Lochner.
LOCHNER: That's not because of the technology per se. That's because candidates have to take the time to understand that each opportunity, each company is a different scenario for them. They have got to approach it differently. They've got to customize or tailor their approach for every opportunity they want to go after.
BRADFORD: It turns out this is a great tip to improve how you're ranked. The software searches for different keywords or phrases in your resume: things like years of experience in a field, specific skills, salary requirements, a nearby zip code. If you want a good rating, you have to customize your resume so it has the right words. Of course, that's just step one in the process. Once you get past the machine, you still have to deal with a real, live person in the next step in the hiring process. For NPR News, I'm Ben Bradford. Transcript provided by NPR, Copyright NPR.


text:
Order business checks online or call us toll free at 888-447-3282, or if you prefer to fax/email your order click here to print the EZ check order form.
*asterisk denotes required field.
The check imprint will be printed exactly the way you enter it, (i.e. upper and lower case). Be sure to double check spelling, punctuation and abbreviations. Important: First time orders require a faxed or emailed voided check copy to verify positioning of the routing & account numbers.
Fax: 816-254-6222 or Email: email@example.com
Details for Peachtree Checks:
Use compatible envelope MD939 or MD939SS(Self Seal)
For higher quantities call Customer Service toll free at 888-447-3282.
Need help filling out the form? Please click here for our Frequently Asked Questions.


text:
Why TeaLAB?TeaLAB is committed to helping people and their gardens to become more self- sufficient, healthier, and productive. Grow your sweetest corn, your biggest watermelon, your tallest quinoa, your tastiest tomato, and your happiest you.
TeaLAB was founded to teach people how to garden organically, so that we can become more closely connected with the land. Our goal has been to simplify growing methods so that gardeners have a positive experience in the garden. TeaLAB is where the garden meets the laboratory. From around the world and into your backyard, our products contain ingredients that are sourced both locally and globally. Using methods both ancient and cutting edge, TeaLAB promotes maximum biology. Grow with TeaLAB. |


text:
Free US Ground Shipping For Orders Over $75
We offer free ground shipping in the lower 48 states for most purchases over $75.00. In the case of some unusually large or heavy products, overweight charges may apply. In those cases, the product's description will clearly indicate such. Some products are required to be shipped freight at an additional cost to you when UPS or Fed Ex will not deliver. If you would like to upgrade from UPS ground shipping you can contact us for a quote. If you have special shipping needs or circumstances please contact us as we will do everything we can to ensure you receive your purchase in time and as expected.
We use United Parcel Service (UPS) for all shipping in continental US. We also offer US Postal Service as an option for shipping to Alaska and Hawaii, and use USPS exclusively for shipping to APO/FPO addresses. You'll get an instant shipping quote by simply entering your zip code on the shopping cart page.
Our products are shipped directly from our Portland, OR warehouse, or in some cases, directly from the manufacturer. The estimated time to shipping is shown on each product page and will sometimes depend on which product options are chosen. The estimated delivery date for your order is shown on the shopping cart page after you have entered your zip code or postal code. We try hard to get your order to you in the estimated time. Bonus items may ship separate from the cue. Bonus items are shipped UPS ground if the cue is shipped to you direct from a manufacturer.
Once your order is shipped, you will receive an email with the tracking number. You can also check the tracking number(s) on your account page by clicking on My Account.
Canadian Shipping
We use United Parcel Service (UPS) and USPS International Airmail Parcel Post for shipping to Canada. To get a shipping quote, simply type your postal code into the form on the shopping cart page. You may also be required to pay import duty, local taxes, and brokerage fees. These will be collected at the time of delivery. Please check with your local authorities to determine the amount before ordering. We attach an invoice to the outside of the box with a detailed description of the products to reduce customs delays, but occasionally orders are still delayed in customs for up to several weeks.
International Shipping
We do not currently ship to locations outside the United States and Canada.


text:
First off, Hello! I hope you all are having a great start to summer. Here, in Portland, we have been having beautiful weather, which is odd for this time of year. Normally we have what the hubs and I like to call June-uary, very cold and wet. Instead, there are people sporting sunburns! Unfortunately, it was the warmest year on record for May, and it looks like June will follow that trend. Look into solar! And recycling, and anything else we can so we don't sink into the oceans ala Atlantis.
I found a few great science articles over the past few weeks. As usual, I kept myself a little too busy and didn't have as much free time as I would like for blog perusal. So, I apologize for the slim pickings, I promise, they are all worth the read. If you are interested, take a click below!
- Dinosaur Blood Ran Just Right: Not Warm, Not Cold
- 10 Years of Scientific Career Evolution: From Springs to Stormwater, Student to Teacher, by Anne Jefferson
- The Albatross and the Phytoplankton by Liz O'Connell
- "Scientists…speak up!" by Jessica Ball
I have taken on a freelance project this summer with Opus Events Agency, and it has been really fun so far. Plus, it fits in with what I'm already doing work-wise. It feels like a win all around. With permission, I might post some of the projects I'm working on in my Project Gallery. I'm working on some fun stuff!
I'm in the process of cleaning up my social media and interwebs presence, this blog will stay, but I have some other old ones floating out there that I would like to consolidate. You should probably expect some older posts. It's always fun to look back on things. And I have to update all my LinkedIn/twitter/etc… It's a good time to clean up. I mean, it's not like I have anything else going on.
As always, thanks for reading!


text:
For instance, consider the case of Shannon Murphy Castellani. She gave Mike Bonin $700 on June 14, 2016. Exactly four weeks later, on July 12, 2016, she registered with the Ethics Commission as a lobbyist.2 Now, section 470(c)(11) of the City Charter forbids candidates from accepting campaign contributions from registered lobbyists. It's vague on the timing, and I don't see that it actually explicitly prohibits someone from donating money and then registering as a lobbyist the very next day, but on the other hand, does Mike Bonin want to argue that case in public? Obviously not, so the best thing to do is to return the contribution. Just as obviously, the $700 itself isn't so important. These people are all zillionaires, after all. It's the good will that the $700 creates, and that lingers on after the money is returned.
Continue reading Some Money Is Even Too Dirty For Mike: A Look At One Of Bonin's Recent Returned Campaign Contributions And Subsequent Trip Down A Lobbyist-Money Rabbit Hole
Some Money Is Even Too Dirty For Mike: A Look At One Of Bonin's Recent Returned Campaign Contributions And Subsequent Trip Down A Lobbyist-Money Rabbit Hole
The L.A. City Ethics Commission website is a marvelous repository of fascinating minutiae. It more than repays the kind of obsessive poring-over in which we here at MK.Org specialize. Today's subject is the quarterly reports that every qualified candidate has to submit detailing their expenditures. You can find all of Mike Bonin's here.1 In particular, take a look at his 3rd quarter report for 2016. On Schedule E, the list of expenditures, note that some items are labeled "Returned contributions." No reasons are given for the returns, but at least in some cases it's possible to track down at least some elements of the story via the Google.


text:
FES Flower Essence (1/4 oz), Borage
- Free shipping on orders $45+
- Low stock - 2 items left
- Backordered, shipping soon
Flower essences are liquid extracts used to address profound issues of emotional well-being, soul development, and mind-body health. They are part of an emerging field of subtle energy medicine, which also includes homeopathy, acupuncture, color therapy, therapeutic touch and similar modalities.
See below for helpful links:
Alphabetical list of all flower essences and their indications- http://www.fesflowers.com/product-info/fes-quintessentials-essences/
About Flower Essences- http://www.fesflowers.com/learn-about-flower-essences/what-are-flower-essences/
Resources from FES - http://www.fesflowers.com/learn-about-flower-essences/resources/


text:
Search UMMC
Mobile Navigation
Headlines around the world told the astounding news of a surgical team in Mississippi which had transplanted a human lung into another human being.
The year was 1963, and the team was led by Dr. James D. Hardy, professor of surgery and chairman of the department at the University of Mississippi Medical Center.
But it was the following year when an event at the young Medical Center really had the world's press in a frenzy. Dr. Hardy and his team transplanted the heart of a chimpanzee - man's closest genetic relation - into the chest of a dying man. The world's first heart transplanted into man beat 90 minutes before it stopped.
The operation "precipitated intense ethical, moral, social, religious, financial, governmental and even legal concerns," Dr. Hardy has written. "We had not transplanted merely a human heart, we had transplanted a subhuman heart."
Even some of his medical colleagues were critical. They said his nine years of work in the laboratory with animals weren't adequate preparation for his bold move in the operating suite and that not enough was known about xenografts to warrant their use.
The noted transplant surgeon Dr. Thomas Starzl, who had transplanted a human liver about the same time, once told Dr. Hardy, as the latter related in his memoirs, "You know, you and I are absolute pariahs in American surgery."
In the ensuing months, some of the criticism waned - particularly among medical colleagues, because Dr. Hardy's paper on the subject appeared in the Journal of the American Medical Association which described the strict ethical guidelines his team had followed in evaluating both donor and recipient.
By 1966, Dr. Hardy says, the American public showed a major shift in perception, and the notion of the heart as a pump began to hold sway over the idea of the heart as the seat of the soul.
After Dr. Christian Barnard performed his heart transplant in 1967, the barriers to human transplantation in the United States were swiftly swept aside, and human-to-human heart transplants followed quickly at Maimonides Hospital in Brooklyn, NY, by Dr. Adrian Kantrowitz and at Stanford by Dr. Norman Shumway.
Dr. Mario S. Barnard, brother of Christian, and author of the paper in the South African Medical Journal describing the first human-to-human heart transplant, gave credit to the Mississippi team for the 1964 operation, saying it proved that "the feasibility of cardiac transplantation was now irrefutable."
A transplant team led by Dr. Hardy performed the world's first heart transplant in man Jan. 23, 1964, at the University of Mississippi Medical Center.
Those first two operations in Mississippi - met with such dubious acceptance in the beginning - set the stage for all future heart and lung transplantation. They demonstrated that surgical techniques perfected in nine years of work on animals would work in humans. They proved that a transplanted lung would breathe and transplanted heart would beat and support a blood pressure in a human host.
Dr. Hardy said the operations "set in motion the inexorable process of human imagination and gradual acceptance which has evolved into our current almost casual attitude toward transplantation."
But whether the object of reproach or acclaim, Dr. Hardy continued a steady pace of scholarly contributions and professional leadership. He edited and wrote 23 books throughout his career, including two which became standard surgery texts in American medical schools. He published more than 500 articles in medical journals, and served as editor-in-chief of the World Journal of Surgery, Surgical Capsule and Comment, and Advances in Surgery. The proceedings of the 1983 Surgical Forum of the American College of Surgeons was dedicated to Dr. Hardy, "... an outstanding surgical educator, investigator, clinical surgeon and international leader."
In 1971, the Vishnevsky Institute in Moscow, Russia, honored Dr. Hardy for his pioneering role in transplantation, and presented him with two medals - one for the lung transplant and the other for the heart.
He served as president of the Society of University Surgeons, the Society of Surgical Chairmen, the Southern Surgical Association, the American College of Surgeons, the American Surgical Association and the International Society of Surgery. He is an honorary member of the French Academy of Medicine, the French Association of Surgery and the Royal College of Surgeons, London.
He was a member of the American Board of Surgery and the American Board of Thoracic Surgery.
Dr. Hardy has been a visiting professor in 36 medical schools in the United States and abroad and has presented as many named lectures throughout his career. Dr. Hardy also served on the National Institutes of Health Surgery Study Section and on the NIH Anesthesiology Training Grant Committee among others.
He was also busy directing the department. "When I came to Mississippi, I decided that our department should start out on an even footing with other institutions in at least one field," Dr. Hardy recalled. "That's why we began transplantation research. I knew it would be difficult to compete with other centers which already had long established programs in older fields."
In addition to the first lung and heart transplantations, Dr. Hardy's team also performed the first successful human kidney autotransplant and the first human adrenal autotransplant in the United States.
He has continued to receive honors in the years since his retirement from the Medical Center.
But as startling as his surgical achievements in the world arena, generations of Mississippians owe a large debt to him for his work at home. More than any other single individual, Dr. Hardy has influenced the way surgery is practiced in Mississippi.
He was the first chairman of the Department of Surgery from 1955 when the Medical Center opened until his retirement in 1987.
As one of the first clinical chairs appointed for the new medical school, he worked closely with the first dean, Dr. David Pankratz, in the selection of other clinical chiefs. As the first chairman of surgery, he was the one who set standards for the surgeons who had operating privileges in the new University Hospital.
Dr. Johnnie W. Williamson of Tupelo is a UMC alum who benefitted from Dr. Hardy's rigorous but humane teaching. He spent a decade at the Medical Center - as a medical student, then as intern and surgery resident and finally as a fellow in peripheral vascular surgery.
From Dr. Williamson's perspective, one of Dr. Hardy's notable achievements was that "he afforded good old country boys from Mississippi the opportunity to become well-educated, well-trained professionals who could stand on our own wherever we wanted to go."
Despite his towering presence in the world of surgery, his residents didn't perceive that his attentions were elsewhere. "All of us knew that he was a world class surgeon, but not from anything he told us about himself. With us, he was always present. Even when he had to be away, he'd call at the drop of a hat. And he spent much of his time here operating. We knew he was highly respected in international circles, but we knew him also as a man and as a surgeon."
Dr. Hardy has said, "Our students and residents are here to learn to operate, and I couldn't help them very much if they never saw me in the OR. The final act of surgery, after all, is operating."
In the operating room and on patient rounds, Dr. Hardy had a unique teaching style that left a lasting mark on students.
"On a surgical case," Dr. Williamson said, "it was always intense, always all business. He kept everybody at the table participating. He wanted everyone participating in some form or fashion from the chief resident to the third-year student.
"On rounds, we went at breakneck speed, from the first floor to the top always using the stairs. And we learned from his rapid fire questioning how to think and talk on our feet. I learned later that ability was the mark of a Hardy-trained resident."
Dr. Williamson learned something else about the mark of a great teacher. "When I left the Medical Center in 1980, I felt I meant more to Dr. Hardy than a resident who had filled a slot. He wanted me to be a good father, a good husband and a good citizen as much as he wanted me to be a good surgeon. I think he cared deeply about his students."