Firmware programming / drivers - not understanding the separation - Page 1
Forum section: electronics / beginners

author: embeddedguy85
author_rank: Contributor
timestamp: October 14, 2017, 07:05:45 pm
content: I'm not really understanding the software competent to electronics. I understand that firmware is software held in ROM.But my questions are1) do you need to write new firmware for every board you buy from a place like digikey?2) do you have to write drivers for the onboard devices/controllers or just the devices you connect to the board?3) if an RTOS is used, how are the applications layered on top? Is the code simply inserted into the RTOS code?

author: odessa
author_rank: Regular Contributor
timestamp: October 14, 2017, 07:53:26 pm
content: Hi,What sort of board do you mean ?I write firmware for embedded systems, mainly Pic's. So if I connect any peripherals to my 'board' I would need to use/write drivers to support them.

author: embeddedguy85
author_rank: Contributor
timestamp: October 14, 2017, 07:55:23 pm
content: What type of firmware? What does your software do without peripherals connected to it?

author: odessa
author_rank: Regular Contributor
timestamp: October 14, 2017, 08:01:20 pm
content: I write firmware for security equipment. It controls the motors and sensors attached to the main CPU.The main CPU has a PIC micro on it which is connected to all the other boards running other Pic's.The software would be useless with nothing connected as it relies on the other boards to provide the feedback the main board needs to run.

author: dmills
author_rank: Super Contributor
timestamp: October 14, 2017, 08:02:06 pm
content: It depends on the board.For small processor sort of boards:Often there is a so called BSP (Board support package) that has at least skeleton drivers for at least a subset of the interesting things, even if 'driver' is in fact just a page of C that gives you a starting point for configuring the registers.In practise you usually take that code and end up writing a version that better fits what you are trying to achieve.If you are clever about it you can manage to abstract away a lot of the low level stuff which often needs a rewrite for a new board from the higher level logic that usually stays the same, and can do something similar for chip specific drivers. So for example the SPI or I2C driver is almost always specific to a processor family, but a driver for a certain IO expander should be able to be designed to use a reasonable sort of abstraction of an I2C port to make it almost processor agnostic.Small core RTOS are usually just a library that handles scheduling and some IPC, they may or may not come with much in the way of drivers.On bigger machines the BSP is often some sort of a Linux with all that that implies, hopefully including drivers.regards, Dan.

author: Nusa
author_rank: Super Contributor
timestamp: October 14, 2017, 08:08:15 pm
content: Quote from: embeddedguy85 on October 14, 2017, 07:05:45 pm1) It depends on the nature of the board. Boards with obvious purposes may include the required firmware at purchase and/or various versions of firmware may be available from the original vendor.2) Generally the latter. You don't have to support things you don't use. However, everything I said for (1) applies here too. Also, the required code may be available online, particularly from open source projects.3) Maybe. There's too many ways things can be done to give a generic answer with no details or requirements.