How to connect multiple devices on avr(atmega16/32) using UART? - avr

atmega 32 has only one (TX/RX) .In case of connecting many devices working with UART what should I do?....Arduino has something called software serial
Is it available in atmega 32 or how to establish it?

One may also use a multiplexer if the peripheral devices do not need to operate at the same time. This is a bit trickier to use due to baud rate changes and such but I have used this approach in one of my projects where I had a serial printer and some other devices which interfaced with the MCU via UART. The drivers for the said devices included calls to switch to the correct output on the multiplexer before communicating with the device.

Related

applying stimulus to FPGA using PC

Is there any way I can apply stimulus signals on my FPGA board from my PC itself, and view the output of hardware in any simulation software? I am working on Spartan 3A development board provided by numato labs (elbert V2)
https://numato.com/product/elbert-v2-spartan-3a-fpga-development-board/
It is a relatively small board with few peripherals, so the number of LEDs for output and push-buttons for input is quite less.
I am a newbie to FPGAs but have sound knowledge on verilog. Please help me out with this
Thanks
The board does not have an physical interface intended for use as wired connection/communications (no ethernet, no usb, no uart, etc) to a PC.
These are the easiest ways I can think of for an 'elbert V2' board to communicate with a PC:
The board has a micro SD connector to access files on the micro SD interface. Those files could be accessed by a Verilog simulation.
A USB to UART adapter could be used with the boards GPIO interface.
Here is an example:
https://www.amazon.com/3-3V-UART-Serial-Cable-TTL-232R-3V3/dp/B078GMQPLT
The cable provides 3.3V TTL and the board has 3.3V gpio ports so that is encouraging. Probably just need to connect 3 wires tx/rx/ground.
You would need to design or find UART RTL IP for the FPGA.
Designing the UART would be a good intermediate level Verilog project.
Use procom or similar software on the PC to communicate with the USB/UART com port on the PC and a file. Verilog simulations can access the data in the file.

What's the difference between "COM", "USB", "Serial Port"? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I am confused about the these 3 concepts.
My understanding is, Serial Port usually means RS-232 compatible port (RS = Recommended Standard). USB stands for Universal Serial Bus. So its name contains serial port, does it support RS-232? What does the Universal mean?
And what does COM port mean?
ADD 1
Some understanding from Hans' answer:
To reduce effort, device manufacturers usually make their device can behave like a serial port device as well. This relies on the the fact that many OS and language libraries have already included serial port communication support. Though such support is no comparable to a real matching device driver.
ADD 2
A good reference doc about Serial Port HOW-TO.
And btw, the Linux Document Project is really useful.
Serial port is a type of device that uses an UART chip, a Universal Asynchronous Receiver Transmitter. One of the two basic ways to interface a computer in the olden days, parallel ports were the other way. Serial is simple to hook up, it doesn't need a lot of wires. Parallel was useful if you wanted to go fast, typ 8 times faster than serial, but cables and connectors were expensive. Parallel I/O has completely disappeared from computer designs, caught up by tremendous advances in bus transceivers, the kind of chip that can transmit an electrical signal down a wire.
COM comes from MS-Dos, it is a device name. Short for "COMmunication port". Computers in the 1980's usually had two serial ports, labeled COM1 and COM2 on the back of the machine. This name was carried forward into Windows, most any driver that simulates a serial port will create a device with "COM" in its name. LPT was the device name for parallel ports, short for "Line PrinTer".
RS-232 was an electrical signaling standard for serial ports. It is the simplest one with very low demands on the device, supporting just a point-to-point connection. RS-422 and RS-485 were not uncommon, using a twisted pair for each signal, providing much higher noise immunity and allowing multiple devices connected to each other.
USB means Universal Serial Bus. Empowered by the ability to integrate a micro-processor into devices that's a few millimeters in size and costs a few dimes. It replaced legacy devices in the latter 1990s. It is Universal because it can support many different kinds of devices, from coffee-pot warmers to disk drives to wifi adapters to audio playback. It is Serial, it only requires 4 wires. And it is a Bus, you can plug a USB device into an arbitrary port. It competed with FireWire, a very similar approach and championed by Apple, but won by a land-slide.
The only reason that serial ports are still relevant in on Windows these days is because a USB device requires a custom device driver. Device manufacturers do not like writing and supporting drivers, they often take a shortcut in their driver that makes it emulate a legacy serial port device. So programmers can use the legacy support for serial ports built into the operating system and about any language runtime library. Rather imperfect support btw, these emulators never support plug-and-play well. Discovering the specific serial port to open is very difficult. And these drivers often misbehave in impossible to diagnose ways when you jerk a USB device while your program is using it.
USB stand for Universal Serial Bus not Port. The term "serial port" simply means that the data is transferred one bit at a time over a single signal path - in that sense even Ethernet is serial in nature. The word serial in both terms implies no relationship other than the width of the data path.
You are right in that the term serial-port in the context of a PC normally means an RS-232 port, but there are other serial port standards such as RS-422 and RS-485 often used in industrial applications. What these have in common is that they are implemented using a UART (Universal Asynchronous Receiver/Transmitter).
The term Universal in USB merely reflects the fact that it is not a specific device interface such as the dedicated mouse or keyboard ports found on older hardware. Similarly a UART based serial port is not device specific, reflected by the U in UART.
USB differs significantly from RS-232 in a number of ways; it is a master/slave (or host/device in USB terminology), rather than peer-to-peer, the USB device cannot initiate communication, it must be polled by the host. USB includes a low-voltage power supply to allow devices with moderate power requirements to be powered by the bus - that is also why USB ports can be used for charging battery powered devices. USB is significantly more complex that RS-232 which defines only the physical (hardware) layer whereas USB requires a complete software protocol stack.
The term COM is just a device name prefix used in Windows (and previously MS-DOS) for a serial (UART) port. Short for "communications", you can for example open a COM port as a stream I/O device with say FILE* port = fopen( "COM1", "wr" ) ;.

Communications between Visual C++ and Arduino:

I have a Arduino app that needs to talk to my PC across the USB (Serial) connection. I have this bit of code that I lifted from the Arduino Playground at
http://arduino.cc/playground/Interfacing/CPPWindows#VisualStudio2008
this->serialPort1->PortName = "COM5"; // Replace with your COM port!
this->serialPort1->Open();
this->serialPort1->Write( "7" ); // In the future, you'll expand on this
// to write your custom data to the board
this->serialPort1->Close();
My question is how does one determine what COM port the Arduino USB cable is attached to?
There are several ways you can approach this.
The most obvious is that you simply make your application configurable and tell it which serial port to use. The port name should never change, unless you have other processes on your machine allocating virtual COM ports such as Bluetooth drivers.
A second option is that you can do what the Arduino app does and scan the serial ports on the system looking for the hardware. Since you are using the CLR, System.IO.Ports.SerialPort.GetPortNames() will give you a list of all the serial ports on the system. (You can also get this from the registry.) Then you can enumerate through them and check the status of the pins to see which serial ports have devices attached. You should probably include in your sketch a way to query the Arduino so that you can send it a command and have it give a fixed response. This would allow you to discern your application from other serial devices such as modems.
There is a third option which would involve figuring out where the FTDI driver stores its configuration information in the system/registry and going from there. This is a bit more involved, so I can't give any information on if this approach is even viable.

How to read from USB without any driver?

We are creating small system which has GPS receiver and PC. We want to test my GPS receiver, We do not want to go for a driver on the first go. First I would like to test my circuit works or nor. GPS IC has been set to output NMEA sentence. We want a program which just reads data from USB port and print it on the screen.
Can we write something like this easily ? Do we have any open source tool which will achieve this purpose ?
Platform : Windows 7
All devices need a driver, so I'm going to interpret your question as "how can I read NMEA data from my GPS using only drivers provided by the OS, so I don't have to write my own?"
If the GPS chip has a USB interface, then you should have gotten a driver with it. But most GPS chips have a UART interface which in your case sounds like it is connected to a separate USB-UART conversion chip. That conversion chip most likely came with a driver as well, but if not, you could jumper the reset pin of the converter chip, disabling it, and then attach a TTL/RS-232 level converter (available off-the-shelf) to the UART traces and then to your computer's serial port.
Unless you suspect that the driver for the USB-UART converter is causing problems, I wouldn't bother.
Anything connected via USB is a device. Devices require a device driver, period.
You might be able to get away with an existing driver built into Windows. This is how USB memory keys work for example - they present a generic device that looks like a removable disk, and Windows already includes the drivers for generic removable disks.
You would need to check the documentation for your device to see if it can emulate a device which already has drivers. Otherwise you must install the company's drivers, or you're out of luck.
Have a look at libusb. You should be able to read the data with that and a little code. (Yes, it's a driver. I take the question to mean "without writing a driver".)
You need a device driver for your device. Unless Windows already have a class driver for the device.
For USB devices on Windows 7 you can write a user-mode driver, see UMDF.

USB Debugging

I'm looking for a very specific USB device for debugging systems that may use USB but not with a regular computer (proprietary hardware). I want a device that has a USB host controller and two USB device connections. The device to be debugged is connected to the USB host controller and one of the device connections is connected to another device with it's own host controller on it. The the other device connection is connected to a pc. The point being that all USB data travelling through the device (from the device connected to the host controller to the device connected to the first device connection) is reported to the pc.
I'll happily write software to do the logging (in fact I want to) but I can't seem to find a board like this anywhere. Can anyone help?
I have an Ellisys USB analyser, which isn't exactly what you describe internally, but does sit between a peripheral and a host and use a separate PC to collect the data.
(i.e. it has two 'B' and one 'A' connectors on it.)
Excellent product, and very helpful company.
Sniffing the USB shouldn't be too hard if you have the right hardware. And that is the tricky question. I haven't seen anything that describes the USB breakout box that you want. However I can say that this is in the realm of the following two magazines:
Nuts and Volts
Circuit Cellar
If they don't have a USB breakout box project in their archives, then at least they will have advertisements for small cheap single board computers that would have multiple USB ports that you can use for buffering the signals and reporting it back to your PC.
Alternatively is it possible to just wire your PC up to the middle of your two devices and write a custom drive that echos data back and forth while sniffing off a stream for you?
Sorry for the long delay in my reply -- I checked out one of our USB developer's toolchain, and he uses a Beagle USB Sniffer. He seems happy with it.
You're looking for a USB device with two upstream outputs. I think according to the USB spec, this is not possible. You will have two USB hosts trying to send messages and control the USB devices at the same time.
What if you were to look for a device which allowed you to view the data going through a hub via something other than a usb output?
If you're building something custom, take a look at this USB chip site. The chips are programmable via a windows application. Once you define how you want it to operate, it's saved on an EPROM on the dev board ($30-$50).
Sorry if this isn't helpful!

Resources