Should we study circuitry?
in [Device Drivers]
|
Prev: Jungo's WinDriver ToolKit
Next: OOB Information
From: Kid on 13 Apr 2008 09:46 Hi Should driver engineer study circuitry for driver development , or it is hardware engineer work only ? Thank you.
From: Calvin Guan on 13 Apr 2008 14:50 It depends on what kind of driver you mostly work on. If it's purely software driver, knowing how hardware work doesn't help much. -- Calvin Guan Broadcom Corporation Connecting Everything(r) "Kid" <Kid(a)discussions.microsoft.com> wrote in message news:7A121A43-4EA8-4AE0-94BC-C4A8C3B9566E(a)microsoft.com... > Hi > > Should driver engineer study circuitry for driver development , or it is > hardware engineer work only ? > > Thank you.
From: Tim Roberts on 13 Apr 2008 18:33 Kid <Kid(a)discussions.microsoft.com> wrote: > >Should driver engineer study circuitry for driver development , or it is >hardware engineer work only ? There is no simple answer. I have had many circumstances where my ability to read a schematic has enabled me to answer questions and identify problems without having to search out a hardware engineer. -- Tim Roberts, timr(a)probo.com Providenza & Boekelheide, Inc.
From: Pavel A. on 13 Apr 2008 19:18 "Kid" <Kid(a)discussions.microsoft.com> wrote in message news:7A121A43-4EA8-4AE0-94BC-C4A8C3B9566E(a)microsoft.com... > Hi > > Should driver engineer study circuitry for driver development , or it is > hardware engineer work only ? > IMO a driver engineer should be a nice guy in general (what the HR calls "great inter-personal skills") and study Linux. When you have a technical question, drop it here, and some kind soul here will help. Regards, --PA
From: David Craig on 13 Apr 2008 19:16
I am a pure software guy with no background in the world of EEs. Since I work in a hardware company it is more difficult, but all others in my group are EE graduates. There are also a lot of EE types who might be involved in validation and testing that can assist, but I would not be a good choice for a company in startup mode. I can do a buss trace and use the software to help determine where the hardware is failing, but I may have an EE review my results to see if I have it nailed down enough. I don't get a lot of problems since the firmware and diagnostic guys have done a lot of validation before I see even the FPGA versions. We may find some issues due to the fact the driver hammers the chips harder than their code, but basic functionality has been verified. I do have one advantage over the EE types. I always think the problem is with the hardware and that bias can help. I will verify the software (driver usually) to ensure I don't blow it, but being suspicious of hardware is helpful. I will do things such as writing very tight code that hammers the hardware more than most diagnostics. I remember a simple ISA buss card from the 1980's where the EE would give me a wire wrap card that he had tested using debug and simple register/memory mapped IO instructions. I would then write code in assembly that would hammer the ports in loops of 50k repetitions and find that it would fail maybe half way through the test. In most of those cases the EE had to tighten tolerances using better parts since this card was always a few plug in chips and discreete. This was before ASICs became common. From what I understand a lot of ASIC design is very similar to writing software. It is just that the instruction set is different. Learning about circuits may be useful in the hardware environment, but may be less useful if you go into pure software drivers other than thinking logical is common to both disciplines. "Tim Roberts" <timr(a)probo.com> wrote in message news:bg2504pvqune33g3iri53jhtguet165s4u(a)4ax.com... > Kid <Kid(a)discussions.microsoft.com> wrote: >> >>Should driver engineer study circuitry for driver development , or it is >>hardware engineer work only ? > > There is no simple answer. I have had many circumstances where my ability > to read a schematic has enabled me to answer questions and identify > problems without having to search out a hardware engineer. > -- > Tim Roberts, timr(a)probo.com > Providenza & Boekelheide, Inc. |