Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : TAVA Technologies (TAVA-NASDAQ) -- Ignore unavailable to you. Want to Upgrade?

To: John Miz who wrote (8351)	1/5/1998 4:07:00 PM
From: Jack Zahran	Read Replies (1) \| Respond to of 31646

Nice to be in-touch with some professionals in that area. Thanks for the reference. I especially was impressed with the following: " Thanks, Peter - that's exactly correct. I've worked on and/or designed firmware for over 100 embedded systems. These were for about 70 different companies: In some cases, there were _no_ standards at all about using 'standard code' (such as a company- wide library), so the programmer 'of the moment' simply wrote whatever seemed necessary. In other cases, there were specific sets of optimized library routines to be used in specific instances (for example, to measure time). Other systems were required to get time-values from other hardware, sometimes outside of the scope of the firmware's author. (Port XXX returns an X-bit counter of milliseconds in real time.) Still other systems used third-party CASE tools (I'm not kidding) which could measure time, but you had to go to the reslting binary code to tell what it was really doing. ("Oh, that's proprietary.") Finally, some folks designing ASICs simply used a 'library' of standard circuits availble for the device in question. > The thing to watch out for is "Does the date need to be reset when the > circuit board has a fault fixed." If not, then the rtc is not used to > keep track of the actual date, it's just there as a long-term counter. Yes and no. If the date _does_ need to be reset, then someone definitely needs to check what's going on. However, the use of public-broadcast time signals was _real_ popular for a while, so it wouldn't surprise me at all to find it in embedded systems that require real-world time (if only to reset their own clocks after a shutdown). Another, more subtle version of this, which I alluded to before, is the case where an embedded RTC (h/w or s/w) simply resets to some arbitrary date. The results from the RTC are used to calculate a period of time. For small times, this isn't necessarily important (so you miss a 100ms pulse - probably not a big deal, as long as it's not telling your heart when to beat). For larger times, such as safety watchdog timers, this could be a big deal. (Bear in mind that, as long as the time caluculations are consistent, things like leap years make no difference. What _does_ make a difference is if the result cycles to a value lower than it should be without a reset state being noticed.) I'll be happy to realte some theoretical and not-so-theoretical examples if anyone wants them. " -Westmore Nydek from news:comp.software.year-2000