Must-haves for EASY DIY controller?

[ZenMastr1968]

Uploading shouldn't be a problem. The issue might be wiring problems causing the AVR not to run correctly (a short, etc.) It's usually a good idea to not use the tx and rx pins of the serial port (digital pins zero and one) for anything external because that CAN cause issues, if the circuit is connected during upload.

The example wasn't using D0 or D1 and even now with looking at the RBBB schematics, I have the cap in-line with the reset pin, tx, rx, vcc, and ground and have them wired into the header on the USB BUB and still no joy. keep getting a

avrdude: stk500_recv(): programmer is not responding

error in the results window and a message saying problem uploading to the board - check this link.

are there any lights that show transfer activity with the BUB?

It's powering the board when I'm connected to the BUB, so that's at least working and it still has the last sketch I uploaded to it - the LCD Blink example which says hello world with a blinking cursor on the LCD...

 

[der_wille_zur_macht]

Yeah, I see what you mean. Well that will be an easy test/fix tonight, I'll just solder it on the bottom.
As I said, I had the exact same problem (of not being able to read the datasheet properly).

Could also probably do a 180 and just turn it around (so the flat side was facing down instead of up).

The example wasn't using D0 or D1 and even now with looking at the RBBB schematics, I have the cap in-line with the reset pin, tx, rx, vcc, and ground and have them wired into the header on the USB BUB and still no joy. keep getting a

avrdude: stk500_recv(): programmer is not responding

error in the results window and a message saying problem uploading to the board - check this link.

are there any lights that show transfer activity with the BUB?

It's powering the board when I'm connected to the BUB, so that's at least working and it still has the last sketch I uploaded to it - the LCD Blink example which says hello world with a blinking cursor on the LCD...

Modern Device's BUB has a TX light on it that should blink when data is moving in either direction. It's a tiny orange SMT.

You might want to post on the Arduino forums or Modern Device's forum and see if anyone can help, you'll get a broader response there than here most likely. It sounds like the BUB isn't talking to the AVR.

 

[terahz]

The example wasn't using D0 or D1 and even now with looking at the RBBB schematics, I have the cap in-line with the reset pin, tx, rx, vcc, and ground and have them wired into the header on the USB BUB and still no joy. keep getting a

avrdude: stk500_recv(): programmer is not responding

error in the results window and a message saying problem uploading to the board - check this link.

That message shows up if the AVR chip doesn't have the arduino bootloader in it. But there might be other reasons.

Could also probably do a 180 and just turn it around (so the flat side was facing down instead of up).

Yep, that should work too.

 

[der_wille_zur_macht]

I wonder if you'd get that message if you tried to transmit and the chip hadn't been reset (i.e. if the reset circuit was messed up.) The chip needs to be at the right spot in it's boot sequence to accept new code. Typically the BUB will use it's reset pin to reset the device as the first step in attempting an upload, then start dumping code. So if the reset pin isn't soldered correctly, or is otherwise failing, that may be why you're getting that message.

If you push the reset button on the RBBB, does it actually reset? When you attempt to upload code, does the device reset?

If the reset button works but the device doesn't reset when the upload attempt is made, try manually resetting it, then immediately (before it's done booting) starting the upload.

 

[ZenMastr1968]

I wonder if you'd get that message if you tried to transmit and the chip hadn't been reset (i.e. if the reset circuit was messed up.) The chip needs to be at the right spot in it's boot sequence to accept new code. Typically the BUB will use it's reset pin to reset the device as the first step in attempting an upload, then start dumping code. So if the reset pin isn't soldered correctly, or is otherwise failing, that may be why you're getting that message.

If you push the reset button on the RBBB, does it actually reset? When you attempt to upload code, does the device reset?

If the reset button works but the device doesn't reset when the upload attempt is made, try manually resetting it, then immediately (before it's done booting) starting the upload.

I have an LED on pin D13 and that flashes once when the device powers up and then I see the message on the LCD. If I push the reset button it flashes again. Sometimes when I click upload in the arduino 0018 development interface the LED will flash. I really only see the light on the BUB flash when I first connect the cable to my laptop. Thanks for both your help - I'll poke around the moderndevice board and see what I find.

 

[ZenMastr1968]

OK, guys - problem solved... I did some poking around on the modendevice boards (didn't see that it existed until you mentioned it) and found someone with a similar problem - same receive error.

Turns out that if it isn't uploading you get a sync error instead....

Anyway in that thread the guy hadn't hooked up the DTR to Reset - which I did even with the proper cap, but in that discussion they made mention that the tx/rx lines are labeled as seen from the other side and thus are reversed. I switched the wires on the tx and rx and volia! uploaded the Hello World sketch and I have hello world and a time count on my LCD...

I'll probably order a replacement RBBB board and move the existing parts to a new board and just go with a straight header this time....

additional uploads of other LCD examples seem to be working flawlessly!

Thanks again guys - this is such a cool device....

 

[terahz]

ok, U11 is indeed reversed. Turning it around makes the circuit more stable, now the voltage I measure gnd to gnd is negative and for a very short time, then it stabalizes to -1.0mV (which is still bad for GND to GND).


On the 7660 chip, now the negative output is split exactly in half (-4.5V) if I measure at the chip. If I measure at the 7905 it is ~0.2V.

I tried the simple circuit of 7660 + 2 caps + 7905 and it works as described in the datasheet:
9V in the 7660, -9V out and in the 7905, -5V out of the 7905.

Something on the board is interfering with this circuit.

DWZM, what is D1 for? I see it is on one of the Vins (the molex pins) but not on the other.

 

[der_wille_zur_macht]

I added the 7660 and 7905 (backwards) and associated caps, and it works fine - I have 9.15v in, about 8.9v at the input to the 7660 (due to D1's drop), -8.89v at the output of the 7660, and -5.04 at the output of the 7905. I don't have the pH amp wired up yet, but it looks like the negative supply is working fine. I wonder if you fried a part (maybe in the pH section) when you had the 7905 backwards? Or at least is there is an inherent problem it must be somewhere in the pH circuit because that should be the only difference between my board and yours (it's not built on mine yet).

D1 is for reverse polarity protection at the molex Vin pins, since I imagine reversing that input would be easy. iirc the reference design (Duemilanove) has a series diode for reverse polarity protection at it's "normal" Vin location (the 2.1mm jack) but not at the Vin on the shield pins (i.e. the "Vin" on the shield pins is downstream of the polarity protection), so I just copied that. The way I see it, the Vin molex connection is for supplying power to the board, and the Vin pin on the shield outline is for the board to supply (reverse-polarity-protected) "raw" power to shields that something higher than the regulated 5v supply, such as my ELN dimming shield.

 

[der_wille_zur_macht]

PS - with both AVRs running, the LCD, and the negative supply, it's now consuming 61 mA.

 

[terahz]

Found it... turns out when I removed C30 I shorted U5VIN with GND slightly. That was my strange short. Reversing the 7905 fixed the rest.

Now with everything populated I get 278mA, U12 gets very hot after a couple of minutes and U1 increases a few degrees above all other ICs.Without U1 I get about 65mA.

I might try desolder U12 and put a touch of arctic silver under it. My 7805 is rated at 1A btw.

 

[der_wille_zur_macht]

I will do a schematic check on U1, because I really doubt it's supposed to pull THAT much current. I've heard people call it "power hungry" but the only spec I recall from the datasheet is that the inductor has to be good for 80mA, not 200!

 

[terahz]

It's alive

It's alive

Well after spending several hours trying to figure out why my LCD wouldn't work I finally figured it out:

After some surgery all is good:

I also tested the PH circuit and seems to be quite stable. I connected a PH probe and calibrated my hydra. Still have to test it against my salifert ph kit though.

Another note, seems lke the 7805 gets hot only when the board is connected both to my laptop via FTDI and to the PSU. If I use only the PSU or the FTDI cable everything is cool.

 

[terahz]

I populated the circuit for the second AVR last night and "tested" it by running the blink sketch with an LED, while the existing AVR was running the LCD using the RTC. It was a little alarming how far off the timing was. I don't mean "not synched" but rather that the blinking LED had a lot of variance compared to the time ticking over on the LCD.

I played with that too just now. I think the problem is, if you try to sync them (by, say, polling the RTC all the time until the second changes and then print/blink), you get garbage on both AVRs because they both try to talk to the RTC at the same time.

I'm doing a simple if (psecond != second){//print time and update psecond} on the main AVR, but if I do the same on the second one, both lose the time. I guess the problem comes from sharing the i2c bus. If we want RTC on the second AVR we'll have to add another RTC chip, but I don't think we need that. Not yet anyway

 

[TheFishMan65]

IIRC you can't have two masters on the IIC bus, at least not easily. I think I would plan on sending the data/time to the second AVR and have a timer there keep count. Maybe update it once an hour.

 

[der_wille_zur_macht]

Well after spending several hours trying to figure out why my LCD wouldn't work I finally figured it out:

D'oh!

I also tested the PH circuit and seems to be quite stable. I connected a PH probe and calibrated my hydra. Still have to test it against my salifert ph kit though.

That's good news. I was a little worried it would be all over the place since we stuck it on the board next to all that other stuff.

Another note, seems lke the 7805 gets hot only when the board is connected both to my laptop via FTDI and to the PSU. If I use only the PSU or the FTDI cable everything is cool.

Yeah, kind of not surprising. The Duemilanove and some of the more sophisticated boards have a circuit that auto-switches the power source so both can't be "on" at the same time. Meanwhile the RBBB uses the exact same power arrangement, more or less, as the Hydra. I asked Paul what would happen if you had both connected at the same time and he said he didn't think anything bad, but he wouldn't recommend it.

but if I do the same on the second one, both lose the time. I guess the problem comes from sharing the i2c bus. If we want RTC on the second AVR we'll have to add another RTC chip, but I don't think we need that. Not yet anyway

IIRC you can't have two masters on the IIC bus, at least not easily. I think I would plan on sending the data/time to the second AVR and have a timer there keep count. Maybe update it once an hour.

I2C CAN be multi-master:

http://www.i2c-bus.org/MultiMaster/

But I'm guessing it requires more overhead than I think we're willing to deal with and I don't think I've ever seen it implemented on Arduino. IMHO we should pick one or the other to be the master, and the master AVR can tell the slave AVR what time it is when it needs to know. (Once an hour or something, like FishMan suggested). Of course the differences are that the lower AVR (U6) has the pH and Ethernet interfaces hard wired on an analog pin and SPI, and it has the LCD backlight pin (for now at least). Originally I was assuming it should be the master, but now I'm not so sure.

Besides separating out based on the hard-wired circuits, we should probably separate out based on interruptibility of different functions. For instance, getting a pH reading should take microseconds because it just has to read the analog input pin (maybe read it a few times and average values, but still it'll be quick.) Meanwhile, if we implement One Wire on one of the AVRs to use the common temp probes, we have to account for the .75 second delay built in to the One Wire library. Or, if we need to ramp a PWM pin rapidly with high accuracy, or do other high-accuracy switching (i.e. to control a wavebox) we might want to consider that, as well.

 

[MarCn]

D'oh!



That's good news. I was a little worried it would be all over the place since we stuck it on the board next to all that other stuff.



Yeah, kind of not surprising. The Duemilanove and some of the more sophisticated boards have a circuit that auto-switches the power source so both can't be "on" at the same time. Meanwhile the adipex no prescription RBBB uses the exact same power arrangement, more or less, as the Hydra. I asked Paul what would happen if you had generic viagra both connected at the same time and he said he didn't think anything bad, but he wouldn't recommend it.





I2C CAN be multi-master:

http://www.i2c-bus.org/MultiMaster/

But I'm guessing it requires more overhead than I think we're willing to deal with and I don't think I've ever seen it implemented on Arduino. IMHO we should pick one or the other to be the master, and the master AVR can tell the slave AVR what time it is when it needs to know. (Once an hour or something, like FishMan suggested). Of course the differences are that the lower AVR (U6) has the pH and Ethernet interfaces hard wired on an analog pin and SPI, and it has the LCD backlight pin (for now at least). Originally I was assuming it should be the master, but now I'm not so sure.

Besides separating out based on the hard-wired circuits, we should probably separate out based on interruptibility of different functions. For instance, getting a pH reading should take microseconds because it just has to read the analog input pin (maybe read it a few times and average values, but still it'll be quick.) Meanwhile, if we implement One Wire on one of the AVRs to use the common temp probes, we have to account for the .75 second delay built in to the One Wire library. Or, if we need to ramp a PWM pin rapidly with high accuracy, or do other high-accuracy switching (i.e. to control a wavebox) we might want to consider that, as well.

Thanks for sharing

 

[TheFishMan65]

I did a quick read of the link above. I was wrong multimaster is supported. I am betting that the arbitration scheme was not implemented in the AVR. It would be possible, but awkward. So I think you/we are better off telling the second part what time it is. Or setup a method to allow the second part to have access to the bus for X seconds.

Master avr would tell the slave avr to do something. The master would have to know that the slave needed the IIC and stay off for a certain mount of time. Disadvantage is that things need to be synchronized, but that should not be to bad if the slave only as a set of low level commands.

However, what besides the time do they both need access to? Why have the slave read it if the master can?

 

[williah]

I love this thread! Keep at it, guys. Great job!

 

[ZenMastr1968]

I was just trying to finalize my last order, a question about C10 was bought up before (and I know it's the way it is on the board) but is there an alternative?? It's on backorder at Mouser....

Can I just use any 10uF for breadboarding purposes??

 

[blackizzz]

have u guys seen the http://regexp.bjoern.org/archives/000189.html to use phidget sensors easy? there's a PH sensor for 25 bucks if u go to the phidget webside.

pretty good deal?
(maybe the pcb and components are really expensive though)