The Craftmans Shop > Radio Control Models
Bruder Manitou 2150 - RC conversion
ddmckee54:
And it just keeps getting better and better.
When I try hooking up to the Nano my set-up for the Com port selection is greyed out. If I'm understanding what I've found on the Interweb correctly, my Chinese clone Nanos are using a counterfeit communication chip that the driver for the real chip doesn't recognize. Some kind soul figured this out, and wrote a special driver just for these chips. I've now got this driver and tonight I'll try loading it. I'll find out if I can actually talk to the Nano. All I'm trying to do at this point is get the Nano to blink the built-in LED. That's the Arduino equivalent of the "Hello World" program in C++. (Baby steps donchaknow.)
Don
ddmckee54:
Well..... It took until after 10:00 last night but I finally got it to run the Blink program, the Arduino equivalent of "Hello World".
I found out many things last night, primary among them is that Google is your friend,
I found out that I DO have the CH340G communication chips on my Chinese clone Nanos and also that not ALL CH340 drivers are created equal. I had to go through several different drivers before I found one that even appeared to work. That got me up to the point where the error message was that it couldn't sync up. Back to the Interweb and Google's still being my friend.
I found out that some chips used 57600 baud and others use 115200 baud. Wait a minute, I"VE got to set the speed? I've gotten spoiled by software packages that do the minion work for me. Oh well, we'll do this the hard way, what's my serial port set at? 9600 baud, NOBODY's used 9600 baud for years and years. We'll try 57600 and see if that works... No Joy, let's try 115200.... And EUREKA, I got a different error message!
This time it's telling me the programmer's not responding. Back to the Interweb and Google's still being my buddy and pal. It seems that some Chinese ATmega328s are being shipped without bootloaders, one of the reasons they are so cheap. WTF, do I NEED a bootloader? How do I get one if I do? Turns out I can use a Nano to burn a bootloader on another Nano... As long as I've got a working Nano - so that option's out. Does it seem like I'm stumbling around in the dark here? If so, you're absolutely right. A little more research and it seems that you don't really NEED a bootloader if you set up the IDE programming software correctly. Go through and check the appropriate boxes and... NOPE, still doesn't work, programmer is STILL not responding.
Back to the Interweb, and while Google is not being my bestus Bud anymore, he still kinda likes me. It seems that while some Chinese ATmega328s are shipped with the NEW bootloader, some are still shipped with the OLD bootloader. And guess what, there's an option in the software for an ATmega328 with the OLD bootloader. OK, we'll give it a shot, if this doesn't work I'm goin' to bed!!…. Ah - VIOLA, "Hello World", I have a Nano with a blinking green light, on for a second, off for a second and repeat 'til I tell you to quit. Just like the program says - it's bedtime.
Tonight I'll start picking away at getting it to do what I want it to do. Is an Arduino always this much fun getting the communications set up?
Don
ddmckee54:
I found out a few things about the Arduino Nano, and the Arduino programming language last night. If you're not interested in programming, mostly just the basics, then you probably want to just skip to the end.
I set up a simple input/output program and the hardware to match it. I declared a couple of digital pins to be inputs and a couple more to be outputs. Then wrote a conditional statement - If the X input is on, then turn on the Y output. Easy-peazee right - not so much.
I found out that this programming language is REALLY case sensitive. For instance, I can type pinmode(), or pinMode(), and some languages will recognize that I want the pinMode() command. (Declaration? It's been too many years, and I had trouble keeping them straight in college.) But NOOOOO...., not this one. It took me a while to figure out what the "pinmode not declared" error message was actually trying to tell me.
A little lesson in binary, and integers, and other fun stuff. Binary is all 1's and 0's right? Ummm…. no so much. A binary condition will either be HIGH or LOW, right? Those statements are the same, right? In some programming languages you can get away saying 1 is equal to HIGH, and 0 is equal to LOW, but not this one. I had declared Ch_1 as an integer variable and did a digitalRead(2, Ch_1). I assumed that this would put a value of 1 into Ch_1 whenever the digital pin 2 was at +5V.
My conditional output was this; if Ch_1 is equal to 1, then turn on the output. I got nuthin'. I jumpered the LED to +5V and the LED came on, so I knew the hardware worked. The problem was in the programming, but where? I even tried to use the built-in LED - no difference. It's been 20+ years since I did any electronics design and I am a LITTLE rusty. I was figuring that I screwed up somewhere, but since I could jumper it and it would work then apparently I had got the hardware right.
Then I started wondering, since this is a digital input, maybe it assigned a Boolean value to the digitalRead()? OK, let's try that. Declare Ch_1 to be Boolean and the digitalRead(2, CH_1) stays the same. But the output condition changes to this - if Ch_1 is equal to HIGH, then turn on the output. Try it again, and SHAZAAM, the output comes on.
Wait a minute, why isn't it turning off? A couple of seconds later it turned off. WTF is going on here? After scratching my head for a while, I've been in this industry since the 70's and I've scratched most of the hair away, I started wondering if I needed to add pull-up or pull-down resistors? Google is my buddy once again, and I find out there's a version of the pinMode() declaration that will activate the built-in pull-up resistors on the digital pins used for inputs. Since the pin is always HIGH now, I've got to jumper the pin to 0V to test my programming and invert the output conditions.
Download the updated program, test it, and HOT CHACHACHA... I've got control of an LED, and it only took me how long??? Holy-Crap, it's past my bedtime. Time flies when you're having fun?
Don
ddmckee54:
I did something stupid over the weekend, I broke my communications between the Nano and my PC.
I'm not sure how I did it but somehow the wrong drivers got loaded and now it won't talk anymore. I think I may have plugged it into the wrong USB port, and that's what started this mess. I saw that instead of the CH340 driver on COM5, I had the Ramps driver on COM4. The Ramps driver is what the IDE software will load when it detects a Nano on the USB. The only problem is that the Ramps driver is for the FDTI chip and I've got the CH340G chips on my Nanos.
I reloaded the driver that I thought worked but now no joy. Back to the Interweb, and hope that Google still likes me.
Don
ddmckee54:
Once again I'm beyond the "Hello World" stage, not much to see except a couple of blinking lights.
I discovered a couple of things:
If I disconnected the communication cable at the PC end nothing bad happened. If I disconnected the cable at the Nano end, the IDE software loads the Ramps driver for the COM port. This is onna-conna that Ramps has the FTDI drivers in it and that's what Nanos are SUPOSSED to be using since a real Nano uses the FTDI chip. Except that I've got Chinese clone Nanos with the CH340G chip, and I need the CH340SER drivers. (Note to self - NO more disconnecting the Nano without FIRST disconnecting the cable from the PC!!!)
One other thing I discovered is that I've got 2 different flavors of Nanos, which kinda makes sense - since they were from 2 different suppliers. They both have the CH340G chip, but one type of Nano requires the "Old" style bootloader at 115200 baud, and the other type of Nano requires the new style bootloader at 128000 baud. Oh frabjous day...
At least I know what I did wrong, and how to fix it - now.
Now that I've got the communication going again, I'm back on track and I've got a bunch of logic tested and de-bugged. I've got the NANO set up on a bread-board with outputs for headlights/tail-lights, left front turn signal, left rear turn signal, strobe/beacon, and back-up lights. I've got digital inputs for moving (Yes/No), turning left(if we're not turning left we gotta be turning right), brakes(Yes/No), and direction(For/Rev). The brake lights, rear turn signals on steady, are currently being triggered off a digital input, when I get the R/C logic working this will be changed. I'm planning on looking at the average value of the For/Rev stick pulse. If the speed, either forward speed or reverse speed, is decreasing then the brake lights will be turned on for a couple of seconds. When I'm turning and the brakes are on, I flash the appropriate rear turn signal off instead of on.
I haven't got the R/C receiver pulse logic done, that's the next step. I HAVE got the logic done that looks at the pulse length values for the for/rev channel and the left/right turn channel, and then decodes this for the various LED functions. I won't bother with the right turn signals until I start putting the lights on the model. The RH turn will just be a copy/paste/edit of the LH turn-signal logic.
Don
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version