<p>Hello all, I am a freshman in CS and was wondering the viability of a CS degree for writing firmware, device drivers, and other systems software as a career. As a CS major, I am required to take a decent amount of systems-level classes (Computer Organization, Computer Architecture, Operating Systems Concepts), but was concerned that those were not enough to write a variety of systems-level programs. Should I take some EE/CompE classes as an elective if I want to be a competent systems programmer? Any answers are appreciated. Thanks!</p>
<p>You generally need to be able to read schematics and understand hardware a bit better than us pure CS folk. Also be comfy with logic analyzers, ICE’s, and other related machinery. </p>
<p>This day and age everything is reasonably high level, i.e. Linux drivers or Windows drivers so it’s not as bad as it was 30 years ago (dad, what’s a device driver?). The device driver/firmware dudes at work are generally EE’s or ECE’s. One of my cubemates is the lead device driver guy. Not my cup of tea but someone’s got to do it.</p>
<p>Out of curiosity, what is the main role of CS people in the electronic devices industry? If we’re not entirely qualified for firmware / drivers, what type of software do we exactly work on?</p>
<p>HyperionOmega, as turbo93 pointed out, it will be easier for you to work on level stuff if are you had some EE/CompE exposure. Intro to digital design and exposure to assembly language programming will be more than sufficient. What I have observed is that EEs who have taken a few CS courses are generally better at it than pure CS folks. </p>
<ul>
<li>begin rant *
I hate it when some CS purists come in and spend weeks drawing umpteen UML diagrams to do simple stuff resulting in zillion abstraction layers and when the end user complains about sluggish performance real folks have to step in and clean up the mess they created. </li>
<li>end rant *</li>
</ul>
<p>We have components that have more UML diagrams than source code, and more code reviews and Jenkins test cases than there are federal regulations. Surprise, they don’t work any better, and the cynic in me says the extra UML’s allow for easier outsourcing :D</p>
<p>Now to answer HyperionOmega’s question, I’ll paste pieces from two posts I made about the issue. I have grad degrees in both CS and Human Factors Engineering so I tend to do both tasks, from usability clinics to writing code, designing, graphics editing, storyboards, back end code when needed, and so on… This past year I spent 7-8 months writing a web portal that our products talk to in PHP and MS SQL Server and interfaces with several social media networks because nobody else knew how to do any of that, then a few more months evaluating 3D UI builders, and i’m now playing with Nokia’s Qt. Going back to C++ after 2 years of not touching it was painful. I already miss PHP :D. I also did a lot of clinicking the portal and other stuff (it’s an advanced R&D project).</p>
<p>So… from the LCD screen to the guts of the machine there’s a lot of gray areas. From top to bottom:</p>
<p>User Experience Design (human factors engineers, industrial designers, marketing, R&D, customers)
User Interface Design (human factors engineers and industrial designers)
User Interface Creation (software people mostly)
High level software blocks (i.e.code that reads a button press) (software people)
Mid level software blocks (i.e. media players, database, other apps)
Low level software blocks (graphics, bluetooth drivers, wifi drivers)
board level computing (hardware / software interfaces) (vendor or BSP guys)
Actual hardware</p>
<p>My part is at the top, the first few layers (user experience design, human factors engineering and also software for user interfaces, maybe down to blocks). We typically develop on Linux virtual machines, and when we get ready to test, boot up our target hardware which also runs the exactly identical distro of Linux, connect the target hardware to our PC via USB or Ethernet, configure it to boot from our workstation, and off we go. </p>
<p>CS people typically do the upper half of this list - ECE’s and EE’s do the lower half.</p>
<p>Some more details… It all begins with guys in the next cubicle row (the BSP / bring up / HAL group where BSP is board support package, ie. device drivers and stuff, hardware abstraction layer, and bring-up meaning they receive the Fedex box with the boards and they bring up the OS and device drivers on the new hardware).</p>
<p>They’re largely EE’s with decent C++ and rarely assembly language. The main guy is a BSEE / MSCS whose purpose in life seems to be to turn the blinky light on and off a few times. He also writes device drivers and other board support goodies especially power management. In these days most of the driver comes from the board or microprocessor vendor and he ports it to our hardware. Not heavy duty coding work, but very tricky and slow/deliberate. </p>
<p>They work very closely with the vendors and the hardware design group, and have a very solid understanding of configuring open source platform software to our needs (i.e. LTIB and other BSP setups on Linux).</p>
<p>Their main devil on a regular basis appears to be device drivers for multimedia, i.e. how to get various drivers from various vendors or home-made to play nicely with each other. Again, fairly tedious work if you ask me.</p>
<p>As far as Operating Systems, well, we rolled our own a decade or two ago and it still works (one guy wrote it) but where the money really goes is the abstraction layer we use - so we can build and test code on Win32 or straight Linux and then when the board blinks ready we’re ready too. For OS work you should have an understanding of open source real time or sort-of real time embedded OS’s (QNX, Linux, Wind River, Windows CE, et al). But we rarely touch the source of the OS- the BSP team does drivers for our specific devices, packages everything with a red bow and passes it on to the middleware team (the people who do all the software that actually does something useful ) or the user experience team (pretty graphics and user interface team). I’m mostly in the last team with occasional dives into the middleware realm.</p>
<p>The board team reads schematics and uses hardware debuggers and analyzers and occasionally patches boards (or asks the hardware lab techs to do so). Hard as it may sound to believe they rarely use assembly language unless we’re talking hard real time like robot control and the like. Spend an hour looking at assembly of any decent microprocessor and you’ll run for your life. </p>
<p>All this for pretty powerful (1+ GHz, multiple cores, several GB memory) consumer electronic devices that are typically internet enabled via Bluetooth and cellphone and/or wifi.</p>
<p>Bottom line, pile on the list of skills and acquire some strange ones just in case. For example, I’m VERY good with databases/SQL, as my wife has every Oracle and such book ever made, and I get to read them and play around on her personal server at home. I learned SharePoint programming to help a nonprofit; PHP and heavy web development on my own for a project, and so on. I have primadonna colleagues that won’t touch anything unless it’s C++ and STL and other acronyms. Not me, heck, give me COBOL and I’ll code it up. Fun stuff.</p>
<p>
</p>
<p>You don’t even need a degree to write drivers. My cousin has made drivers and hasn’t finished high school. Also every qualified CS person should have had exposure to C, assembly, ( basic - verilog or vhdl), and computer architecture. I have taken some EE classes as electives but don’t see how they would help write better assembly/C at all. EE classes will help you understand what happens when you write programs for Arduino or RASPBERRY Pi because unless a CS person has taken physics E&M they won’t know what voltage and current really are</p>
<p>
</p>
<p>Those are high level :P</p>
<p>There’s two things here. One is qualifications. An ECE or EE understands the instrumentation more. CS do too but our heads are too full of UML and other crud to remember how to hook up an ICE or scope or what not. Also they have to be able to read chip data sheets and do basic hardware troubleshooting, stuff we CS folk are not as familiar with (last time I read data sheets it was during the George H. W. Bush administration :)). </p>
<p>The other is interests. EE’s and ECE’s are a bit more logical than us CS folk and are generally more orthogonal thinkers - avoiding coding heroics, design patterns, and other maladies afflicting coders worldwide. The typical CS person wants to see pretty graphics and sounds happening. My cubemate the BSP guy is happy if the LED’s on the board blink ON-OFF-ON-ON… When you write software that if it fails it WILL brick the unit, you tend to be a bit more careful. While we engage in theological questions like “should we use the STL” they talk about LTIB vs YOCTO and sing praises to NAND RAM or some other acronyms I don’t quite remember.</p>
<p>In other words, it’s one of these things you’re born for. To me, if the LCD does not show more buttons than an accordion, I’m not happy. To them, if the machine powers down when you press OFF, that’s nirvana. Different mind sets, and you need both. To me, I assume my SQL Server is on the other side of some IP address and away I go. They’re just as happy getting tftp to work…</p>
<p>turbo, you are too hilarious. :D</p>
<p>by the way, could you please send me the resume of your cubemate? He will get to dabble with cynagenmod and/or linaro distributions, flicker 4k displays and dip into sqlite.</p>
<p>He’s good. I think. I mean, all he does is stare at like 50 lines of code, changes something, runs, then the thing blinks a light. Well, duh, good thing you went to Rose-Hullman for that, dude 
Every few months he screams at us for not shutting down our code fast enough… He’s not moving tho, other companies have tried. </p>
<p>Consumer electronics is a brutal field but it’s a lot of fun too. In a month we have our Superbowl (CES in Las Vegas) and of course my stuff will be there as it has been nearly every year since the late 90’s.</p>
<p>@Turbo93</p>
<p>Yes, this is spot on. I care about blinking LED lights on an FPGA to verify my design for Input/Output code is working. As an EE, i usually work with the I/O. It could be either Analog or Digital design but the hardware dictates what i write.</p>