I have a number of Windows 2000 systems that we are trying to use to program the new Arduino Uno and Mega devices. These boards now come with a USB connection, an upgrade from the prior FTDI. I'm not able to download the Arduino code into the board from a Windows 2000 system
The supplied drivers are *.inf files that modify the standard USB driver that comes with Windows (in this case Windows 2000).
I go through the process of setting the port, setting the device and doing the download. The download fails, and the apparent error is that the PC can not communicate with the board. I've checked the port, adjusted the baud rates, etc. I've even moved the port number from a high port number (ie COM12) to a lower port (COM2) without any success. I do see activity on the rec/xmt lights on the Arduino board, so some type of data is being sent and received.
I'm looking for:
Someone who has been able to download files from Windows 2000 to the Arduino
or
A way to shim inside the USB driver to be able to watch the traffic going up and down to the board so I can continue to debug this.
or
Some general tips for things to look at in the .inf file that need to be set/not set to make it work on Windows 2000.
I know the boards work I've used them on a different set of Windows XP systems. So I know to some extent the install is good and that most of what I have works.
Full dumps can be found on the Arduino forum, http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1291090110/.
This is the information produced by the AVRDude program while it's trying to download the code.
this could be a long shot, but I jsut recentlz had problems uploading too. Fist of all, how long is the USB cabele you are uploading from? Mine in one case was too long and th arduino woul lose sync. Secondly, and this might just be a silly oversight (like i did) do you have things wired in the digital pin 0 and 1? These are used for the communication, and if there is anything else plugged in to them the upload will also fail.
As I said, long shot but those were two errors I had.
Related
I am controlling a device over serial connection using LabVIEW (version 7.0). It is connected using USB, and is installed as a virtual serial port on the computer (running Windows XP). Every now and then my device crashes when my program sends a command, and it is unable to accept any more input (the device itself also stops working) until it has timed out.
I've looked at the serial port traffic using Portmon. Whenever the device crashes the serial driver sends the command I send using my program four times instead of just once, with an IOCTL_SERIAL_GET_COMMSTATUS command in between. I cannot see what this last command returns, but I assume something happens in the communication earlier on. I'm thinking my configuration of the port is not entirely right, but I have no idea how or why. I open and close the connection to my device every time I want to write something to it.
For completeness' sake: it has a baud rate of 9600, 8 bits, no parity, 1 stop bit, and no flow control. I'm aware that the correct settings of these parameters depend on the device, but the manufacturer has not supplied any recommended settings.
The driver is a DLL of some sort? If so, this is the most likely source of your problem, and you likely will need to contact the author of the driver. LabVIEW does have crashing bugs, but by far the most common source of crashes in simple communications apps is a buggy third-party DLL.
In other words, I doubt this is a LabVIEW problem at all and that you would have the same difficulty if you wrote a C program to talk to this driver. I only know what you've posted here about your system, but after many years of chasing down such issues, I would start with the device manufacturer/driver author.
If you have evidence to the contrary, please share.
First of all, I won't go into details, cause there are a lot of them, and I dont want to write (a too long) essay. There is TL;DR section at the end, because I have a specific question, but maybe some additional info can help.
I have a device that is made of a GRU (glass room unit) and espressif (esp8266).
GRU and esp8266 communicate via serial, with GRU as master. GRU is programmed with an internal tool, and I can monitor everything on it, including the info it gets from esp8266.
There is a test/development device, that has espressif on top of the GRU, so I can easily take it off, reprogram/reconfigure it, and put it on.
Espressif is inside of a GRU, and downloading stuff to flash is a real pain. There is whole process including a OS switch (from Win7 to Linux and back). Console output on espressif cannot be done, or at least not in the time frame I have.
For esp8266 I use non-os SDK V2.0.0_16_08_10.
Espressif can be configured with downloading a configuration to flash, or via UDP (over a network if connected, over its AP if its not connected).
Algorithm for Wifi:
1. Try to connect to a network from configuration
2. If it succeeds, raise a flag for that
3. If it fails, enter dual (STATION+AP) mode and raise a flag for that
The reason espressif is not always in dual mode is that it affects multi-cast operations.
Configuration over network is done by a Java aplication I wrote.
Scenario 1
I've configured a wifi router, configured all (x19) of the devices (espressif in devices that is) to connect to its network. When I turned them on, they would connect one by one. The ones that didn't entered dual mode and could be configured via the app.
All well.
Scenario 2
I've wanted to test the system in real world, so I reconfigured them to connect to the our firms network. Additionally when I was already going thru the whole process I've downloaded latest firmare to flash.
I expected that they would connect or enter dual mode and create their own APs. But they did not.
I tested then the code and configuration on espressif whose console output I could monitor, and everything worked.
I tested then the code and configuration on the test device, and it worked again.
I've then redownloaded the code and configuration to one device, and it didn't work.
TL;DR
I have two devices, espressif on a GRU and espressif inside of a GRU. Both connected to one network. Esp on a GRU work for another, Esp inside of a GRU doesn't work for that other network.
They have identical code and configuration, so it shouldn't be a software issue.
Does having espressif inside of a device jams its signal enough that it can't go trough? Device is not big (5x5x2cm).
UPDATE 1:
While I was writing, the espressif inside of a GRU managed to connect to network. I then restarted it so I can check that it can do it again, and it can't connect again.
It took me about 10 minutes to write the whole question.
There are two things that seem to have caused the problem.
When I removed gpio_init(), network stuff became faster, much much faster. Everything on it, connecting to AP, creating AP etc...
I've changed my config and wifi code, so that it now stores the ap and station config to flash via API.
I only check if its internal config is the same as mine from flash. If it isn't, it saves it. Now, I only control the current opmode.
Few months ago, I bought cheap arduino nano from china. Instaled all the required drivers, and tried out my frirst program.
Now I tried to upload something new, and I get this error message:
avrdude: ser_open(): can't open device "\.\COM4": System can't find given file.
I also noticed, that Tools->Ports can not be clicked. The device does not even show up in device manager.
Any Ideas?
In my first program I did also set pin 0 and 1 (RX/TX) as outputs and used them to flash LEDs. I am aware, that this probably prevents new code from beeing uploded, but it should not prevent from the device from shoving up at all. The computer talking to the USB driver, not the microcontroller.
Go to Device Manager and find the Arduino COM Port
Go to the Advanced properties of the port
Set the port # to COM1
Then un-plug your USB and plug it back in.
I have a Microsoft Surface Book that I've dual booted Linux Mint on. I'm writing a program that needs to read in data from a serial port, but my serial ports don't seem to be working. The behavior is consistent across Mint and Windows (Testing done through Cygwin). It gets a bit of data the first 2-5 seconds that the device is plugged in (viewing the data through screen, same thing happens if I just use pyserial to print data incoming from serial port), then nothing.
What could be happening? I think I've isolated the problem to the serial ports - the Surface Book has 2 USB ports and the same thing happens on both of them, and I've tested the hardware that I'm plugging into it on 2 other computers (One Linux and one Mac OS), and it works fine on both of those.
Your MS Surface, seemingly, has a yellow triangle exclamation mark icon (over the adapter icon) without any driver to install/download. And properties in the device status box window say This device cannot start. (Code 10) or A device which does not exist was specified. Right?
If it's so you should wait for an update from MS. It's notorious problem.
I ended up getting the computer replaced on warranty for an unrelated issue months later, and what do you know, on the new computer the serial ports work fine. That indicates to me some sort of hardware problem, given that the issue persisted across OS's.
maybe this will help:
see Arduino examples for serial port communication - search google:
arduino serial c++
arduino serial c#
arduino serial c++ linux
the point is to open port properly you need to open a file, not a port. not with usual c - assembly write to port code.
another option you are using an unintentionally bought fake USB to serial cable with a Fake PL2303 chip
then you need to install the old version of the driver.
search in google:
Fake PL2303 + your os name:
install driver Fake PL2303 windows 10
another option is maybe it conserves energy and closes the port because it feels it is unused.
in windows> device manager,> properties of a device - usually USB root hub > power management - allow the computer to turn off this device to save power - uncheck it.
https://superuser.com/questions/408683/why-my-usb-mouse-gets-suspended-after-3-seconds-of-inactivity
https://blogs.msdn.microsoft.com/usbcoreblog/2013/11/08/help-after-installing-windows-8-1-my-usb-device-doesnt-charge-or-it-disconnects-and-reconnects-frequently/
also, you could look in windows events - to see what happens. usually, failures like this are registered in the events log.
an unlikely option is it consumes too much current, like a short circuit. and the device protection circuit shuts the chip off. also probably it does not have such circuit. one possibility is to try with an external powered hub.
the most probable of these is the power saving mechanism
I was experiencing the same problem - came across the solution on another site. The USB 3 ports on Surface Book aren't compatible with something or other to do with Com Port but running the device through a cheap USB hub solved my problem straight away and it was instantly recognised by the Arduino IDE
I am using 2 esp8266 wireless modules to establish bidirectional wireless communication between 2 arduino boards (one mega and one uno) without the use of any earth based technologies (i.e. radio frequencies, wifi which relies on earth sattelites, etc.). My solution was to use the esp8266 to establish a private area network with both esp's acting as a station and an access point (AT+CIPMODE=3). Unfortunately, this solution has proven to be more of a hassle than it was worth.
To start, I have the esp's each wired according to this diagram
When I first started out, the red LED was on and the blue LED was off. During this time, I was able to send AT commands, establish the server, and achieve the communication I required by entering commands directly to the serial monitor. After this, I started writing a library using the SoftwareSerial library to allow me to issue commands directly through the program to set up the esp as needed upon start up of my script. Before doing this, I changed the baudrate to make sure it was running at 9600, and entered the AT commands in the serial monitor to make sure everything was working properly and it still worked.
After I began writing the library, before uploading the code with a test of the library I noticed the blue LED was lit solid now. Noticing this, I reuploaded the barebones script (I haven't uploaded the library code to the arduino yet) and the esp was no longer receiving the AT commands.
Does this indicate an issue with the board which I can fix or does this mean the board is done?
With my deadlines approaching fast in about 3 weeks it is crucial I get this wireless communication working so if this is an issue with the board, I'm going to have to scrap the esp's and use a different way of communicating. So my second question is, if this is the case, what are other viable options for establishing this communication? I have used xbee's before and while that would be ideal, they fall out of the budget I have been alotted so I need to keep it under $50 for this. If bidirectional communication is not possible for that price I can live with one way because I just need to get this system working. Basically I just need to transmit a single byte of data.
I realize this response is a little belated, and I hope you got it sorted: I've started working with the ESP8266 myself in the last few weeks, and hence why I was looking around for tutorials on direct communication between 2 units, when I found your post.
From what I've been able to ascertain, the AT commands are a part of the 'firmware' which ships with some modules. The Arduino code however starts loading onto the chips at memory address 0x0000, which is the same address that the firmware update tools use.
In other words, I believe that with the Arduino-coded program running on there, you lose the AT command functionality.
If you find a firmware update tool for the ESP8266 (plenty online) you'll get back the AT commands.
I suppose though the real question is why would you want to? It seems that the AT commands are just a way to treat the ESP as a dumb WiFi antenna. With the Arduino code, you're actually treating it as a micro-controller in its own right.