Do we need a driver to talk to atmega328p from a PC

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

This question is more specific to Linux and how drivers are needed to talk to other peripherals.

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

 

My PC has a UART hardware built in it. I plugin my Arduino board. I start a Serial communication using the terminal. At it's core,

the terminal uses read/write system calls from the kernel space to send and receive data from the PC UART to Arduino UART.

 

Now are there any pre installed drivers involved here? 

 

If I plug a webcam or a printer to the same Serial port I need to install a driver. Why is that? Why can't the UART hardwares send data to each other like the above example. I would assume there is a piece of software on the other peripheral (much like the Arduino boot loader) which handles the received data from UART and puts in in the correct locations/registers.

This topic has a solution.
Last Edited: Fri. Jul 10, 2020 - 07:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avruser1523 wrote:
My PC has a UART hardware built in it.
Really? In 2020? Anyway traditional PC uarts will be supported in Linux as pretty standard /dev/tty0 or something. The kernel already has inbuilt driver support for things like 16550 UARTs so you don't need anything special.

 

As this is 2020 in fact most people connect micros to PCs with USB-UART or USB-RS232 cables that implement a CDC-ACM class device interface. As Linux has standard CDC-ACM driver support already in the kernel these things would generally appear as /dev/USBtty0 or something along those lines.

 

"Drivers" that you add to kernels whether in Linux or Windows tend to be to support "unusual" features that the generic kernel does not "know" about but many device manufacturers strive to get their device support added into the kernel for the very notion that the end user won't be troubled about messy driver installation and updates etc.

 

BTW I am going to move this thread from this forum because like some of your previous "general question" threads this isn't really anything to do with Tiny/Mega AVRs (subject of this forum).

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

avruser1523 wrote:
Now are there any pre installed drivers involved here? 

Of course; here's the code - https://github.com/torvalds/linux/tree/master/drivers/tty/serdev

 

 

Last Edited: Fri. Jul 10, 2020 - 02:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avruser1523 wrote:
Why do we need drivers to begin with?

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

avruser1523 wrote:
My PC has a UART hardware built in it. I plugin my Arduino board. I start a Serial communication using the terminal. At it's core,

the terminal uses read/write system calls from the kernel space to send and receive data from the PC UART to Arduino UART.

 

Now are there any pre installed drivers involved here? 

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

 

avruser1523 wrote:
If I plug a webcam or a printer to the same Serial port I need to install a driver. Why is that?

 

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

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Fri. Jul 10, 2020 - 02:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The kernel already has inbuilt driver support for things like 16550 UART

 

This is the part I don't get. What does the inbuilt driver do? Does the Arduino have a drive in it to talk to my PC? (If it doesn't have one then why does my PC need a driver to talk to it).

 

You just send bits on a wire and receive the same bits from the other end. What is the driver driving exactly?

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

avruser1523 wrote:
What does the inbuilt driver do?

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.

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Fri. Jul 10, 2020 - 02:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
I thought you said you were an experienced C++ programmer ?

Again these are hardware questions, not related to C++.

 

awneil wrote:
Well that has nothing specifically to do with the AVR

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

 

awneil wrote:
The driver is what understands those bytes, and turns them into a video feed

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

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

avruser1523 wrote:
these are hardware questions,

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.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
Did you follow the links I gave

Yes I did, I have googled a lot. Articles usually don't go into much detail and keep saying "it's what talks to the hardware". Well ye I know that already.

 

awneil wrote:
Not really.

So then I still have no clue what a driver does. All this time I thought that's what a driver is.

 

 

You know instead of being so passive aggressive and asking if I know c++ or if I have googled can you just give a clear example on what it is?

Last Edited: Fri. Jul 10, 2020 - 02:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

 

 

FF = PI > S.E.T

 

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

Thanks Jim, but your definition was similar to other articles, not enough detail.

 

I used Arduino to be able to ask my question as best as I can.

 

If as awneil mentioned Arduino has no builtin driver in it:

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 

Then how does it interpret those bytes? 

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


avruser1523 wrote:
This is the part I don't get. What does the inbuilt driver do?
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.

 

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

Above was a great explanation.

 

clawson wrote:
You write "driver" software that puts the right values into these control registers

So then this is an example of a driver which will run on the AVR chip to send data to my PC, correct?

https://github.com/arduino/ArduinoCore-avr/blob/master/cores/arduino/HardwareSerial.cpp#L225

 

On Linux, does the system call end up calling a driver or the other way around?

Let's say there is a write system call. Im guessing it will end up calling a driver which will put the data into the correct registers which will get pushed out by the hardware itself? So the driver is the last piece of code before hardware kicks in.

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

avruser1523 wrote:
This is the part I don't get. What does the inbuilt driver do?

I'm sure the veil will lift somewhat if you peruse some of the linux code. You don't need to understand the code at all; just read the comments and function names.

 

Here's just one example function:

static void stm32_tx_interrupt_enable(struct uart_port *port) ;

 

In this directory https://github.com/torvalds/linux/tree/master/drivers/tty/serial you will find linux code to handle Atmel UARTS, STM32 UARTS and also PIC32 UARTS amongst others. Realise that linux runs on wildly varying hardware so can assume nothing about it - hence the huge number of files (drivers) to cope with all the various UART hardware it may encounter.

 

Note also your AVR software also has a driver for it's UART. Because its usually integrated into application code you just don't recognise it as such.

 

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

@OP

 

I suggest you read, and understand, this...

 

https://en.wikipedia.org/wiki/OS...

 

 

#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

avruser1523 wrote:

Thanks Jim, but your definition was similar to other articles, not enough detail.

 

I used Arduino to be able to ask my question as best as I can.

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

 

 

 

FF = PI > S.E.T

 

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

In the old days there was a C function "stty" (implemented as system call) which provided programming API much like the "stty" command API (which still exists).

Now it seems more complicated.  I have to do some other magic.   Try "man ptmx" or web search for ptmx, grantpt, unlockpt, fcntl, ...

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

avruser1523 wrote:
Let's say there is a write system call. Im guessing it will end up calling a driver which will put the data into the correct registers which will get pushed out by the hardware itself? 

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.

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Fri. Jul 10, 2020 - 04:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

 

Thank you, so to confirm, is what i said in #13 correct? that's considered a driver on Arduino?

 

Another thing:

It was mentioned this repo has Linux drivers for UART:

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

 

If a printer is also connecting to a PC via USB i'm assuming it is going to also use UART (or some other Serial protocol converted form USB) in which case Linux should already have all the drivers.

It should be able to use the same drivers to send data to the printer? Why do we need to install extra drivers then?

 

Edit:

Im assuming the driver is what converts the data then calls the UART driver; so
 

I click print -> printer driver picks up the data -> converts them to what the printer HW understand -> makes system calls such as write, which will call the UART drivers -> UART driver picks up the converted data and puts them on the correct UART registers -> data is sent over

Last Edited: Fri. Jul 10, 2020 - 06:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

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

clawson wrote:
You appear to be very confused

Yup, and that's why i'm here.

 

clawson wrote:
What on earth makes you think a PC-USB-Printer connection has anything to do with a UART

because that's how Arduino works? That's my reference in terms of HW connections right now.

I thought every connection is Serial? either SPI, or UART, or I2C, or maybe direct USB and no conversion?

 

Edit:

 

You mentioned they are mostly done with CDC-ACM these days, so USB without any conversion:

 

I click print -> OS makes system calls such as write, which will call the printer drivers -> printer driver picks up the data (convert them in needed) and puts them on correct registers -> data is sent over USB

 

 

Last Edited: Fri. Jul 10, 2020 - 07:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 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.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Fri. Jul 10, 2020 - 07:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Arduino doesnt have USB host. How on earth could it host a Class device like Printer??

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

clawson wrote:
Arduino doesnt have USB host. How on earth could it host a Class device like Printer??

 

No no, i knew it doesn't. I'm just using it as a reference.

 

You seem to confuse serial ports (UART based)  with USB

So printers use direct USB connections, no conversion at all.

 

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

https://github.com/arduino/ArduinoCore-avr/blob/master/cores/arduino/HardwareSerial.cpp#L225

 

 

Last Edited: Fri. Jul 10, 2020 - 07:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As I wrote in another of your threads: You assume way too much! Read before assuming...

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

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. 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Fri. Jul 10, 2020 - 07:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
it has nothing to do with USB 

But is it a driver?

 

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

 

 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. 

according to this definition given at #12, it should be a driver! 

Last Edited: Fri. Jul 10, 2020 - 07:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Fri. Jul 10, 2020 - 07:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
Why? 

Because I learn by seeing actual examples.

 

If this  repo has UART drivers for Linux:https://github.com/torvalds/linux/tree/master/drivers/tty/serial

 

Then this has to be an example of a UART driver for avr, developed by Arduino: https://github.com/arduino/ArduinoCore-avr/blob/master/cores/arduino/HardwareSerial.cpp#L225

 

That's what i'm trying to confirm.

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

avruser1523 wrote:
But is it a driver?

Yes

 

FF = PI > S.E.T

 

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

ki0bk wrote:
Yes
Thank you so much.

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

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:

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.

 

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.) 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

Yup, and that's why i'm here.

No, you should be at a university or college doing electronics and programming!

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

The upside of the 'modules are the new components' maker culture is that it's easy to create things some of us could only have dreamed of in our teens (c 40 years ago).

 

The downside is nobody learns the basics of electronics and computing any more. I suppose one could argue that the current degree of complexity means you'd need those 40 years to learn it all :)

 

PC program -> device file -> filesystem driver-> kernel -> USB and CDC drivers -> USB bus -> USB/serial adapter -> TTL serial protocol -> MCU UART & registers -> MCU program (at least).

Last Edited: Sat. Jul 11, 2020 - 12:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I suppose one could argue that the current degree of complexity means you'd need those 40 years to learn it all :)

In a few years someone's gonna say these microcontrollers are too large & complex & in the hands of the programming elite.  Then a movement will come along saying we have these new computers called picocontrollers. that are smaller, faster, and easier to use...and the micro users will dismiss them, saying what use would such a low level chip have?  Who would want such a thing? There is no future in those, we have our fancy microcontroller systems!! 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

js wrote:
No, you should be at a university or college doing electronics and programming!

I could have been to them, don't assume things, you don't know me. electronics and programming are 2 very different fields plus no ones forcing you to read my thread if it's wasting your time.

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

@OP Have you read the Web page I linked to about 20 posts ago?

#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

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.

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Brian Fairchild wrote:
Have you read the Web page I linked to about 20 posts ago?

Yes I was familiar with OSI from networking.

But it's too theoretical. I was looking for a specific example of what a "driver" does in Arduino. It's my frame of reference as the most basic "computer hardware" right now,

without all the complexity added by CISC and operating systems.

 

Last Edited: Sat. Jul 11, 2020 - 01:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The concept is ‘abstraction’. Be it a hardware interface or a 3d raytracer. Add layers to increase functionality and hide complexity.

What does CISC have to do with any of this?

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

Kartman wrote:
What does CISC have to do with any of this?

There is a line where software ends and hardware starts. That line could be when instructions getting decoded in CPU, or when a driver puts values in registers and hardware takes it from there.

I'm trying learn that line in more detail using Arduino as a replacement of my PC. Since my PC is CISC and a nightmare to get into its detail. Mem management, Paging, Cache, Multithreading, Complex pipelines, etc. etc. too much.

 

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

 

avruser1523 wrote:

I'm trying learn that line in more detail using Arduino as a replacement of my PC. Since my PC is CISC and a nightmare to get into its detail. Mem management, Paging, Cache, Multithreading, Complex pipelines, etc. etc. too much.

 

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.

 

#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."

Last Edited: Sat. Jul 11, 2020 - 03:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If your goal is simply to see sone "driver" code for an AVR then just google "peter fleury AVR". He has well respected driver code for all of TWI/I2C, UART and HD44780.

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

Again you seem to be confusing terms. The processor in my pocket is RISC and it has all of that - multi core, demand paged virtual memory, caching and a complex pipeline. As such, each of these are fairly simple constructs.
Your knack of using buzzwords and forming an assumption is becoming an art form.

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

 That line could be when instructions getting decoded in CPU, or when a driver puts values in registers and hardware takes it from there.

I'm trying learn that line in more detail

Well you probably won't, because 10 people will draw 10 different lines in the sand.    

 

Say you have a motion control system that has some code that generates coordinates so a motorized saw can cut out different clown faces.  Maybe there are 3 brands of motorized saws that are rather different.  The clown face drawing code knows nothing about controlling motor windings, so instead it can enlist the help of a driver that does know about which transistors to turn on,  frequencies, voltage limits, etc, and perhaps variations for different saw brands that might be selected.  In this case, the driver is directly controlling the motor electronics.

 

More likely, the saw has some smarts & an internal processor & code for itself to keep things safe, prevent overheating, monitoring blade rpm & to make control interfacing a bit simpler (forming a higher level interfacing).  The saw processor has the job of controlling transistors and saw sensors.  In this case, a driver knows how to communicate the clownface data into commands needed by the specific brand of saw....data formats, handshaking, error codes, status bytes, etc.

 

You could apply this to an Arduino or PC or tablet or phone...write some clown face generating code, get some smart motors, and write a driver to control them.  You can't clown around without the drivers.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sun. Jul 12, 2020 - 01:01 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Sun. Jul 12, 2020 - 01:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Unusually i have to disagree with Jim. I would always call the support code for a peripheral a "driver" whether in OS context or not.

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

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

Letting the smoke out since 1978

 

 

 

 

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

I think Jim may be pointing out that in simpler cases the uart code might not be separable, but woven together with other lines of code (checking a switch, turning on an led, reading the adc, calculating pi...). so one line over here to send a char, another line elsewhere in the code to check the rcv flag, some other line elsewhere to set the baud register.   So it becomes a My_Led_ADC_Uart_Picalc driver, or simply "the code".

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

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.

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

imho, to be a driver, a piece of code should provide a common or familiar interface to a class of devices, hiding the precise complexities of a particular instance of that device. 

 

e.g. all UARTs do pretty much the same thing, regardless of physical implementation. You want to configure it, and then read and write characters. You may want flow control, etc.

 

Also, there may be a hierarchy of dependencies, e.g. the different USB device classes implemented over a common USB transport. Thus, the interface between the CDC class driver and the USB interface device driver should be written to common standards, so that different people can provide different parts, and drivers from difference sources can be expected to play nicely together, without having to reimplement the entire driver stack from scratch each time.

 

The OSI model is a good example in the networking and comms space. You can add a new TCP sub-protocol without having to recode for every network interface card that ever existed.

 

As commented upthread, this all promotes reusability, testability, and is generally more efficient and effective. 

 

By that definition, most of the Arduino code and libraries is just drivers.