Benutzer:Rdiez/ArduinoDue - Versionsgeschichte

Rdiez: Weiterleitung nach Benutzer:Rdiez/PageRemoved erstellt

2015-04-04T14:44:50Z

Weiterleitung nach Benutzer:Rdiez/PageRemoved erstellt

Änderungen zeigen

Rdiez: Referenz auf DigiX.

2014-01-24T19:57:43Z

Referenz auf DigiX.

Rdiez: Weitere JTAG Notizen.

2014-01-24T19:53:19Z

Weitere JTAG Notizen.

Rdiez: The AT91SAM3X8E is not becoming cheaper

2013-09-20T18:49:00Z

The AT91SAM3X8E is not becoming cheaper

Rdiez: The latest OpenOCD version is 0.7.0, not 0.8.0.

2013-06-07T19:22:01Z

The latest OpenOCD version is 0.7.0, not 0.8.0.

Rdiez: Several small fixes and improvements.

2013-06-06T18:43:42Z

Several small fixes and improvements.

Rdiez: No Ethernet PHY

2013-06-03T19:20:25Z

No Ethernet PHY

Rdiez: Use "pitch" and add inch value for the JTAG connector

2013-06-02T19:05:12Z

Use "pitch" and add inch value for the JTAG connector

Rdiez: {{BenutzerSeitenNichtVeraendernWarnung|rdiez}}

2013-05-24T17:13:36Z

Rdiez: More USB ID info

2013-05-24T17:10:44Z

More USB ID info

@@ Zeile 6: / Zeile 6: @@
 * Popular platform, well supported, reasonably priced.
-* Open-source hardware. <br/> Hopefully this will lead to lower prices and longer availability.
+* Open-source hardware. <br/> Hopefully this will lead to lower prices and longer availability. Later note: There is an upcoming Kickstarter project named DigiX that looks promising. The CPU specs are the same, but the board will come with more built-in peripherals. Unfortunately, there is no sight of any cheaper clones yet.
 * 32-bit CPU with good toolchain support. <br/> After having some negative experiences with GCC's PowerPC and AVR support, which are supposed to be stable after so many years of widespread usage, the ARM port looks much more polished.
 * High Speed (480 Mbps) USB tranfers (effective throughput up to 35 MB/s or 280 Mbit/s). <br/> This is about time, the USB 2.0 spec was released in April 2000 (!). <br/> Most ARM microcontrollers support only the 11 Mbit/s mode (as of 2013).

@@ Zeile 45: / Zeile 45: @@
 * The board has a single user LED and no user buttons whatsoever, let alone any kind of display or sound ability. <br/> You need extra hardware for the most simple of tests.
 * There is no Ethernet connector, even though the microcontroller does support it. What is worse, there is no way to manually add an Ethernet PHY, because the right pins are simply not accessible.
-* Serious hackers will need a [http://en.wikipedia.org/wiki/In-circuit_emulator JTAG-based hardware debugger], which costs at least 50 €. <br/> There are some cheap USB-Blaster clones for 10 € in Ebay, but I haven't been able to make mine work properly yet. <br/> The Arduino designers added a separate 8-bit AVR CPU in order to update the main microcontroller firmware over the "programming" USB port. What a complete waste of time! They could have added some existing JTAG-over-USB chip, or they could have made one themselves by connecting that little AVR to the JTAG wires.
+* Serious hackers will need a [http://en.wikipedia.org/wiki/In-circuit_emulator JTAG-based hardware debugger], which costs at least 50 €. <br/> There are some cheap USB-Blaster clones for 10 € in Ebay, but I haven't been able to make mine work properly yet. <br/> The Arduino Due designers added a separate 8-bit AVR CPU in order to update the main microcontroller firmware over the "programming" USB port. What a complete waste of time! They could have added some existing JTAG-over-USB chip, or they could have made one themselves by connecting that little AVR to the JTAG wires. <br/> In the meantime, you can use [https://github.com/rdiez/JtagDue a second Arduino Due as a JTAG Adapter].
 * The JTAG header is smaller than usual, it has a 1.27 mm pitch (Samtec 0.05" micro header) instead of the normal 2.54 mm (0.1"). <br/> Most hackers will have to pay extra for an adapter like Olimex' ARM-JTAG-20-10. If you have an Atmel JTAGICE3, look for an adapter in the box.
 * You'll probably need buy extra USB cables too. <br/> The board has 2 USB ports, the "native" USB socket is of type Micro-A, and the "programming" one is of type Micro-B. It may be my bad luck, but all devices I use have the Mini-B connector (Bus Pirate, USB-Blaster, AVR JTAGICE3, Wind River probe...), so I didn't have the right cable at hand. Of course there isn't one in the Arduino Due box either. Wasn't USB supposed to be standard? Apparently, there is a type of USB cable that fits in both Micro-A and Micro-B connectors, but the documentation offers no advice about this either. I wonder why there are 2 types of Micro USB connectors then, it's just confusing. To top it all, both sockets have such a tight grip that I worry they will break or wear out soon if I need to plug and unplug USB cables often.

@@ Zeile 39: / Zeile 39: @@
 * The board comes with no "Getting Started" information whatsoever. <br /> The only piece of paper in the package sports some marketing blurb and tries to justify the price with statement "The people who made your board were reasonably paid". It should at least mention that you may want to load the blinking demo sketch, in order to check if the board is minimally working.
-* It is relatively expensive compared to more powerful platforms like the Rasperry Pi, the Beagle Bone and many of the microcontroller evaluation boards. <br/> Due to the low availability 4 months after release date I ended up paying 59 € for it, and that hurts if you manage to fry it during your experiments.
+* It is relatively expensive compared to more powerful platforms like the Rasperry Pi, the Beagle Bone and many of the microcontroller evaluation boards. <br/> Due to the low availability 4 months after release date I ended up paying 59 € for it, and that hurts if you manage to fry it during your experiments. <br/> The price is probably not going to come down significantly, as the Atmel AT91SAM3X8E now costs more than its SAM4 successors. This kind of ARM chips evolve quickly, and the older ones do not seem to get cheaper, they just get replaced fast. I suspect that any cheaper Arduino Due replacement will have to use a different CPU, and some software changes will be necessary. Therefore, the current incarnation will probably not become popular after all.
 * The development environment has no integrated debugger (!).
 * Launching a program, however small, takes a few seconds. <br/> That is quite a long time for such a modern board, it goes on your nerves. Maybe it is due to the beta development environment version 1.5.2 I tested, but why is it still beta? The release date was 22nd October 2012, more than 4 months ago.

@@ Zeile 255: / Zeile 255: @@
    openocd  -f your-jtag-adapter.cfg  -f target/at91sam3ax_8x.cfg  -f arduino-due.cfg
-Configuration file ''target/at91sam3ax_8x.cfg'' comes with OpenOCD version 0.8.0, so it should be able to find it automatically.
+Configuration file ''target/at91sam3ax_8x.cfg'' comes with OpenOCD version 0.7.0, so it should be able to find it automatically.
 For older OpenOCD versions use file ''at91sam3XXX.cfg'' instead.
@@ Zeile 262: / Zeile 262: @@
 === Caveats ===
-The [http://dangerousprototypes.com/docs/Bus_Pirate Bus Pirate] is very slow as a JTAG adapter, you should expect speeds under 1 KiB/s when downloading new firmware to the Arduino Due. If you manually patch OpenOCD version 0.8.0 so that setting "buspirate_speed fast" works, you can expect transfer rates of 8 KiB/s.
+The [http://dangerousprototypes.com/docs/Bus_Pirate Bus Pirate] is very slow as a JTAG adapter, you should expect speeds under 1 KiB/s when downloading new firmware to the Arduino Due. If you manually patch OpenOCD version 0.7.0 so that setting "buspirate_speed fast" works, you can expect transfer rates of 8 KiB/s.
 Firmware version v6.1 (current as of feb 2013) has a bug that might make you physically disconnect the USB cable often.
@@ Zeile 285: / Zeile 285: @@
   buspirate_port /dev/buspirate
-  # In order for the 'fast' setting to work you will probably need to manually patch OpenOCD (as of version 0.8.0).
+  # In order for the 'fast' setting to work you will probably need to manually patch OpenOCD (as of version 0.7.0).
   buspirate_speed normal  # 'normal' or 'fast'.

@@ Zeile 29: / Zeile 29: @@
 ** No floating point support.
 * 84 MHz clock frequency.
-* 2 x 256 KBytes Flash.
+* 2 x 256 KiB Flash.
-* 64 + 32 KBytes RAM.
+* 64 + 32 KiB RAM.
 * The "native" USB port and can do High Speed USB 2.0 (480 Mbit/s).
 * JTAG port
@@ Zeile 184: / Zeile 184: @@
    Leading bit:  1  # Always set to 1 according to the IEEE standard 1149.1
-Note that, if you connect the JTAG_RST signal and you JTAG probe holds it deasserted most of the time, the ATmega16U2 AVR microcontroller may no longer be able to trigger a reset when you connect to the 'Programming' USB serial port.
+Note that, if you connect the JTAG_RST signal and you JTAG probe actively holds it high most of the time, the ATmega16U2 AVR microcontroller may no longer be able to trigger a reset when you connect to the 'Programming' USB serial port.
 If you abruptly disconnect the JTAG cable, you may leave breakpoints behind that, when triggered, will forever freeze the CPU. The JTAG logic on the CPUs does not normally detect the loss of the JTAG debugger, so always disconnect gracefully or reset the device after debugging.
@@ Zeile 208: / Zeile 213: @@
 It may be possible to trigger a RSTC PROCRST from GDB or OpenOCD in order to reset the core and stop at the first instruction. Another way to stop the CPU right after a CPU reset could be flag C_SNAPSTALL in the "Debug Halting Control and Status" register at address 0xE000EDF0, but I haven't had time to check it out yet, please [[Benutzer:rdiez|drop me a line]] if you do.
-A good workaround is to add an initial delay in the firmware before it actually starts playing with the hardware, as the wrong I/O or system clock configuration could render the JTAG interface unusable. This way, there is a window of opportunity for a JTAG debugger to take control after a hardware reset, and you can debug most of the start-up sequence properly. The downside is that the boot process always takes a little longer, even if you are not debugging it.
+A good workaround is to add an initial delay in the firmware before it actually starts playing with the hardware, as the wrong I/O or system clock configuration could render the JTAG interface unusable. This way, there is a window of opportunity for a JTAG debugger to take control after a hardware reset, and you can debug most of the start-up sequence properly. The downside is that the boot process always takes a little longer, even if you are not debugging it. The SAM3X starts at 4 MHz upon reset, so it is probably a good idea to ramp the clock up before the initial delay,
 == OpenOCD Reset Issues ==
@@ Zeile 247: / Zeile 253: @@
 It is best to create separate configuration files for the JTAG adapter and for the Arduino Due board, so the OpenOCD command-line arguments look like this:
-   openocd  -f your-jtag-adapter.cfg  -f target/at91sam3XXX.cfg  -f arduino-due.cfg
+   openocd  -f your-jtag-adapter.cfg  -f target/at91sam3ax_8x.cfg  -f arduino-due.cfg
-Configuration file ''target/at91sam3XXX.cfg'' comes with OpenOCD, so it should be able to find it automatically.
+Configuration file ''target/at91sam3ax_8x.cfg'' comes with OpenOCD version 0.8.0, so it should be able to find it automatically.
 == Connecting with a Bus Pirate v3.5 ==
@@ Zeile 255: / Zeile 262: @@
 === Caveats ===
-The [http://dangerousprototypes.com/docs/Bus_Pirate Bus Pirate] is very slow as a JTAG adapter, you should expect speeds under 1 KB/s when downloading new firmware to the Arduino Due.
+The [http://dangerousprototypes.com/docs/Bus_Pirate Bus Pirate] is very slow as a JTAG adapter, you should expect speeds under 1 KiB/s when downloading new firmware to the Arduino Due. If you manually patch OpenOCD version 0.8.0 so that setting "buspirate_speed fast" works, you can expect transfer rates of 8 KiB/s.
 Firmware version v6.1 (current as of feb 2013) has a bug that might make you physically disconnect the USB cable often.
@@ Zeile 266: / Zeile 273: @@
 I was surprised that just connecting the JTAG adapter powers the Bus Pirate, or at least the PWR LED turns on. Although it must be some partial current leakage, because connecting the USB cable makes the PWR LED shine brighter. The trouble is, that low current seems to be enough to keep the PIC running. Therefore, if you need to disconnect the Bus Pirate USB cable due to the bug described above, you will have to disconnect either the Arduino Due USB cable or the JTAG cable too.
-OpenOCD cannot slow down the Bus Pirate's JTAG clock, which always runs at a fixed rate. I am not sure whether this limitation lies with OpenOCD or with the Bus Pirate firmware. The fixed clock rate becomes an issue if the SAM3X switches to its internal 32 KHz oscillator, which happens if your SAM3X firmware enters some power-saving mode. Note also that, upon reset, the CPU starts at 4 MHz, instead of the normal 84 MHz. When the CPU starts running at a lower frequency, you need to slow down the JTAG clock accordingly, or the JTAG connection will not work any more. This implies that you cannot debug the firmware from the beginning directly after a CPU reset with the Bus Pirate. You should also avoid in your firmware switching the SAM3X clock when idle.
+The Bus Pirate firmware normally has the JTAG clock speed feature disabled, and the OpenOCD driver lacks the necessary support for it,
 === Configuration File ===
@@ Zeile 276: / Zeile 285: @@
   buspirate_port /dev/buspirate
-  # The 'fast' setting here does not work on my Ubuntu 12.04 PC, no idea if it would work elsewhere.
+  # In order for the 'fast' setting to work you will probably need to manually patch OpenOCD (as of version 0.8.0).
   buspirate_speed normal  # 'normal' or 'fast'.
@@ Zeile 553: / Zeile 562: @@
 = Memory Map =
-x0008 0000 - 0x0010 0000  512 Kbytes flash (2 consecutive banks)
+x0008 0000 - 0x000B FFFF   256 KiB flash bank 0
-x2000 0000 - 0x2000 FFFF   64 Kbytes sram0
+x000C 0000 - 0x000F FFFF   256 KiB flash bank 1
-x2007 0000 - 0x2007 FFFF   64 Kbytes mirrored sram0, so that it's consecutive with sram1
+                             Both banks above provide 512 KiB of contiguous flash memory
-x2008 0000 - 0x2008 7FFF   32 Kbytes sram1
+x2000 0000 - 0x2000 FFFF   64 KiB SRAM0
 x2010 0000 - 0x2010 107F   4224 bytes of NAND flash controller buffer

← Nächstältere Version		Version vom 24. Mai 2013, 17:13 Uhr
Zeile 1:		Zeile 1:
		+	{{BenutzerSeitenNichtVeraendernWarnung\|rdiez}}
		+
	= Why the Arduino Due =		= Why the Arduino Due =

@@ Zeile 1: / Zeile 1: @@
 = Why the Arduino Due =
@@ Zeile 62: / Zeile 60: @@
 * Power-up.
-* The user presses the RESET button. <br/> This asserts the MASTER-RESET signal, which also goes to the RESET pin next to the 3.3V and 5V reference voltage pins. <br/> Note that this does NOT reset the ATmega16U2 AVR microcontroller, so that the 'programming' USB connection is not affected.
+* The user presses the RESET button. <br/> This asserts the MASTER-RESET signal, which also goes to the RESET pin next to the 3.3V and 5V reference voltage pins. <br/> Note that this does NOT reset the ATmega16U2 AVR microcontroller, so that the 'Programming' USB connection is not affected.
-* The ATmega16U2 presses the RESET button (virtually) every time you connect to the 'programming' USB serial port. <br/> Under Linux, setting the port speed with command "stty -F /dev/ttyACM0 115200" is enough to trigger the reset. Note that the 1200 bps speed triggers an 'erase' procedure, see below.
+* The ATmega16U2 presses the RESET button (virtually) every time you connect to the 'Programming' USB serial port. <br/> Under Linux, setting the port speed with command "stty -F /dev/ttyACM0 115200" is enough to trigger the reset. Note that the 1200 bps speed triggers an 'erase' procedure, see below.
 * A JTAG debugger can assert the JTAG_RESET signal, which is connected to MASTER-RESET too.
 * The firmware can request a reset with NVIC SYSRESETREQ, RSTC PROCRST and the like.
@@ Zeile 81: / Zeile 79: @@
 * The firmware may switch to the internal 32 KHz oscillator, or may keep changing the system clock in a tight loop. Depending on your JTAG probe, this might hinder the JTAG connection.
-The small ATmega16U2 AVR microcontroller on the Arduino Due also presses the ERASE button (virtually) when you configure the serial interface over the 'programming' USB port to 1200 bps, see below for more information.
+The small ATmega16U2 AVR microcontroller on the Arduino Due also presses the ERASE button (virtually) when you configure the serial interface over the 'Programming' USB port to 1200 bps, see below for more information.
 Note that the user firmware can reconfigure the ERASE / PC0 pin as a general-purpose I/O. I did not want to risk my board, so I am not sure if you could rescue it afterwards by say holding down the RESET and ERASE buttons at the same time. Therefore, you should generally avoid reconfiguring PC0 in order to prevent confusion (at least). If worse comes to worst, you may find some pointers in section "Entering Programming Mode" on the AT91SAM3X8E datasheet.
@@ Zeile 95: / Zeile 93: @@
 The SAM3X's first UART interface (RX is PA8, TX is PA9) is connected to the ATmega16U2 AVR microcontroller, which acts as a USB-to-serial converter. The corresponding USB port is labelled as "PROGRAMMING" on the board's backside. The serial port connection parameters do matter, always use 115200 8N1 when connecting to SAM-BA. If you set the serial port speed to 1200 bps, the ATmega16U2 will trigger an ERASE procedure on the SAM3X. Under Linux, you can achieve that with command "stty -F /dev/ttyACM0 1200". Note that connecting at 1200 bps with 'picocom' does not seem to trigger the ERASE, but conneting with 'minicom' does (?).
-The SAM3X's USB port is labelled as "NATIVE". The serial port connection parameters do not actually matter for this port, as transfers are always performed at the maximum USB speed available. However, if your firmware uses the standard Arduino libraries, configuring the 'native' serial port to a speed of 1200 bps will trigger an ERASE procedure. You cannot rely on this method in real life, for it will no longer work if your firmware crashes or freezes.
+The SAM3X's USB port is labelled as "NATIVE". The serial port connection parameters do not actually matter for this port, as transfers are always performed at the maximum USB speed available. However, if your firmware uses the standard Arduino libraries, configuring the 'Native' serial port to a speed of 1200 bps will trigger an ERASE procedure. You cannot rely on this method in real life, for it will no longer work if your firmware crashes or freezes.
-The above means that you can talk to the SAM-BA bootloader on any of the 2 USB ports on the Arduino Due. Having 2 such ports does not actually make a lot of sense, see section "Inadequate as a Learning and Hacking Platform" above for more information. The 'programming' USB port is more convenient if your firmware uses it as a logging console, because its associated serial port does not close when you manually reset the SAM3X CPU with the RESET button. Keep in mind that just connecting to that serial port will trigger an initial reset. The 'native' USB port is faster, but, unless your firmware waits for a USB connection on start-up (for example, with "while (!SerialUSB);"), you will lose the first log messages, because the serial port will close on reset and you will have to reconnect after the firmware is already running.
+The above means that you can talk to the SAM-BA bootloader on any of the 2 USB ports on the Arduino Due. Having 2 such ports does not actually make a lot of sense, see section "Inadequate as a Learning and Hacking Platform" above for more information. The 'Programming' USB port is more convenient if your firmware uses it as a logging console, because its associated serial port does not close when you manually reset the SAM3X CPU with the RESET button. Keep in mind that just connecting to that serial port will trigger an initial reset. The 'Native' USB port is faster, but, unless your firmware waits for a USB connection on start-up (for example, with "while (!SerialUSB);"), you will lose the first log messages, because the serial port will close on reset and you will have to reconnect after the firmware is already running.
 === The SAM-BA Protocol ===
@@ Zeile 139: / Zeile 137: @@
 This is what happens when you click on the "Upload" button in the Arduino environment:
-# The 'programming' USB port gets opened with a speed of 1200 bps, which makes the ATmega16U2 trigger an 'erase' procedure on the SAM3X. The SAM3X boots then into SAM-BA and waits.
+# The 'Programming' USB port gets opened with a speed of 1200 bps, which makes the ATmega16U2 trigger an 'erase' procedure on the SAM3X. The SAM3X boots then into SAM-BA and waits.
 # The 'bossac' tool connects to SAM-BA over the ATmega16U2 with a speed of 115200 bps and performs the following steps:
 ## Erase the entire flash (unnecessary after the 'erase' procedure above, but it's very quick).
@@ Zeile 147: / Zeile 145: @@
 ## Reset the SAM3X. The new firmware should start now.
-With version 1.5.2 of the Arduino environment, you can only download the firmware over the 'programming' USB interface. If you try to use the 'native' USB port, you get a "No device found on ttyACM0" error message. However, you can then copy the 'bossac' command line from the build output window, remove the '-U false' argument, and run it on a command console, and then it works. It's also much faster than the 'programming' USB port.
+With version 1.5.2 of the Arduino environment, you can only download the firmware over the 'Programming' USB interface. If you try to use the 'Native' USB port, you get a "No device found on ttyACM0" error message. However, you can then copy the 'bossac' command line from the build output window, remove the '-U false' argument, and run it on a command console, and then it works. It's also much faster than the 'Programming' USB port.
 == Downloading over JTAG ==
@@ Zeile 160: / Zeile 158: @@
 # You can set the GPNVM bits with command "at91sam3 gpnvm" in OpenOCD. <br/> Run the 'bossac' tool with the '-d' argument in order to see the memory write sequence needed to set that bit from other environments.
-# If you are connected with the 'programming' USB interface, or you are connected with the 'native' USB interface but your are using the Arduino libraries and the firmware works, or SAM-BA is already running:
+# If you are connected with the 'Programming' USB interface, or you are connected with the 'Native' USB interface but your are using the Arduino libraries and the firmware works, or SAM-BA is already running:
 ## You can download your firmware with bossac, if you have generated the corresponding .bin file. Just append "--boot=1" to bossac the command line.
 ## You can download some example sketch with the Arduino environment. You will have to download your firmware over JTAG again.
@@ Zeile 183: / Zeile 181: @@
    Leading bit:  1  # Always set to 1 according to the IEEE standard 1149.1
-Note that, if you connect the JTAG_RST signal and you JTAG probe holds it deasserted most of the time, the ATmega16U2 AVR microcontroller may no longer be able to trigger a reset when you connect to the 'programming' USB serial port.
+Note that, if you connect the JTAG_RST signal and you JTAG probe holds it deasserted most of the time, the ATmega16U2 AVR microcontroller may no longer be able to trigger a reset when you connect to the 'Programming' USB serial port.
 If you abruptly disconnect the JTAG cable, you may leave breakpoints behind that, when triggered, will forever freeze the CPU. The JTAG logic on the CPUs does not normally detect the loss of the JTAG debugger, so always disconnect gracefully or reset the device after debugging.
@@ Zeile 265: / Zeile 263: @@
 I was surprised that just connecting the JTAG adapter powers the Bus Pirate, or at least the PWR LED turns on. Although it must be some partial current leakage, because connecting the USB cable makes the PWR LED shine brighter. The trouble is, that low current seems to be enough to keep the PIC running. Therefore, if you need to disconnect the Bus Pirate USB cable due to the bug described above, you will have to disconnect either the Arduino Due USB cable or the JTAG cable too.
-OpenOCD cannot slow down the Bus Pirate's JTAG clock, which always runs at a fixed rate. I am not sure whether this limitation lies with OpenOCD or with the Bus Pirate firmware. The fixed clock rate becomes an issue if the SAM3X switches to its internal 32 KHz oscillator, which happens during start-up (after a CPU reset), or if your SAM3X firmware enters some power-saving mode. When the CPU starts running at 32 KHz you need to slow down the JTAG clock accordingly, or the JTAG connection will not work any more. This implies that you cannot debug the firmware initialisation code with the Bus Pirate, and the firmware should avoid switching the SAM3X clock when idle.
+OpenOCD cannot slow down the Bus Pirate's JTAG clock, which always runs at a fixed rate. I am not sure whether this limitation lies with OpenOCD or with the Bus Pirate firmware. The fixed clock rate becomes an issue if the SAM3X switches to its internal 32 KHz oscillator, which happens if your SAM3X firmware enters some power-saving mode. Note also that, upon reset, the CPU starts at 4 MHz, instead of the normal 84 MHz. When the CPU starts running at a lower frequency, you need to slow down the JTAG clock accordingly, or the JTAG connection will not work any more. This implies that you cannot debug the firmware from the beginning directly after a CPU reset with the Bus Pirate. You should also avoid in your firmware switching the SAM3X clock when idle.
 === Configuration File ===
@@ Zeile 297: / Zeile 295: @@
 = USB Information =
-  USB Vendor  ID: 0x2341
+The IDs for the 'Programming' USB interface are:
-  USB Product ID: 0x003d ('programming' USB interface)
-x003e ('native' USB interface)
+  USB Vendor  ID: 0x2341 (Arduino)
 == lsusb -v Information for the 'Programming' USB Interface ==