Forum Replies Created
December 5, 2013 at 1:47 pm in reply to: Inexpensive microcontroller programming setup for an educational project: does anybody have one? #21595
How reliable are the CP2021s? I’ve been unimpressed with at one or two of the generic USB/TTL adapters I’ve gotten my hands on. Tend to stick with FTDI which are a bit more. In this case it may not matter, since you can apparently get Leonardo compatible boards which have integrated USB hookups and use the ATMega to emulate USB serial for just a few cents more than your combination of TTL adapter and Arduino.
Incidentally, if some of your wires are loose, you can get exactly the same error even with the correct chip… I mean, so I’ve heard. ;)
I haven’t ever seen the code that runs the clock,though I’ve considered getting one at some point. Are you decent with programming in general? I ask because I personally don’t find programming an arduino to be much different than programming anything else. Especially if you do c or c++ sometimes, you’ll be right at home.
Anyway, off the cuff I wonder whether you could take the ground connection — or depending on the circuit, the positive lead, whichever is shared — from the LEDs and hook it into an arduino pin. Setting that pin high or low would then make it possible or impossible the diodes to light. Might be able to do this in conjunction with some simple checks of the time to easily flip your display on and off.
So, just having had the experience of dealing with two third-party USB to TTL boards and a Diavolino in combination, maybe I can contribute something here. First, I may be reading you wrong, but you may be thinking about this in the wrong way. That a pin is ground certainly doesn’t mean you should apply voltage to it directly. In fact, in this case, you probably — perhaps depending on how you built your Diavolino — want to think of it as a case of the adapter providing power to the Diavolino. Did you build it to pull power from the TTL adapter?
So, what I mean by that is that they should be connected ground to ground and +5v to +5v. RTS is used to trigger the auto-reset of the Diavolino, so I suspect that it should connect to the RST pin on your adapter. RX and TX are trickier, since I’m really not sure if there’s a standard for labeling them that prevents people from getting it backwards; that is, I don’t know if RX always means “I receive signals here” or it may sometimes mean “connect the remote receiver here” (making it actually TX…) Anyway, I’d try connecting RX on the adapter to TX on the Diavolino and vice versa. If this doesn’t work, swap wires on one end, connecting TX to TX and so on, just to make sure.
Because ground and CTS are basically the same line, there’s not really a need to hook both of them up. I’ve been using a five pin arrangement that just skips attaching anything to the ground wire of the Diavolino and grounds CTS instead. This works for me, though perhaps there’s some reason it would be better to just use the ground pin. Certainly, don’t directly supply voltage to them. :)
So, briefly, what I’m suggesting (and what works so far for me) is this:
RST->RTS (I think, though my adapter isn’t as vague about it. I actually connect DSR there)
RX->TX (or maybe RX if this doesn’t work)
TX->RX (or maybe TX…)
CTS->GND (or you can leave it open if the next pin is grounded)
GND->GND (…or you can just use CTS above.)
Now, a few warnings. Don’t apply voltage backwards. I did this once, and it heats up the ATmega in the Diavolino pretty well. Luckily no damage, but be very careful. Also, if you’ve managed to get your TTL adapter to produce a burning smell, I’d test it before trying to get it properly hooked up. At least do a loopback test. This involves disconnecting everything from the adapter, connecting its RX and TX pins together, and plugging it in. If you have a standard old terminal program, you can open it up, telling it to use the adapter’s port for communication. Now try to type something in. If you can see what you’re typing, there’s a reasonable chance that the data is flowing through the adapter, out of the TX pin, into the RX pin, and making it back intact. This is good news.
Of course, it doesn’t guarantee that the thing will work. Of my TTL adapters, one of them refuses to properly toggle the auto-reset, nor have I been able to get it to program the board properly even when I hit reset manually, and the other works fine. Both do loopback connections just fine, and so are functional in some sense of the word. Anyway, hope some of this will help.
The AVR is working in the Diavolino. It’s not working in the breadboard. It’s hard to tell exactly what’s not working, except that when I remove it from the board, and place it into the circuit on the breadboard, which I think is correct, it isn’t blinking the LED.
I suspect a clock issue just because it’s one of few problems I can come up with that could cause the chip not to do anything. The other ones being power (and I think it’s getting power ok) and a low reset signal (which I’ve pulled high quite purposefully)… I might be missing something else I’m not thinking of, of course.
I suppose I should mention that I’ve tried two identical crystals and two identical sets of capacitors, with the same results.
The leostick does appear to have some fundamental problems with the way the arduino-as-isp stuff is handled, and I think this shouldn’t be a huge problem for me now that I can get code onto the Diavolino, which ought to be much more usual in that regard.
As for the other TTL adapter, so far I know that a loopback does work as expected. There’s actually a pin on this adapter labeled “reset,” which makes it pretty obvious where it’s supposed to go, and as I said, the power is at least working sufficiently well to drive the board. I do wonder what (if anything) it’s doing with that reset pin, and perhaps I should tack a multimeter onto the end of it and see.
Luckily, I also have a pro-mini clone — the intent here is to use the Diavolino in development of a project to be built with the pro-mini — so I can verify that the Diavolino isn’t the only thing which will program with one TTL board and not the other.
Yes, I suppose it should. Well, it turns out that things aren’t quite as bad as I thought they may be. No electrical problems with the board at all. The reason that it wouldn’t program is that the TTL serial adapter I was trying to use (which is a cp210x) doesn’t seem to like programming arduinos at all. What’s more, the reason I thought the blink sketch was starting immediately after a reset was that I couldn’t easily tell the difference between the LED strobe from the power being applied to the board and the blink from the sketch. :)
If I use the FutureTech board, (even without trying to wire it into the ISP header) it does work exactly as it should. Let me change my question again. Do you think the other FTDI board is hopeless? I’d kind of like to get it working, but I’m not sure where to start. It does apply power just fine. Doesn’t seem to reset the boards — hopefully I can say that with some certainty now since I’ve replaced blink with my own soft PWM fade sketch, so the difference between the twitch from the power-on and the running sketch is obvious. I also haven’t been able to get it to program properly even resetting it manually, nor does swapping rx/tx seem to help. I thought it might have them backwards, but perhaps not.
I’ll check those perhaps later tonight, then. The 10k resistor is a pull-up for the reset line, right? So should I be able to tell for sure that it’s working by actually testing the current through the reset pin? Obviously I can check the solder joints manually and make sure it has 10k of resistance between poles, but I’m wondering whether there’s something more useful.
As for the capacitor, that handles the auto-reset function, doesn’t it? So what’s the best way to test that this is correctly installed? Is there a way that I can check the function of the auto-reset reliably? Also, (hopefully) this thing is non-polar, right? :) I don’t remember from when I was assembling it.
Well, I’m beginning to wonder whether this thing has a bootloader on it. Just tried it with an FTDI board, and depending on which way I arrange the RX/TX pins, I get either a complete hang and a data light that’s perpetually on, or an error stk500_recv(); programmer is not responding. Reset never seems to trip, or rather, it probably does, but the LED flashing just starts right back up afterward with no delay.
So, I thought I’d try the ArduinoISP stuff and see if I could get a loader on there. Unfortunately, the Leonardo platform seems to have some problems with it. MISO, MOSI, and SCK have been moved off of the usual pins and isolated in the ISP header. This isn’t a deal breaker, since I can run them out from there. I’ve redefined reset in the sketch to use pin 10 instead of pin SS. This all should work in theory, but there appears to still be some problem with the process, since avrdude keeps seeing different device signatures on the chip. (Further, trying this with a separate, fresh ATMega on a breadboard achieves the same result, so I’m assuming that this is a problem with my ISP programming and not with the chip or the board.)
At home I have a FutureTech TTL adapter, which maybe I could use to bit-bang the loader in through the ISP connection, so Google tells me. Haven’t tried actually using it yet, though, and who knows? I’m not having the best of luck with this so far. Any other ideas?
Also, good news. It looks like I just got my TTL stuff today. I should be able to do a proper test shortly. Still, I wonder what I might have been doing wrong here. Anyway, we’ll see how it goes.
What might it mean if the delay isn’t noticeable? As I was saying, it seems to start right away and just keep going. I hadn’t been too worried about it, given that I have not been able to try programming it correctly yet, but could this be an indication of some sort of problem?
Does the loader flash the pin 13 led, then? It begins to flash as soon as it gets power and doesn’t stop unless you pull reset low.
ChrisJune 28, 2012 at 5:36 pm in reply to: Nokia PCD8544 (5110 LCD display) is a little strange #20745
Well, you’d be able to do it a row at a time, where if you were doing 84 pixel rows, each set of two rows would have a byte split between them, so it would be equally easy to scroll off the edge by two rows, but it would be kind of a pain to do one. Still, I think aesthetically, I’d prefer that they picked a direction and stuck with it. If they’re mapping everything column-wise, just do one screen column after the next, so that your image ends up needing a simple rotation in order to behave the way you think it should. Start at the top left, draw the entire column straight down, and so on. With a little bit of pointer magic, you could still make it reasonably easy to scroll something off the display.
Anyway, that being said, it’s now _just_ an aesthetic argument, since everything is working. I’m looking at the way it handles text now, which has its own oddities. The font that’s built in is a 5×7 pixel font. The entire font is packed into an array, and the text handling functions have the 5×7 hard-wired into them. They’ll resize it in multiples of two by drawing filled squares on the display instead of pixels, but that’s pretty much it. I’m thinking about trying to load in a larger font (at least to display numerics) and also support alternate languages, at least in such a way that you could use the display to render non-ascii characters in some way.
ChrisJune 28, 2012 at 11:04 am in reply to: Nokia PCD8544 (5110 LCD display) is a little strange #20743
That makes some sense now that you mention it. Fonts tend to be stretched horizontally much more often than vertically. I do also note that 48 is divisible evenly by eight, while 84 is not. This means that if you’re obsessive-compulsive enough to want to insist on your rows (or columns) always ending on a byte boundary, you’ll need to draw column-wise on this display.