RS232 and serial mean different things (Score 1)

Most of what's being called serial here is asynchronous serial, meaning there's no external clock line. Each end of the connection has a clock that determines the baud rate, and so they must match in frequency within a couple of percent. There's a TX transmit line and an RX receive line and a ground wire in the minimal configuration. In a pc or an MCU there's a chip or an emulated version of same called a UART Universal Asynchronous Receiver Transmitter that takes care of buffering the serial bits as they come in (or go out of) the data wires One Bit At A Time. Many microcontrollers have built-in UART's. It used to be that the signal from a UART was universally converted to RS232 voltage levels. The spec says -12 volts is a 1 and +12volts is a 0. This is a really old standard that was invented to connect dumb terminals to mainframes through a modem. Several other wires are in the spec have to do with flow control and interacting with the modem. To get from 5 volt (or whatever) logic levels, a special line driver is used. A popular one is the MAX232 series of chips. These days the other lines in the RS232 cable are rarely used for their original purpose. The Arduino uses a flow control line to start the flash burner through a bootloader for instance. Async serial is very much still around because there are a large number of periperal chips and board-level modules that use a UART to communicate with an MCU or each other (sparkfun.com). In these applications, the voltage is at logic level. It is not shifted to RS232 levels, although you could do this if you needed to.
The serial port on the original PC is a DB9 connector. The UART's interface to the CPU is interrupt driven, so you can do pretty good real-time stuff. Since the async serial port us pretty much gone on PC's, a lot of devices like most cell phone cables use an emulated UART port running over USB. There are a couple of companies that make USB to 5 or 3.3 volt UART converter chips that implement the USB protocol. Rather than having to put the USB protocol it in the target processor, you buy the functionality. Of course there are MCUs that know the USB stuff, but they're a bit uncommon. Also there's the whole licensing problem if you roll your own USB device. So as strange as it is, designing with an 8-bt MCU, you'll use a chip with a lot more horsepower than the target to handle the USB interface. This is a very, very common thing to do. The other half of the problem is the host device drivers. FTDI make chips with no-cost drivers that are routinely used alongside a lot of 8-bit MCUs. There are drivers in the linux kernel for a handful of converter chips, and FTDI's are the best known.
The PITA for embedded designers is that the serial port emulated by the FTDI chip has buffering constraints and timing limitations (16ms latency) that basically ruin the real-time capability of the port. This really sucks. The alternative is to write your own drivers for Win, Mac, and Linux, and program your mcu to use one of the faster modes in the USB protocol than the one offered by the USB device class that includes async serial. For most people this doesn't matter. The host app on the PC uses its driver package that comes with, and you never have to know that your cell phone is using a 50 year old data link to talk to the pc.