OpenServo.com

[tillin9]

Howdy, I'm looking to try OpenServo for a project of mine and already put in an order with Jay for a couple boards. However, I'm interested in being able to make them myself. While the SMD components were the issue I had been dreading most, he informed me that programming the AVR micro was what he found most difficult. Looking around the main site and forum, I was only able to find the wiki page for making version 1.x boards and the minimal 2.x wiki page, hence I thought I'd ask in the forums how people were flashing their 2.x boards. My main concern now is what programmer and tools are needed.

I googled the STK200 programmer and found a few (different) schematics that looked a lot like a wiggler JTAG programmer which I happen to have. So I was wondering if they are actually the same (I'd need someone to confirm the pinout for the STK2000) but if I could made an adapter for my wiggler, that would be ideal.

I also have three other programmers which might be useful, a TopWin2000 (EEPROM/ PIC), PicKit2, and a JDM2. Unfortunately I don't know if any of these can do AVR programming (or easily modified to do so) since I've been using them to try to learn PIC programming. A few PIC sites online say the JDM2 can do AVR too, but it would be nice if someone with AVR experience could give a more definitive answer.

Would a 32-pin TQFP to 32-pin DIP adapter be useful for programming and testing OpenServos?

If so, does anyone have a cheaper source for them. The ones I found were in the $150 range.

Finally, while I'm not completely opposed to using Windows tools for any of this, I'd love it if I can use open source (i.e. can run under Linux) software to build my OpenServos as my primary machines don't run Windows.

Thanks in advance.

[mpthompson]

Given the early state of the OpenServo it is really important to be able to reflash the ATmega168 and program the MCU fuses when needed. As you may have read in another thread I'm doing some bootloader work which will require the ability to reflash and modify the MCU fuses on the OpenServo to use the new bootloader.

Basically, what I do is start with a built OpenServo and flash the MCU on-board with an STK500 with pins from the In-System Programming (ISP) header appropriately routed to the OpenServo edge connector.

The STK500 is really a dev board so it has a lot of uses beyond just programming the OpenServo. Other ISP based programmers meant for AVR MCUs should work as well.

The connections from a 6-pin ISP connector are shown below:

[tillin9]

Thanks for the quick response. Sorry if I was unclear. My question was mainly if this schematic:

is that of the STK500 programming dongle.
Unfortunately when I quickly looked at it, I thought parallel port, resistors, 74244...this looks like the wiggler! whose schematic is here:

If these are both correct, my idea of making an adapter on the end of my wiggler (for OpenWRT development) and using it for OpenServo won't work. However, if the STK500 schematic is correct, I can make one myself very easily. I'd hate to have to buy the Kanda one for $50, if its less than $5 worth of components I already have. Considering the Kanda programmers can be adapted to program JTAG, this makes me hopeful.

However, while both designs technically can provide digital I/O on the AVRs ISCP pins, they're worthless without the correct software. My TopWin 2000 (purchased for Etherboot work) uses a 8051 micro (whose IC numbers were scrtached out) and comes with a 48-pin ziff. It could program any micro easily, however, its window-only software doesn't support custom templates and the company does everything possible to make it impossible to reverse engineer anything for it.

My biggest frustration with trying to learn the PIC, that there was no real 'standard' programmer and software. One would think this would be the first thing the company would provide and try to encourage everyone to use the same reference design as to make it easier to use their micro. I finally found the PicKit2 ($35) which integrates with MTLAB and has its own GUI based programmer software in Windows and integrates into pikLab and has its own CLI based software in Linux. This is the closest I could find to a standard programmer. I essentially want the same thing (if it exists) for AVR.

Anyway...sorry about my rant, my question was what programmer and software do people here use for OpenServo? If nobody has the schematic for the Kanda dongle, I can just buy it if that is the 'standard' AVR programmer and there is software to support it (the wiki suggest avrdude for windows, google suggest UISP for linux). Do people use PonyProg? I didn't get it since its not the 'standard' PIC programmer, but it says it can do PIC, AVR, SEEPROM, and function as a Windows/ Linux serial to I2C adapter.

[ginge]

Hi,

You can flash the initial software onto an OpenServo with just a few components. In the wiki I wrote up about the DIY STK200 which can be programmed through win32/linux using avr-dude

http://openservo.com/moin.cgi/STK200

It is quite similar to the ones you have posted above, but is known working with OpenServo.

You will need to route the pins in the schematic above to the OpenServo pins

http://openservo.com/moin.cgi/OpenServoPinout

I compiled a list is steps to get your own OpenServo build and running here
http://openservo.com/moin.cgi/StepByStep

The above is what I use occasionally, and is similar to the schematic posted on the wiki. I believe what you have is the buffered version of the STK200, which also works well.

I hope this helps.

Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

[tillin9]

Thanks. The wiki pages were a little unclear about what information applied to the Version 2.x as well as the 1.x. I think I'm more or less up to speed now.

It is really good to know avrdude is BSD/Linux/Windows and even has a Debian package!, I'm kind of surprised my initial searches didn't bring this to my attention. Checking the homepage, I see schematics for buffered and unbuffered versions, so I can definately build a compatible programmer. Since I have dozens of 74244 chips just lying around, I should use one and build a buffered programmer to be extra safe as I've known people who fried their new Core Duo 2 motherboard because of using an unbuffered JTAG and having 12V go through their parallel port. Luckily nothing that bad ever happened to me. Anyway...

With this information I believe I can program a suitable AVR under Linux with the OpenServo .hex using a TQFP-DIP adapter. My guess is that this is the easiest thing to do. Plus since there are many PICs and AVRs that use the TQFP form factor I can use the adaptor for other stuff too. My PLCC32-DIP adapter has come in handy too many times to count, so I know these things are nice to have.

However, programing on the OpenServo board is still a little confusing. Jay mentioned something about dealing with the 7V during programming and Mike mentioned a diode his boards might not have. This leaves me confused as to if I should power the board from Vbat (7V) or +5 when programing. My question is why does it matter? If I get +5V to power the micro from the onboard regulator or an offboard regulator, it should work assuming there is a common ground. Is this some kind of noise issue, i.e. the AVRs are really sensative?

Also, I had been lurking on the forum for awhile and found the 3.3V thread. What's the deal with this? Can the AVR work from a 3.3 source? Is this more of the AVR could be a CMOS variant that accepts a wider range, or that it is such a chip, or that it needs a different voltage to run vs. program i.e. it could run at 3.3 but needs 5 to program?

Sorry for all the questions (try to remember I'm relatively new to PIC stuff, and know almost nothing about AVRs), and thanks again for all the help.

[ginge]

The wiki pages are fairly unclear about this stuff, true. I will try and clarify that. The differences between programming v1 and v2 are down to the chip used. The v1 chip was based around the AVR attiny range which required high voltage programming once soldered in. The v2 atmega168 has more pins and allows for standard low voltage programming.

The programming with 5/7 volts is also a little confusing I guess. The OpenServo runs from a >6v source for operation, but when programming you need to break the link JP1 or solder in a diode. This protects the onboard regulator from exploding when programming with a low voltage source. Flashing the initial firmware requires 5v externally on pin 5, and no voltage on pin 2 (VBatt). This way you only power the AVR and not the H-Bridge while flashing, helping to stop the motor doing odd things. To clarify... program at 5v on pin 5 and run from 7v at pin 2.

[tillin9]

Thanks for making things clear. Okay, this now seems fairly straightforward. I see the big JP1 link that needs to be broken for flashing, and I can see why if the motor might do something odd when programming, (like trying to force past the physical stop and smashing up the gears) so we might not want to provide it power then.

I also see why 3.3V operation might not work with the standard FETs.

This isn't the biggest issue as I'm going to need something better for my main uses anyway. I plan to do OpenSero conversions on Hitec 805s and 5955s (The 805s will be first since the 5955s do have limited HMI already). Both of these servos can draw over 2A stock and I think might only be limited by their electronics. Yes, I saw the Hitec 5995 thread. I also saw somewhere the IRF7389 used in a 2 FET stack for up to 14A worth of current, and that should work with OpenServo with the possible need of adjusting some constants in the firmware. Sadly even this might not be enough current since I found dirt cheap $2 airplane propeller motors which will fit my 805s and have 17A stall with a max of 2400 oz/in torque (theoretically when using the 805 gear train, I'm sure the plastic gears will smash way before this). The 5955 already has a very good heatsink built-in, and the 805 is mostly empty space and can be modified quite a bit. However...even if I don't get any torque increase from my servos at all, the ability to daisy chain cables, current sense obstacles, and remove the need for a dedicated analogue servo controller (for the 805s), is more than worth the conversion.

So what was Jay talking about when he said we need 7V for programming?

Also if the micro will run off of 3.3V fine, why not leave a low-drop diode in there permanently? I know its a tad wasteful, but would make things easier. Finally, besides power saving, does running at 3.3V give any benefit?

Sorry for all the questions. I swear this will be the end, at least until I get some OpenServo hardware and test results.

[mpthompson]

[ginge]

I am glad you understand what I was trying to say. I got a little confused myself and one point

[tillin9]

Hey thanks for everything. I think I can now try to build some OpenServos boards myself if things work out with Jay's boards. Yea, as you can see low power is not where I'm going with this. On the Lynx forum linuxguy (same one as here) has had no end of I2C communcation issues at 5V (not with OpenServos, with port extenders) so there is absolutely no reason for me to even think about running at 3.3V if it means introducing any more noise issues than will be there already, the power the micro uses is insignificant compared to the motors I plan on running.

In fact, since the higher voltage, the better, I might just forget about any diode and connect/ disconnect the jumper since even the 0.3V drop might exacerbate my problems (large bot, lots of current going everywhich way). Again, this is stuff I really need to test with some hardware since there are far too many variables to dicuss it abstractly and maybe I won't have any issues. Also hopefully I won't need to reflash without a bootloader very often.

If needed I can run some extra ground wires, try different filtering and terminating tricks, implement shielding schemes, etc. and put to use all the other EE knowledge I learned in class for keeping lines clean while wishing they taught me how to program micros.

Thanks again.

[linuxguy]

[tillin9]

Hey, I thought if I started posting around here I'd run into you.

Nice to know you got your I2C issues under control. I never has any issues, but then the only time I really used I2C was bit-banged access to some EEPROMs with my old Basic Stamp. There were only two devices, and the 'bus' length was under 1"". Saldy my more or less retired BOE-bots and their I2C code will be brought back to life, if only to test my new OpenServos. I know some of my PICs can do real hardware I2C or at least bit-bang it a lot faster, but my BS2 code is well documented (I didn't write it, just copied a stock implementation) and well tested (lots of people copied it too) so its ideal for testing as opposed to trying something I've never done before with my PICs. I also like the idea of using the BOE (a proven test platform) as opposed to some board I cooked up, since I'm prone to user error too. Of course since I doubt any of my BS2s will be providing the brains for any new bots, I'd best figure out how to get things working on the PIC in short order. To that end I've been spending a lot of time on the PikLab wiki, they have some udev stuff I think I can use to get my PicKit2 working with the IDE... Ah, so many things... so hard to stay focused.

Truth be told, I never modified a servo for continuous rotation myself. I also never had much luck with the Parallax and other brand continuous rotation servos in my BOEs, when I post pics of my I2C setup you'll see I eventually just gave up on any speed control from the 'servo' nature of the gear motor (the EEPROMs were to store ever more detailed calibration look-up tables for them as per in some Parallax AppNotes) and just installed real encoders. Anyway...

Some places make it seem as simple as measuring the midway resistance of the pot used for the servo, then finding two matching resistors, making a Y configuration and replacing the pot with the Y to trick the servo into thinking its in the midway point all the time. Other sites (generally servo specific and not the 805) have much more complex plans involving changing many components. ServoCity does offer a premodded version for $20 more, which you might want to check that out if only to buy one and report back how they did it. Though $20 to see a poorly implemented Y would make me kinda mad.

A much better idea IMHO is to checkout the RS-385 gearhead motors from BaneBots. They're originally for model airplanes, have 17A stall, and at priced $40 a piece. Using a suitable motor controller like one of those from Lynx would work fine for beefing up your rover. While I guess you could use OpenServo boards to control the gearheads like a continuous rotational servo, and the people here would be much more capable of answering whether or not this was possible and a good idea, to me it sounds like just using the wrong tool for the job. What you want is just PWM control of a motor which is exactly what a motor controller does.

By the way an RS-385 (no geartrain) for $2.05 is one of the first motors on my list to attempt to replace the stock 805 motor with if I don't get much improvement with just better electronics. I have some other low cost propeller motors I want to try too unless I start smashing gears or running into current limits with the modded FETs. Anyway...I won't count my chickens before they hatch. Suffice to say, I'm almost giddy at the prospects for a properly modded 805.

[poor-robot]

I'm curious about the whole topic of programming with power applied to the H-bridge. With the pull-down resistors (although you may want to make them 10K instead of 100K) the H-bridge should be fine - the outputs will be tri-stated during programming and the motor won't move. This way you could just provide power to the servo as you would normally, and not hook up the +5V line to the STK500. No more regulator issue.

Did someone try this and encounter issues? As long as the SPI/Reset pins aren't used to control the bridge you should be fine.

I think you've arrived at this conclusion already, but I would steer you away from the TQFP-to-DIP for programming use. If you want to get it for something else, it may be occasionally useful for programming. Realistically, you won't want to be removing and replacing the AVR every time you need to reflash the bootloader. The PCB will be destroyed after a few cycles of soldering and desoldering the chip.

If you want to buy an STK-200 I would pick one up from SFE:
http://www.sparkfun.com/commerce/product_info.php?products_id=13
(currently out of stock - $11.95) or here:
https://admtn.ucsadm.oregonstate.edu/ustores/web/product_detail.jsp?PRODUCTID=176
I went to school at OSU, but that is my only association. They're only $9.95! You could hardly prototype one for that, and these are assembled and tested. I have used them for the past few years with no problems, just keep the cable length short.

[tillin9]

As far as the H-bridge, I'm not sure I'm fully qualified to comment since I don't know what exactly AVR pins do durring programming. However, pulldown resistors on tristate pins seems like a no movement situation to me.

Thanks for the links. I may end up buying one, but there's some value in building one. I design in Eagle, test on breadboard, then send it out. Things like patchpcb make this too easy since rarely do I need more than a handful of anything, and most PCB stuff is small since if its DIP I can use perfboard. I may end up using such a service for OpenServo, but I've never really tried to do something like toner transfer and would like to try to reduce costs this way. I have access at school to lots (virtually unlimited) 1 and 2 oz copper boards as we used to have a much better EE slant in the physics department where I work (I'm a grad student). I actually already have the feric chloride from a magnetism demo, I made some homebrew ferromagnetic liquid durring class and used only about 50 mL of brand new 1L bottle. There is also a mini-drill press in the machine shop downstairs as students used to make their own PCBs all the time and I might even luck out and get to send my boards to the main CNC for drilling. Anyway... the point of this rant is that I need something simple to test my home etching chops. A JTAG-like AVR programmer is just the ticket since its simple, but something I need, possibly more than one of.

Assuming this is relatively easy I can fit 30 or so OpenServo layouts on a single medium sized board. A few etches and even if some of them fail for whatever reason, I just saved over a thousand on PCB costs since the materials are all free. $2.5 a square inch becomes alot on a few 15""x10"" boards. Since this is going inside the servo, it doesn't even have to look that pretty so long as it gets the job done.

As far as the TQFP adapter, I certainly won't desolder the chip then program and put it back, that's silly. I was going to use it to program and test the micro before soldering. In a similar way I hope to build some kind of test jig for the PCBs (batchpcbs aren't tested either), this way hopefully I can isolate my problems to bad board, bad chip, bad flash, or bad solder (I'm probably going to use an entry-level reflow station here, so I expect trouble). Once I get a working board, JP1 can be connected/ disconnected easily enough (and depending upon my I2C issues, maybe I can just leave a diode in there), and I expect all future flashing to be done via bootloader on onboard. Again I hope I don't have to do this too much.

[robotjay]

Tillin', you should be able to use either of Barry's parallel port programming interfaces, although I personally suggest using the buffered version. I used the unbuffered version with my breadboard and eventually fried my parallel port. There's no real need to buy an entire Kanda board, although having an AVR development board will be useful to you if you plan on developing your own AVR application code. If you plan on flashing your own boards, you should definitely take the time to etch a proper board or buy an off-the-shelf ISP dongle. I tried using my bread board and had jumper wires here, there, and everywhere, which makes any problems that arise very hard to diagnose. I eventually broke down and etched my own board at home (a simple process) and solved most of my programming issues.

Regarding the Jumper at J1, and 3.3v regulators, with your order (and all subsequent orders) I have begun including the Diodes at J1 as opposed to just a solder bridge. Although it is entirely possible to just break the solder bridge when re-bootstrapping, after you start flashing more than 2 boards at a time, it becomes a needless hassle. The diodes now work for their intended purpose, and flashing is now only a 2 step process, instead of 3.

The boards you ordered also feature a 3.3v regulator. You will have to be the Guinea pig for our community, and I hope that you will continue to report your results to this forum. I made the switch after Barry stated that the OS still performs as usual while using 3.3v. I verified this through my own testing, and everything still seems to perform just as it did with 5v. I am confident that 3.3v will work without any noticeable difference, and it will allow smaller battery packs/PSUs to program and control the boards. IF your boards don't function properly, and you feel that this is the result of the 3.3v regulators, then you are welcome to ship the boards back to me, and I will replace them with a 5v regulator (or if you want to do it yourself, I will send you some 5v regulators.) Either way, I think this transition from 5v to 3.3v is fine. If anything, it makes programming the boards easier because I don't have to connect 2 separate battery packs to my boards just for programming. Your boards shipped today, and you should have them by the end of the week. Let us know how they work out.

-Jay
_________________
"Nothing is fool-proof; For we fools are ingenious and will find a way."