AVR Freaks

Well that has nothing specifically to do with the AVR - have you tried googling that ?

 

eg,  https://www.digitalcitizen.life/what-are-drivers-why-do-you-need-them

 

https://docs.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/what-is-a-driver-

 

etc

Again, that has nothing specifically to do with the AVR.

 

I thought you said you were an experienced C++ programmer ?

 

The driver here is what turns the UART registers, interrupts, etc into the read/write system calls; 

 

ie, what turns the UART hardware into a COM: device on Windows, or a /dev/tty on linux

 

 

A UART or a COM port is just a means of transferring arbitrary, unstructured data;  it has no understanding of the meaning or purpose of the data its transferring - it's all just bytes.

 

The driver is what understands those bytes, and turns them into a video feed, or a printer device, or whatever.

 

EDIT

 

The others beat me to it

See #4 !

 

EDIT

 

Oops posted too soon

 

Does the Arduino have a drive in it to talk to my PC? 

Do it just sends bytes out of its UART, and receives bytes into its UART - it neither knows nor cares what is sending the bytes to it, or receiving the bytes from it.

 

 

What is the driver driving exactly?

 

Again, see #4. And it's nothing to do with the Arduino. This is standard computer stuff.

 

No - not really.

 

They are standard questions about the structure & operation of Linux (which, in this regard, is pretty much the same as Windows)

 

Did you follow the links I gave?

 

Did you do any further reading of your own?

 

I'm trying to understand it from a MCU point of view.

There is nothing to understand from the MCU's perspective - it is blissfully unaware of all of this!

 

 

 

So trying to tie it with how Arduino works, Is it like the software running on the atmega16u2 chip which acts as the USB to Serial converter? :

https://github.com/arduino/ArduinoCore-avr/blob/master/firmwares/atmegaxxu2/arduino-usbserial/Arduino-usbserial.c

Not really.

A driver is a program that connects a generic software interface to a real device, i.e.  On your PC you load a device specific driver for the type and brand of printer (for example) you have so any program that wants to "print" something can talk to the real hardware.   The operating system has defined how a program can talk to a device (printer, serial port, etc, "a software interface or API") but does not provide the code that actually talks to the device, as there are many such devices.   A driver is the glue between the operating system and the hardware (or software in the case of a PDF file creator).

 

Hope that helps.

Jim

 

While things have moved on in PCs these days and all the "peripherals" tend to be packed into a single chip from someone like Winbond the fact is that the PC design is as old as the hills (around 1980) and when it was designed the Intel 8088 CPU was connected to an Intel 8250 UART chip. By the time the 80286 PC AT came out they changed the design so that the 8250 was replaced by an updated UART called a 16550. This had things like buffers for received characters and stuff. But since then PCs have tended to have something mildly compatible to the 16550 even if it's only part of a WinBond or whatever. Now you know how in an AVR the UART is controlled by a set of registers such as:

 

 

and if you want to program this to send/receive characters you have to know what to put into things like UBRR0H/UBRR0L and UCSR0A and so on. You write "driver" software that puts the right values into these control registers and then further software that actually deals with waiting for UDRE/RXC then sending/receiving the actual bytes. 

 

We a PC with Windows/Linux is no real different. if the 8088/8086/80386/80486/Pentiumthat it is based on wants to use the 16550 UARt that is attached then it will have to deal with something very similar:

 

 

Sure this set of registers are a bit different to those you may know in an AVR UART but at the end of the day the action is all very similar. You write some baud registers to make the thing go at the speed you want, you write come control flags in other registers to configure it to operate in exactly the way you require. Then you have send/receive code that can handle the actual transmission/reception of the bytes to be conveyed (this time it's not one register called UDR but a couple called RHR and THR that hold the received byte or byte to be transmitted.

 

 

But to do that requires some PC software. Something that "knows the chip" and how to operate it. That is a driver. It's not really any different to that driving code you may have written for AVR (or someone else wrote for at the core of the Serial class if using Arduino). Thing is that Windows/Linux are "protect mode" operating systems. They no longer let any old software just write to whatever memory or IO address it chooses as one persons code could wreak havoc (or more importantly "snoop on") someone else's code. So to write to things like RHR and THR in IO space you need "special software". Software that knows how to play by the rules and do things the way the controlling operating system (Windows/Linux) wants things done. So it's no longer just a "UART driver" but a kernel space/"ring 0" driver that is granted special permission to make IO writes directly. 

 

if you followed the link Nigel gave earlier in #3 then nearby you may have spotted:

 

https://github.com/torvalds/linux/tree/master/drivers/tty/serial

 

which is a whole bunch of UART drivers for a whole bunch of different UART designs on a whole load of different CPU systems that Linux can run on. 8250 (and hence 16550) gets it own whole subdirectory there:

 

https://github.com/torvalds/linux/tree/master/drivers/tty/serial/8250

 

which are lots of different 8250/16550 support for a load of different 16550-alikes in a number of different (mainly PC) system designs.

 

Drivers are needed by an Operating systems, Arduino's don't have an OS. 

Arduino's (and I'm talking about UNO's here) run programs that the programmer has written that directly talks to the hardware (serial USART, in this case), so no driver required.

The UNO runs either the bootloader, which listens to and responds to application loading app on the PC (AVRDude), or an application sketch is running, which may, or may not use the USART.

The application sketch, has been written to send/receive data using the USART hardware if needed.

How much detail do you need, and why?

 

Jim

 

 

Yes - that's what I said in #4!

 

When your C++ code uses the read & write system calls, the C++ code is completely oblivious to what hardware is "behind" those calls.

 

It's the driver which provides that abstraction - so that your C++ code doesn't have to know or care anything about the hardware details.

 

the hardware might be

• a built-in UART as part of the motherboard chipset
• an add-on UART on a PCI card
• a USB-to-Serial device
• a network connection 
• an infrared link
• etc, etc, etc,

 

Your C++ code is completely oblivious - it just talks to COMx: or /dev/ttyx

 

It's the driver which converts from the specific hardware implementation to the generic, uniform COMx: or /dev/ttyx interface.

 

 

You appear to be very confused. What on earth makes you think a PC-USB-Printer connection has anything to do with a UART??

 i'm assuming it is going to also use UART 

You seem to confuse serial ports (UART based)  with USB (universal serial bus)...the only thing in common is the word serial.

 

They are vastly different things.  USB is both a hardware & full protocol (complex) specification. 

 

A serial UART, doesn't specify a standardized software protocol or framework. 

 

At best,  USB contains means to emulate the classic & somewhat obsolete UART connections as virtual comm port  (in concert with an interfacing chip: UART<<===>>USB).  

USB is "plug 'n play, with many useful attributes defined for different classes of interfaces, and even particulars to specific models of equipment.  UART has none of that.

Another way to ask this question would be: Why do we need drivers to begin with?

 

KI0BK reply #10 gives the reason we have drivers!  Could we do it another way?  Perhaps, but this is the path that has been taken.

Lastly I like to confirm my question in #13. Is this an AVR driver to write data to Serial:

It is simply AVR code to write to the UART-- it has nothing specifically to do with USB

 

A USB virtual comm port, with the proper uart<<===>>USB interface chip (and usb chip driver)  can then rcv the transmissions. 

All i'm doing is trying to find an actual code that is considered a "driver" on avr.

Why?  As stated this code will let you send data out the serial port to some undefined data consumer.  In that sense it is a driver to nothing in particular. 

 

If you said the AVR serial transmissions were being managed to monitor and command a railroad car (to deliver coal to your house), then you could say you had a railroad car driver. 

In that case the AVR knows something about railroad cars monitoring & control, timings, formats, etc to form a specific driver.

Yes

You can think of a driver as a black box software interface between two points...you get to specify those points.  They can be broad and generic, or very specific.

 

also:

A driver is software and/or firmware that controls hardware. Often it connects an operating system with specific hardware devices. For example, there are drivers for every card and disk in your computer. Each driver is written for a specific operating system — for example Windows XP or Macintosh OS X. Therefore, to use a card in your computer, you must use a driver that matches the device and also your operating system. Drivers can be enhanced, for example, when new operating systems come out. Eventually hardware becomes so old it is no longer economical or practical to produce new drivers for it.

Sometimes the words software, firmware and driver are used interchangably, so don't be thrown off if somebody uses the word "software" when you expected to hear "driver", or vice versa.

 

A utility is software used for the limited purpose of changing the overall behavior of hardware or other software. (For example configuring your browser to accept cookies.) 

I could have been to them, don't assume things, you don't know me.

True, but from the questions you are asking it seems doubtful, but I could be wrong, so apologies.

 

no ones forcing you to read my thread if it's wasting your time.

As a moderator I look at ALL posts in all forums everyday checking for possible spam, trolling or misplaced posts. Some posts I can be of help, others maybe over my head and can't be of any help. Some posts get deleted and some posters get banned, at times, if they are found to be spamming, not very common but it happens a few times a month.

 

 

You are over-thinking it. An AVR is not a replacement for your PC.

 

Buy a prototype board, a USB power supply for it, an ISP adaptor, a few resistors, LEDs, capacitors, a USB to serial lead and a few mega 328s.

 

Learn your way around the datasheet.

 

Blink an LED. Get 'Hello World' working, write to an LCD display, drive a servo. Measure the distance to objects with ultrasonics.

 

Or buy something like this...

 

 

 

In a word, EXPERIMENT. You will learn more in a weekend than you will by trying to equate what goes on inside your PC and OS to how the AVR works.

 

Drivers, Yield(), Sleep(), etc are meaningless on the AVR until you have learned the basics.

 

The simple fact is, as mentioned many times above, that you access your MCU UART with ordinary software. Normally, it is a simple, integral part of the program and not easily separated into something called "a driver". 

 

Often, the receive function will be handled in an interrupt. YOU choose what to do with the characters once read from the UART. Nothing special.

 

The transmit function can also be handled by interrupt or by polling in the main() loop. No special code (e.g. nothing any usual person would call a "driver"). Your routine checks whether (a) there is a character ready to send and (b) whether the transmit part of the UART is not busy. If both of these are true, it writes to the UDR and maybe increments a transmit buffer index or pointer. Done. Simple. Nothing so fancy as a driver. Code? Absolutely! But, would I call it a driver? Why bother? It is an integral part of code.

 

Side note: I am starting up on a new project using Mega4809. That has 4 UARTs. Every one is configured differently. Two will not (normally) even operate as UART but will be SPI, instead. The two remaining ones will be configured quite differently. Am I going to use "drivers"? What ever I use, I won't call them that, because they are "just code".

 

Jim

There's 2 different lines in the sand.  Can we get 8 more?  (just kidding)

To be honest it's not a great idea to intermingle code in such a way. Far better to keep things like UART and ADC module drivers as separately developed/testable entities.