Do you have experience in device driver development

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi 

What employers are looking for when they mention device driver. In a job ads, it mentions this: Proficient in device driver and C++ programming. I can understand the Embedded C++ , but what are they looking for when they say device driver?? Like what do they expect to do regarding "Proficient in device driver"

Thanks guys

Last Edited: Sun. Mar 22, 2020 - 01:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As a guess...something based around embedded Linux.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Agree, it almost certainly means Linux kernel drivers. Google "rubini" for the (free!) bible on the subject.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

"Device drivers" are the code pieces that connect a physical device to the operating system of the PC.  If people are actually looking for someone to do this for them, and are prepared to pay them serious money, then the operating system is most likely Windows 10.

   A device driver will send initialization and data-exchange format information to the peripheral.  It will format for Windows any data received from the peripheral.  Device drivers usually have small file sizes because they are often written in the Intel X86 assembler for the CPU-family used in most PCs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simonetta wrote:

"Device drivers" are the code pieces that connect a physical device to the operating system of the PC.  If people are actually looking for someone to do this for them, and are prepared to pay them serious money, then the operating system is most likely Windows 10.

 

I understand device driver for PC but I think the work of PC software developer and embedded software developer is different. Embedded systems do not have OS

 

Has anyone developed a device driver for a company that was part of embedded system ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A lot (the majority?) of embedded devices are ARM based. The ones based on Cortex-A rather than Cortex-M run an application operating system and in the vast majority of cases that OS is Linux so there is a LOT of embedded driver development for Linux in "large" embedded products. A lot of employers work in this realm and are desparate for anyone who has the skill to develop such software. So it can pay well if you invest in learning.

Last Edited: Sun. Mar 22, 2020 - 04:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You may also want to understand how the device driver interface can be used to shield the company's software from the requirements of the Linux GPL. I think understanding that could score some points as a device driver developer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simonetta wrote:
Device drivers usually have small file sizes because they are often written in the Intel X86 assembler for the CPU-family used in most PCs.

I can't speak to before Windows NT4, but all drivers for NT4 and later were/are written entirely in C.  Sure there is the odd case where an assembly shim is needed but Microsoft were very adamant about device drivers being written in C.  With the advent of WDF (windows driver framework, somewhere around the release of win7 IIRC) there is now some limited use of C++ in windows drivers.

Letting the smoke out since 1978

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Proficient in device driver and C++ programming.

As written, that's pretty ambiguous.

There are essentially two halves to a "device driver" - there's the half that is your code manipulating device hardware, and there is the half that your code is interfacing to higher levels of software (an operating system like wnidows or linux, or perhaps just a common API like Arduino.)

The hardware side involves understanding how to go from a datasheet to code - how to access IO registers, use of volatile, atomicity, the true nature of time, interrupts, dma, things that are set to zero when you write a one, common buffering schemes,  common protocols at a low level (UART, SPI, I2C, Ethernet, USB); stuff like that.  You should be confident that you can write a Serial driver for a weird uart without having to resort to ASF or Cube or some Arduino library, in several variations (polled, interrupt-driven, ...)

The other half is understanding what other software has to use your driver.  API standards, locking mechanisms, use of shared resources, memory protection, security issues, portability...

 

Without an OS qualifier ("linux device drivers") or context, I'd expect the description in the OP to be wanting someone more familiar with the hardware side.  But it could just be poorly written (perhaps after modification by clueless HR types.  Sigh.)
It could mean anything from "we just want someone who doesn't need to ask what 'volatile' means" to "we want someone who has the Intel xxx chipset Red Books nearly memorized so that we can interface our FPGA-based weird IO device directly to a zzzz bus with maximum performance."

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Embedded systems frequently have an OS like linux. TVs, mobile phones, wireless routers, webcams, gps navigators, smart touch screen, ring, amazon listening device will most likely run Linux. Embedded is no longer just a single chip micro flashing lights.
As Bill (westfw) points out, the requirement is for someone both electronic engineer and software engineer - someone who can read the datasheets and write code.
Having dealt with employment agencies recently, what you get asked can be nothing like what the employer actually wants.