2
\$\begingroup\$

With a serial port or parallel port in pc programming avr microcontroller is very easy and cheap. Problem is, no modern computer come with serial or parallel port. So, usb to serial converter should be the solution but unfortunately not.

There must be a difference between the actual serial port and converted serial port. What is it?

Another related question would be, how USBasp communicate almost directly with pc? I thought most or all of the microcontroller of ATmega series microcontrollers are without usb support.

I have checked this link- AVR programmer with serial to USB converter

I know there are several question like this but being new to embedded programming I need an easy explanation to get the concept. Thanks.

Edit: I want to use a circuit as below with the converted serial (possibly, RS232) interface.This circuit is designed for actual serial port.With a converted serial port, I might be able to reduce some complexity of the circuit. Schematic of the serial programmer

The detail can be found at Simple Serial Programmer for AVR

\$\endgroup\$
  • 1
    \$\begingroup\$ Many can, though less than ideally. See for example arduino.stackexchange.com/questions/3361/… \$\endgroup\$ – Chris Stratton Jul 29 '14 at 18:09
  • 4
    \$\begingroup\$ The USBasp "approximately" implements the lowest speed USB interface standard with a network which "sort of" couples the signals to and from GPIO pins and excessively clever software that reads or writes the pin states at approximately the right time. \$\endgroup\$ – Chris Stratton Jul 29 '14 at 18:36
2
\$\begingroup\$

The serial programmer you are using is using serial port to connect to computer, but not the standard RS232 protocol! Take a closer look at the schematic:

  • pin 4 (DTR) is assigned to MOSI. On a true motherboard serial port this pin can be toggled high and low, thus emulating a bitbang mode
  • pin 6 (DSR) and 7 (RTS) are asigned to SCK. As DTR, RTS can be set either high or low, thus along with DTR allowing software implementation of custom synchronous serial protocols
  • pin 8 (CTS) is an input pin assigned to MOSI. Its value is read on SCK toggle.

DTR and RTS are the only pins of the serial port that can be bitbanged. But there is the need for a reset signal. The designer of that adapter uses a trick. He sends a 0x00 character with no stop bits over standard RS232 TX, thus creating a short reset pulse (which for some MCUs need to be inverted).

The actual data on a standard serial RS232 communication is actually sent only via Rx/Tx lines. All the others are accessory lines used by devices to signal different states of operation or to signal data availability or transfer termination.

This is the problem with USB-serial adapters. Most of them can only use Rx/Tx lines and of course, only serial RS232 (asynchronous) protocol, which is by no means compatible with AVR programming protocol (SPI, synchronous). So the only way to communicate via serial port by SPI is to use alternate lines and emulate the protocol in software.

You can see on this forum that in some cases it works with USB-serial adapters, but in most situations it doesn't.

I thought most or all of the microcontroller of ATmega series microcontrollers are without usb support.

What do you say about: ATmega 8U2, 16U2, 16U4, 32U2, AT90USB1286, AT90USB1287, AT90USB162, AT90USB646, AT90USB647, AT90USB82. Full list from here.

But USBasp is not using one of those MCUs! Looking at its schematic we can see that it uses a pull-up resistor on the D- line, which means it signals the PC that it is a low speed device (1.5 Mb/s). And it software emulates USB bus over a general use I/O port (can be seen in AVR firmware source code - file usbconfig.h):

#define USB_CFG_IOPORTNAME      B
/* This is the port where the USB bus is connected. When you configure it to
 * "B", the registers PORTB, PINB and DDRB will be used.
 */
#define USB_CFG_DMINUS_BIT      0
/* This is the bit number in USB_CFG_IOPORT where the USB D- line is connected.
 * This may be any bit in the port.
 */
#define USB_CFG_DPLUS_BIT       1
/* This is the bit number in USB_CFG_IOPORT where the USB D+ line is connected.
 * This may be any bit in the port. Please note that D+ must also be connected
 * to interrupt pin INT0!
 */
#define USB_CFG_CLOCK_KHZ 12000
/* Clock rate of the AVR in MHz. Legal values are 12000, 16000 or 16500.
 * The 16.5 MHz version of the code requires no crystal, it tolerates +/- 1%
 * deviation from the nominal frequency. All other rates require a precision
 * of 2000 ppm and thus a crystal!
 * Default if not specified: 12 MHz
 */
| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Hey man you can delete your comment since you updated the answer and it is proper. I'll delete mine shortly since the comments on this are now irrelevent \$\endgroup\$ – Funkyguy Jul 31 '14 at 17:13
  • \$\begingroup\$ @Cornelius I'm just curious; I'm using a Teensy with the "Benito" sketch and it created a serial connection via USB and then connects it's UART port, which is simply hardware serial on TTL level. So I'm not using RS232 either (the teensy doesn't have it onboard). So I just though I should be able to use a serial USB cable instead and stumbled across this thread. Could you please clarify? Thanks! \$\endgroup\$ – Julian F. Weinert May 13 '16 at 20:43
  • \$\begingroup\$ @JulianF.Weinert you can use USB-to-serial converters for standard RS232 UART protocol. It shouldn't matter if the serial device is using a hardware or software emulated port as long as it supports the standard protocol. \$\endgroup\$ – Cornelius May 14 '16 at 9:33
  • \$\begingroup\$ @Cornelius sure. Maybe I was a bit unclear here. The implementation is actually only shifting each received bit out of the serial port. I don't see any evidence of RS232. What exactly would tell me, if I'm doing "real RS232" or arbitrary serial? \$\endgroup\$ – Julian F. Weinert May 14 '16 at 9:38
2
\$\begingroup\$

A few thoughts off the top of my head based on bitter experience:

  • Only use FTDI USB-Serial converters, they are by far and away the most reliable & configurable & best-supported. Others can work fine, but it's a lottery and life's too short for errant hardware.

  • Check that the "serial" output from the chip is actually what you really want; Converters can output full RS232, TTL (0-5v) level serial data, or 0-3v3 serial data, and sometimes RS485/RS422 depending on the converter.

  • As mentioned, there are other settings like start/stop bits, parity, buffering, bit-bang modes, etc. etc. which can cause problems.

Buffering in the USB-serial chip or driver especially can cause issues when the programming software tries to execute specific time-delays when programming. FTDI drivers allow you to change all of these things.

| improve this answer | |
\$\endgroup\$
0
\$\begingroup\$

To be able to program such devices the SERIAL port might have to be configured to operate in a bitbang mode. Most USB <-> Serial converters do not provide such capability.

Depending on the type of USB <-> SERIAL converter you may be able to "configure" it to facilitate such a mode.

www.ftdichip.com/Documents/AppNotes/AN232B-01_BitBang.pdf

The FT232BM and FT245BM chips can be set up in a special mode where the normal function of the chips are replaced. This mode changes the 8 data lines on the FT245BM or the RS232 data and control lines of the FT232BM to an 8 bit bi-directional bus. The purpose of this mode was intended to be used to program FPGA devices. It may also be used to talk to serial EEPPROMs or load a data latch.

| improve this answer | |
\$\endgroup\$
  • 1
    \$\begingroup\$ That doesn't make any sense. Most "real" serial ports don't have a "bitbang mode". Are you thinking of parallel ports? \$\endgroup\$ – Dave Tweed Jul 29 '14 at 11:33
  • 1
    \$\begingroup\$ @DaveTweed - most real serial ports do allow twiddling the control lines with lower latency (and potentially better coordination with the state of the data lines) than USB-mediated ones do. Many USB serial devices probably can do it, just more slowly. But some offer special bitbang/GPIO modes (they are, after all, typically microcontrollers with special firmware) \$\endgroup\$ – Chris Stratton Jul 29 '14 at 18:07
  • 1
    \$\begingroup\$ @Naib: You misunderstood the question. The OP is asking why programming works with "real" serial ports, but NOT with USB-to-serial converters. I'm well aware that some USB-to-serial converters support a high-speed precision "bit-bang" mode of operation. \$\endgroup\$ – Dave Tweed Jul 29 '14 at 20:51
  • 1
    \$\begingroup\$ @DaveTweed - actually it looks like one may be able to command a 16450/16550 SOUT pin by sending no UART data but using the BREAK bit for a SPACE and the loopback mode bit for a MARK. That along with two write status lines and one read status line would do it. At any rate, it's known that people have done ATmega ISP with "real" serial ports. And it's possible by other means with some USB-serial converters. What remains unclear is if it is possible slowly while manipulating them using serial APIs rather than special modes. \$\endgroup\$ – Chris Stratton Jul 29 '14 at 21:27
  • 1
    \$\begingroup\$ @DaveTweed "real" serial ports can get close: vivara.net/blog/?p=24 \$\endgroup\$ – markrages Jul 29 '14 at 21:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.