To: Hawkmoon who wrote (8095 ) 12/30/1997 8:29:00 PM From: John Hanzl Respond to of 31646
Ron, This is true - Topro indeed does not make the actual embedded chips (That is the realm of Motorola, National, Intel, Zylog...) However, I was responding to: "having to replace embedded chip systems provides another investment opportunity. Anyone have any good picks for companys that specialize in updating and replacing non-Y2K compliant systems??" The important thing to note here is that what makes an embedded system a system is the combination of hardware & firmware (code). Topro DOES write the firmware that breathes life into the system. While it is true that they utilize OEMs that produce equipment (& sub-systems) for plant floor processes, it is Topro that brings it all together into one cohesive system. Sometimes Topro can recode to fix a Y2K problem, sometimes they will deem it necessary to completely replace a component (sub-system)at a mark-up, and sometimes it will be most cost-efficient to scrap the whole damn thing and start fresh. But Topro is guiding hand. However - for a component manufacturer - check out:dalsemi.com I would like to address a few questions to Mike Winn... I read the following comment of yours... "In the case of TPRO, the company makes money on factory automation but the Y2K stuff is purely hype. I couldn't contain myself laughing when I read what are posted on that thread. I work in embedded systems for a living and I know for sure for most of the part, embedded systems don't depend on the clock. Everything revolves around the power up time and not the clock time. But if there is any problem in embedded systems, it would have to be fixed by the company itself and it cannot be contracted out as the code is very complex and cryptic. " First of all, I am confused by "embedded systems don't depend on the clock. Everything revolves around the power up time and not the clock time" What revolves around power up time? A processor keeps track of time by dividing down a stable time base, period - either through firmware or dedicated hardware (Real Time Clock), possibly with sync data from another source. I have coded plenty of realtime clock stuff to understand it fairly well. I can think of plenty of opportunities for both the code and RTC to screw up the date information (I have posted regarding just that already) Next, please expand on the statement "But if there is any problem in embedded systems, it would have to be fixed by the company itself and it cannot be contracted out as the code is very complex and cryptic". You have stated in the beginning of your post that "In the case of TPRO, the company makes money on factory automation" so wouldn't Topro be, at least to a large degree, involved with the creation of the very complex and cryptic code you mention, at least to the degree that it is Topro who has the relationships with the OEMs that wrote the code (if Topro itself didn't write it)? Yes, I agree that quite often there are home-brewed solutions and implementations (some that are pretty slick) that can't directly be addressed by Topro - Topro knows that (as a reference check out thier PlantY2kOne demo, there is plenty of room to enter in custom data / systems) I can guarantee you that Topro will have a thier own solution to those home-brews - if there is a question of Y2K non-compliance. Until you adequately answer these questions and those put forth by Jack Z, I would be hard put to call you "somebody who directly works with embedded processors, knows what he is talking about ". Thank you JohnnyH