Can i use a USB-to-RS232 Serial converter to connect to Arduino ?

i bought a cheap CH340G USB-to-TTL converter and am still having troubles getting it to work.

in my scouring for solutions, i stumbled across a thread about USB-to-Serial converter and someone mentioned using a MAX3222 to make a USB-to-RS232 converter.

then i remembered i actually have one of those !
(with drivers for Windows and all, and has worked for an old controller.)

is it possible to use this (USB-to-RS232 converter) by adding some kind of logic-level shifter setup, to use for uploading sketches to the Arduino ?

here's the post that made me think of doing the reverse of what was mentioned;
https://forum.arduino.cc/index.php?topic=57927.msg416497#msg416497

@ExpertGeezer

RS232 uses a different voltage than TTL.

You need USB to TTL

You need a RS-232 to to TTL level shifter, the MAX232 is commonly used. You can buy the required DB9 and a MAX232 on a board for a $1 from China. Only issue is they’re usually counterfeit parts although they reportedly work.

The CH340G is solid part, used tons of them without issue. What OS? Post a picture of the module you have, i probably have one I can test or comment on.

avr_fred:
You need a RS-232 to to TTL level shifter, the MAX232 is commonly used. You can buy the required DB9 and a MAX232 on a board for a $1 from China. Only issue is they’re usually counterfeit parts although they reportedly work.

hmm, more waiting for stuff from China - but if it is indeed possible, i will definitely give it a go - never mind the inefficient roundabout solution - would be "fun" just to see the converting of a converter !! :smiley:

avr_fred:
The CH340G is solid part, used tons of them without issue. What OS? Post a picture of the module you have, i probably have one I can test or comment on.

ooh, that would of course be much better, thanks !!

here's the pic; (EDIT : running Windows and IDE 1.0.5)

it looks quite alright - there's a button near the DTR pin which i'm not sure of its function, but when i press it, the LED by CTS goes off (when connected to the computer USB).
EDIT : incase the pic is not bright enough, there is a slide-switch below the 12 MHz crystal for switching 5V and 3.3 V levels - it's set at 5V now.

i have the drivers okay - Device Manager detects it and a loop-back test works fine.

but uploading a sketch (to a 328P... larryd will know :wink: ) gives the STK500 - not in sync error.

FWIW : i managed to get some support via the eBay seller but i cannot access the link they gave; http://www.mcu-memory.com/datasheet/stc/STC-ISP-V4.86/STC-ISP-V4.86-NOT-SETUP-CHINESE.EXE
connection error to the website - no DNS from my end. :frowning:
(i think there is a block happening somewhere - the email i received should have an (in-line) image but it doesn't appear :frowning: - i'm in a country that likes to block certain websites... vimeo for one, and even reddit... i've not bothered to get a VPN to get around the block... haven't really found the urgent need to ... yet.)

If loopback test works, it should work with an Arduino (assuming DTR works).

First question is why 1.0.5? I have no idea if it will work with non-Arduino drivers, maybe someone else knows. Current versions of the IDE going back to at least 1.5.8 will absolutely work with the CH340G.

Also: which version of Windows and which Arduino and how is it connected?

PS: Don’t waste time with the link, it is of no use with the Arduino environment. The STC-ISP is a downloader for STC processors, a Chinese based 8051 core part with a permanent, non-erasable bootloader. The mystery push button opens VCC which required by the STC parts to initialate the bootloader sequence.

avr_fred:
If loopback test works, it should work with an Arduino (assuming DTR works).

Also: which version of Windows and which Arduino and how is it connected?

on XP - very old laptop that cannot handle newer Windows.
and a "Breaduino" : https://www.arduino.cc/en/Main/Standalone
EDIT:
(with the 10K from RESET to 5V and also 0.1 uF in series to the DTR line - as per Nick Gammon's setup
that was a whole different saga !!

avr_fred:
First question is why 1.0.5? I have no idea if it will work with non-Arduino drivers, maybe someone else knows. Current versions of the IDE going back to at least 1.5.8 will absolutely work with the CH340G.

i have a pet peeve about upgrading to the latest software willy-nilly.
if the old one works fine for my purposes, i see no reason to upgrade which i have noticed goes through lots of teething problems going on the evidence of all the announcement threads on the forum - for 1.6.X and 1.8.0 onwards.

well, i did read this here;
https://forum.arduino.cc/index.php?topic=332638.0

Re: Problem to upload in UNO CH340
#5
Jun 28, 2015, 03:04 pm Last Edit: Jun 28, 2015, 03:06 pm by Peter_n
The newest Arduino IDE should work. Starting with version 1.5.x, the serial communication to upload a sketch has improved a lot.

and i did attempt to install 1.6.X on another laptop (with Vista) but that opened up a whole new can of worms that entailed uninstalling Java and going back and forth using the installation.exe and just the zip package and all sorts of hassles of "Arduino 15" folder name related issues that i just gave up - after attempting to install 1.8.5 even !! (i think that laptop is sub-optimal, Celeron chip and i'm not sure if it'll handle Windows 7)

the Arduino software download page doesn't show 1.5.X links - unless i am mistaken.

avr_fred:
PS: Don’t waste time with the link, it is of no use with the Arduino environment. The STC-ISP is a downloader for STC processors, a Chinese based 8051 core part with a permanent, non-erasable bootloader. The mystery push button opens VCC which required by the STC parts to initialate the bootloader sequence.

okay - good to know.
yeah, i guess that makes sense with the "CTS" LED going off then. ("opens VCC" means, pulling the CTS to GND i suppose ?)

so anyway - unless you can convince me that 1.0.5 is really the issue for this CH340G converter, i'd rather keep it on this trusty laptop which has it's peculiarities, but at least it's "the devil i know".

Tested three different IDE versions under an XP VM environment.

1.0.6
1.56.5-r2
1.6.9

with an identical to yours CH340G board and a ProMini with the Uno bootloader installed. This was loaded by selecting the Uno board tye and then burn booloader in the IDE. Connections are:

CH340G     ProMini 
 DTR <----> DTR
 RXD <----> TXD 
 TXD <----> RXD
 VCC <----> VCC 
 CTS
 GND <----> GND

All three versions yield the same results:

Board type: Uno - Uploads and runs
Board type: Duemilanove w/328P - Uploads and runs
Board type: ProMini 5V w/328P - Uploads and runs

Based on the above, I would suspect that either you don't have a Uno bootloader installed or the fuses are set incorrectly on the target device.

avr_fred:
Tested three different IDE versions under an XP VM environment.

1.0.6
1.56.5-r2
1.6.9

wow, thanks - i really appreciate your comprehensive checking !

avr_fred:
with an identical to yours CH340G board

sorry to be doubtful, but given the multitude of varieties of those things on eBay, can you be quite sure ?

avr_fred:
...and a ProMini with the Uno bootloader installed. This was loaded by selecting the Uno board tye and then burn booloader in the IDE. Connections are:

CH340G     ProMini 

DTR <----> DTR
RXD <----> TXD
TXD <----> RXD
VCC <----> VCC
CTS
GND <----> GND




All three versions yield the same results:

Board type: Uno - Uploads and runs
Board type: Duemilanove w/328P - Uploads and runs
Board type: ProMini 5V w/328P - Uploads and runs

the common factor being the ProMini - i wonder whether these CH340G boards are tailored to cater for the ProMini boards that also proliferate on eBay.

avr_fred:
Based on the above, I would suspect that either you don't have a Uno bootloader installed or the fuses are set incorrectly on the target device.

that 'saga' i mentioned above documents in detail that this should NOT be the case !

as it stands now, i have the original 328P chip on the breadboard, with a sketch loaded WHILE ON the Uno board (normal upload, meaning HAS the bootloader) and runs the sketch (blinking LED on every digital pin in sequence) running on external power source - ie. standalone success.

it really is the USB-to-TTL converter that is not playing nice with this setup i have atm.

sorry - clicked back-browse after the edit and it ended up double-posting
deleting this now

avr_fred:
Based on the above, I would suspect that either you don't have a Uno bootloader installed or the fuses are set incorrectly on the target device.

hmm.... i don't know how this happened - but it does seem the HFuse is not right.

i had used Nick Gammon's "Atmega_Board_Detector" sketch to confirm the bootloader when i first swapped out the chips - and to confirm the signature was 0x0F and not 0x14 (last part) - but only now just noticed the; HFuse = 0xD6 when i believe it should be 0xDA ?

i can't confirm it was ever 0xDA though - but it has worked all this time - on the UNO board.

does the programming chip running the Board Detector sketch make a difference ?

because it is now the 328_ which is in the UNO board.
previously it was the 328P, and i had to 'cheat-edit' the avrdude.conf to upload sketch via ISCP to the 328_ (on the breadboard).

EDIT: i only ran detect (with the 328_ and Nick Gammon's detector sketch) - not Burn Bootloader or anything else of a Write-nature (the sketch is still what was put there via the UNO board - just physically transposed from UNO to breadboard - no ICSP uploading has been run yet)

so... should i use avrdude to manually set/edit the HFuse on the 328P now ?
(could you reconfirm how to do this, i've read the ladyada tutorial on using it, but haven't actually put it in practice yet.)

Seriously, what does any of this have to do with a board detector program?

All that I can tell from your post is that you probably don't have a current Uno bootloader installed because if you did, the hfuse should be 0xDE which says the bootloader is 256 bytes in size. 0xDA says yours is 1024 bytes.

So you're telling me you haven't uploaded a bootloader to this chip? If not, you have absolutely no idea of what that chip looks like to avrdude, other than the device signature.

Edit:
Don't bother with fuses, just burn the bootloader, the IDE takes care of the fuses.

avr_fred:
Seriously, what does any of this have to do with a board detector program?

well, for one thing, it is the ONE resource that i know is reliable.
i don't understand how that sketch works, so i have been giving (maybe too much) information of all the various scenarios that i have encountered, in the hope that it helps show what is going on.

avr_fred:
All that I can tell from your post is that you probably don't have a current Uno bootloader installed because if you did, the hfuse should be 0xDE which says the bootloader is 256 bytes in size. 0xDA says yours is 1024 bytes.

OK, i'm out of my depth here - on Nick Gammon's page, i see in an example, it was 0xDA but now i understand it was 512 bytes for a Lilypad bootloader.

avr_fred:
So you're telling me you haven't uploaded a bootloader to this chip? If not, you have absolutely no idea of what that chip looks like to avrdude, other than the device signature.

Edit:
Don't bother with fuses, just burn the bootloader, the IDE takes care of the fuses.

i have not uploaded a bootloader because i have never had to because it was the original chip that came with the UNO board and i have been using it for years in-situ, uploading sketches to it.

now - i have swapped it with a newer chip (reason in that other thread) - and i didn't think i would still need to burn a bootloader on it - that Board_Detector sketch confirmed it - it HAS the bootloader;

i would rather NOT burn another bootloader AGAIN - not knowing if the programmer chip being a 328_ will make a difference - that 328P is the original chip and i don't want to mess with it (i was even averse to removing it from the board in the first place.)

i HAVE burned a new bootloader onto the 328_ chip, AND successfully ISCP'ed a sketch onto it - but then, using the CH340G, it would not upload a NEW sketch onto it.
EDIT:
i guess that's because, being ICSP'd - the bootloader got erased.
but that is NOT the case with the 328P now - because it was loaded BY the UNO board.

SO; i will now SWAP the chips again - the original 328P back on the UNO, and the new 328_ on the breadboard (WITH bootloader), and i will print the result of the Board_Detector with the complete info, signature and fuses.

and then i will be willing to do whatever you suggest to that 328_, given the condition at that moment.

thanks for your patience in helping me with this odd situation.

Yes, loading a program using icsp erases the entire chip which includes the bootloader - but it leaves fuses intact. This just reinforces my statement that a “board detector” is pretty meaningless troubleshooting tool. Chip doesn’t accept a program? A $3 usbasp, 30 seconds in the IDE and you’ve got a known good bootloader installed. There is no good reason to avoid this step, it’s no different than compiling and downloading a new sketch.

Your hfuse setting is different from what I posted because you’re dealing with an ancient bootloader. I stated I was using Optiboot, which is the the current BL for the Uno which gives you 768 bytes more program space over the older BL in your old Uno.

You have two unknowns, the breadboard and the serial adapter. Put the known good Uno ‘328 in the breadboard and one unknown is eliminated. Try the CH340G adapter. If it doesn’t work, elimate it with this arrangement:

Of course you need the bypass caps, crystal and load caps not shown, I’m just using the image to show how to use the Uno’s serial adapter, a known good piece of the puzzle. If that doesn’t work, fix your breadboard. If that combination works, let me know and I’ll download 1.0.5 and test with the older bootloader in that image and the CH340G.

avr_fred:

ahh yes - this picture was at the start of my whole arduous journey !!

it was so long ago i'd forgotten about it after i'd moved on to the ICSP method and then discovered the 'hack' of editing the avrdude.conf to trick the IDE in thinking the 328_ was a 328P.

SO;

i finally returned to THAT setup (in the picture above) - and LO AND BEHOLD !
i could actually upload a sketch to the Breadboard 328_ (having removed the original 328P on the UNO).
(the difference from before is that the IDE now thinks it is a 328P and not a 328_ - that generic error message of "avrdude: stk500_getsync(): not in sync: resp=0x00" would have saved me so much hassle if it had mentioned wrong chip signature* from the beginning !!)

this would confirm the bootlloader was still intact from being uploaded when ON the UNO board.
(i had not performed any write ICSP connection, just the read from the Board Detector sketch)

so; the UNO board 16U2 (USB-to-TTL chip) finds NO problem with the "outdated bootloader", nor the "wrong HFuse". (nor the actual signature of the chip being a 328_ )

is the CH340G really failing because of an "outdated bootloader" ?
i cannot imagine it makes a check of the fuses - that's all done by avrdude, right ?

side-question (been thinking of starting a new topic) - why is it the Arduino IDE is so averse to the 328_ chip? it does not appear in the boards.txt, and yet so many of the other chips atmega168/atmega168p, atmega325/atmega325p, atmega3250/atmega3250p, atmega329/atmega329p, atmega3290/atmega3290p all appear with BOTH versions....
:frowning:

I'm lost.

Your breadboard:

Which chip did it have? 328 or 328p?

Which board model and chip type are you selecting in the IDE for the download to that breadboard?

avr_fred:
Which board model and chip type are you selecting in the IDE for the download to that breadboard?

following the https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard
i chose Duemilanove, but that failed.
but when i just chose UNO - it worked !

avr_fred:
I'm lost.

Your breadboard:

Which chip did it have? 328 or 328p?

right now, as per success above, the 328_.

the full saga of the swapping is here;
https://forum.arduino.cc/index.php?topic=536460.0

anyway - STOP THE PRESSES - the problem was indeed in this picture;

on the previous problem, i had meticulously tested for continuity on all the breadboard connections - that was of course because it was unrelated to the CH340G module - but on this issue (now on the CH340G) - it didn't occur to me to test THOSE DAMN JUMPERS !! :frowning:

they were BRAND NEW - a rainbow set of 10 which were freshly purchased for this setup !

it really should have hit me much earlier, that when i upload a NEW sketch, the OLD sketch should STILL run before the RESET kicks in - it only dawned on me a few hours ago, that the LED (for the sketch) was NOT blinking !!

i pulled out the old multimeter and - INDEED - TWO of the five on that ribbon jumper was NOT conducting anything !

i checked the other five i haven't used yet, and found yet another one that was faulty !

i am going to get my money back - or a replacement that is tested one-by-one !!

grrr.....

replacing the faulty jumpers with my own sloppy-crimped wires did the trick - Sketch Uploaded !!
[ p h e w !! ]

i guess the bright side is that i got to learn about ICSP and some avrdude, and really went through the paces with 'bootloading fundamentals' - plus i finally "grew up" and popped chips in and out of the Uno board !

Thanks again to every one who patiently helped !!

BabyGeezer ExpertGeezer

I would get rid of those single pin headers and combine them into a 6 pin header.

See the PDF on: FYI Making DuPont jumper wires. - General Electronics - Arduino Forum

larryd:
I would get rid of those single pin headers and combine them into a 6 pin header.

yeah, i have one of those - i guess nothing beats making your own cabling, plus my stock of wire is more flexible than that jumper which is rather stiff. (i still haven't bought a proper crimping tool though, been manually squishing it with pliers for some time.)

i'd already made one for the ISCP with a 3-pin male header for the breadboard end, you might have seen it in the pics i took.

I wanted some clarity on the combination because what I found was that 1.0.6 does not like the 328 used in conjunction with an Uno board type selection. The result is a not in sync error. Later version IDE’s do not do this, they will fail and report the invalid chip signature.

In this situation, 1.0.6 will download if the Duemilanove board type is selected along with the 328 chip type which needs to see a chip signature of 1E 95 14.

This does not appear to agree with you’ve said so I’m now questioning the chip you’re calling a 328. Do you know what the chip signature is as returned by avrdude? Or, your board identifier tool? The picture you posted in #11 is not a 328, it is clearly a 328P as the signature is 1E 95 05.

avr_fred:
I wanted some clarity on the combination because what I found was that 1.0.6 does not like the 328 used in conjunction with an Uno board type selection. The result is a not in sync error. Later version IDE’s do not do this, they will fail and report the invalid chip signature.

ahh, good for those later IDEs then.

yeah - i was really underinformed by the 1.0.5 as well then.

avr_fred:
In this situation, 1.0.6 will download if the Duemilanove board type is selected along with the 328 chip type which needs to see a chip signature of 1E 95 14.

This does not appear to agree with you’ve said so I’m now questioning the chip you’re calling a 328. Do you know what the chip signature is as returned by avrdude? Or, your board identifier tool? The picture you posted in #11 is not a 328, it is clearly a 328P as the signature is 1E 95 05.

yeah sorry - my post in Reply #11 wasn't clear enough then.
i was already swapping chips in and out, just (mindlessly) documenting (thinking i'd look back at them carefully later when less 'stressed' (!) ), and i probably uploaded the wrong image for that post at the time.

the signatures are correct as you have outlined ... 14 vs. ... 05 - (sorry to harp on it again, but this was all in that "saga" thread)

i basically found the solution to "handling" the 328_ chip based on the information on these two threads;

http://forum.arduino.cc/index.php?topic=244971.0
and
http://forum.arduino.cc/index.php?topic=58670.0

hopefully that clears up any gaps on this thread for anybody with the same problem in the future.

should i edit the topic Subject to reflect a better parameter for other ppl's searches ?