The Raw ATMega2560 or the Arduino MEGA 2560
If the latter then as i pointed out above The MEGA 2560 is NOT doing any USB it is only doing USART Serial like any of the Hundreds of PIC devices.
The Arduino board has a seperate USB/Serial converter chip external to the ATMega Chip.
Last edit: Chris Roper 2018-12-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes.
It is talking via USB CDC to a USB / Serial Converter Chip on the Arduino Board that is connected to PIN's 0 and 1 i.e Com0 of the Atmel device - Its USART.
Last edit: Chris Roper 2018-12-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As of today, Dec 18, the USB capability is NOT a USB-TTL emulator. AUSB-TTL emulatorwould be a USB CDC solution - we have implemented a USB LibK solution.
USB LibK class devices
The most straight forward way to implement a USB device is by choosing class Custom, which basically means that you comply to no known class. We have used USB LibK to enable this.
Data can be transferred in blocks up to 254 bytes in both directions over the default control endpoint. An example for a very simple custom class device is PowerSwitch. If required, interrupt endpoints can be added for stream-type data or to send spontaneous notifications to the host. An example for this can be found in the RemoteSensor project.
Advantages:
Easy to implement on the device.
Easy to write host side software on Windows and Unix.
Disadvantages:
On Windows, a driver LIbK DLL must be installed. This means that the host application can't be run without installation.
You need software for the host to control the device - we have provided the in the demo.
USB CDC class devices
The USB CDC class was intended for modems and other communication devices. Implementing this class, it is possible to simulate a modem and thus a serial interface ("virtual com port"). Drivers for this class are included in all modern operating systems.
CDC requires bulk endpoints which are forbidden for low speed devices by the USB specification. However, most operating systems don't care and CDC works. There are still many drawbacks involved (see disadvantages below) and the main purpose of implementing this class is to simulate older devices which had a serial interface.
Advantages:
Devices compatible to old serial gadgets can be built.
Communication parameters (bit rate, parity etc.) can't be wrong because they are ignored.
Host side programming interface is well known and understood by most hobbyists.
Disadvantages:
Violates the standard.
Does not work with some versions of Windows and Linux (in combination with particular USB host controllers).
Consumes ca. 90% or more of the microcontrollers CPU time because bulk endpoints are polled aggressively by the host. Real-time applications on the microcontrollers are close to impossible.
May become unreliable if other interrupts are used on the microcontrollers.
Requires an INF file on Windows which binds the device to the CDC driver DLLs. These DLLs differ from Windows version to version but these are included in most operating systems.
Development Tools
We have provided a Windows demonstration application. This required either SharpDevelop or Visual Studio.
Once the demonstration software is loaded into the SharpDevelop or Visual Studio IDE you can easily adapt to add more functionality.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The Raw ATMega2560 or the Arduino MEGA 2560
If the latter then as i pointed out above The MEGA 2560 is NOT doing any USB it is only doing USART Serial like any of the Hundreds of PIC devices.
The Arduino board has a seperate USB/Serial converter chip external to the ATMega Chip.
Last edit: Chris Roper 2018-12-17
Does the line open com "COM7:9600,N,8,1,ds0" as 2 in the freebasic code mean it's using serial not usb like using uno, gcb terminal and serprint?
Yes.
It is talking via USB CDC to a USB / Serial Converter Chip on the Arduino Board that is connected to PIN's 0 and 1 i.e Com0 of the Atmel device - Its USART.
Last edit: Chris Roper 2018-12-17
Let me be clear - to avoid confusion.
As of today, Dec 18, the USB capability is NOT a USB-TTL emulator. AUSB-TTL emulatorwould be a USB CDC solution - we have implemented a USB LibK solution.
USB LibK class devices
The most straight forward way to implement a USB device is by choosing class Custom, which basically means that you comply to no known class. We have used USB LibK to enable this.
Data can be transferred in blocks up to 254 bytes in both directions over the default control endpoint. An example for a very simple custom class device is PowerSwitch. If required, interrupt endpoints can be added for stream-type data or to send spontaneous notifications to the host. An example for this can be found in the RemoteSensor project.
Advantages:
Easy to implement on the device.
Easy to write host side software on Windows and Unix.
Disadvantages:
On Windows, a driver LIbK DLL must be installed. This means that the host application can't be run without installation.
You need software for the host to control the device - we have provided the in the demo.
USB CDC class devices
The USB CDC class was intended for modems and other communication devices. Implementing this class, it is possible to simulate a modem and thus a serial interface ("virtual com port"). Drivers for this class are included in all modern operating systems.
CDC requires bulk endpoints which are forbidden for low speed devices by the USB specification. However, most operating systems don't care and CDC works. There are still many drawbacks involved (see disadvantages below) and the main purpose of implementing this class is to simulate older devices which had a serial interface.
Advantages:
Devices compatible to old serial gadgets can be built.
Communication parameters (bit rate, parity etc.) can't be wrong because they are ignored.
Host side programming interface is well known and understood by most hobbyists.
Disadvantages:
Violates the standard.
Does not work with some versions of Windows and Linux (in combination with particular USB host controllers).
Consumes ca. 90% or more of the microcontrollers CPU time because bulk endpoints are polled aggressively by the host. Real-time applications on the microcontrollers are close to impossible.
May become unreliable if other interrupts are used on the microcontrollers.
Requires an INF file on Windows which binds the device to the CDC driver DLLs. These DLLs differ from Windows version to version but these are included in most operating systems.
Development Tools
We have provided a Windows demonstration application. This required either SharpDevelop or Visual Studio.
Once the demonstration software is loaded into the SharpDevelop or Visual Studio IDE you can easily adapt to add more functionality.