New Controller Board

[linuxguy]

@KM6VV

Hi Dale, all,

I can’t keep up with this thread!

I know… You don’t read for a day or so and look what we do! We definitely have not been idle.

@KM6VV

I like to run FAST crystals. Helps for baud rate also.

So do I. Since USB needs 48 Mhz anyway, I figured we might as well try running everything as fast as possible.

@KM6VV

I could have used the high-res A/D for a HAM radio project! I like the EEPROMS, yeah, all different sizes.

Cool. So you can see how this board could be used in many different projects. It doesn’t just have to be just robotics board, even though most of the connections are oriented for that.

@KM6VV

Good show! If Pete was using the hardware I2C, then it shouldn’t be too much of a problem. Humm, I do have both types of EEPROM, I could use that to test out the I2C code.

Thanks. I am anxious to get those five 20 Mhz crystals I ordered. I can’t really move forward with the software end of this until I can wire the clock circuits to each chip. So, I have time to work on schematics and learn more about Eagle. I also want to tinker with other features of the 4550, like the ADCs, reading a PING sensor, interrupts, etc.

@KM6VV

That long a wait? Yes, In good code, you shouldn’t have to do a re-write in order to change a few parameters.

Yes, but it works out good for me anyway, because I will have more money at the first of the month. I also want to get a decent little DMM, and Norvac has models from $9.95 on up. I think the $30.00 model should work well for me.

@KM6VV

OK, more current, and sometimes you want the RFI kept to a minimum. I just test out the equations at the different clock frequencies, then comment out the #defines for the other frequencies.

I think the 20 MHz and 40 Mhz speeds should work fine, but 40 Mhz is not compatible with the USB. I am more concerned about the full 48 Mhz speed because the math doesn’t work out exact. It will probably be awhile before I can test that speed though.

I took a peek at Pete’s dsPIC code, and he has already allowed for slow and fastest speeds. It doesn’t look like there are any needed changes there to go faster, but I have not looked real close yet. I’ve only looked at the main line so far. I want to stay in 4620/4550 mode for now.

@KM6VV

I hope so. I’ve ordered some 28 pin dsPICs, although I probably should have ordered 40 pin parts. No matter, easier to mill up a board!

I am planning to build a stock board from Pete’s stuff, so I can compare operation with what we are doing. I also want to see how Pete’s board behaves at faster speeds - 20 Mhz and 40 Mhz.

It’s not so important to me that we use a 40 pin dsPIC if we have the ability to stack on additional boards. I’ve been wandering around Spark Fun’s site, and they have some nifty displays it would be nice to add as a stacked board but this is one that should be a top board. Do you think stacking connectors could work for both sides of our board (socket on top, pins on the bottom)?? I know New Micros does this with their Pluga series, so maybe it can work for us also. There is also the issue of the pin headers for sensors and servos if there are boards stacked on top of our main MCU board.

8-Dale

[km6vv]

Hi Dale, all,

@robodude666

Personally, if I were you, I would not use the UBW as a backbone of your dualPIC system. You CAN, and I recommend it, look through the user.c like KM6VV mentioned and look at how Brian does things. Some VERY nice stuff. I will be borrowing Brian’s command reading system

@linuxguy

OK, UBW is out then. I will definitely look into user.c though. It sounds interesting.

Don’t quite follow that recommendation. If you want USB, then use the “framework” that Microchip provided; LOOK at and study user.c JUST to get the hang of interfacing to the framework.

@robodude666

But the project has a ton of crap that you simply don’t need for your project. The UBW project is mostly designed so you can control/read the i/o via a GUI on your system. You don’t need that, at all.

Yeah, exactly right. You really don’t want the stuff in user.c, but take a while and see how it works.

@linuxguy

I agree. We don’t need any excess baggage. I want as much program memory available as possible for robot stuff.

I’m told there is a “bigger” replacement chip, 30F possibly, but I haven’t worked on that yet. Different family, etc.

@robodude666

I would recommend you start from a blank project. Get that 20MHz crystal and set the proper config bits so it runs at 10MHz like the original project.

Yes, get it working first as-is, then modify it to suit your needs.

@linuxguy

This is what I have done. I created a new project for my i2cleds program. Then I added a few of Pete’s files for the i2c and sci stuff. I have my circuit all wired up and ready to go when I get the crystals. In fact, I have a 4550, dsPIC4011, and MCP23017 wired up.

Let’s hear of the results!

@robodude666

Rewrite whatever pin definitions you need and see if the program runs like it should. If it does, increase to 20, then to 40, and then to 48MHz.

@linuxguy

I plan to start out at 10 Mhz, then move up to 20 Mhz, then 40 Mhz, and finally 48 Mhz with Pete’s original code before moving on to work with the USB stuff. This is important in case something starts failing at a higher speed, I will have a better idea where when it starts failing and can work to deal with that before moving on.

calculations for timers and baud rate divisors can fall out.

@robodude666

Once that all works, pop on the MicroChip (DEFAULT, regular stuff, NOT UBW!) USB Bootloader. As a basis for the firmware, use either the COM example (I’d suggest it. You can print to terminal for debugging <— programmer’s best friend.), or you can use a plain firmware without HID or COM or MMS enabled.

Do we really want the download capability? I have it “conditionally” in the code, but I’d much rather just ICD2 the code over. Saves a little room as well.

@robodude666

Then slowly rewrite the entire code to fit into the new firmware. This part will take a bit of time. In fact, a lot of time.Once the USB Boot loader is on board, some of the vector address change. (i’ll help you out with that! I spent a week getting it to work so I know exactly what you’ll need to do to get it to work!)

@linuxguy

Is it just the vector addresses that change, or are there more major changes that will have to be made? We don’t really have to use ALL of Pete’s code, just the important stuff for sci, i2c, etc if that will make this easier. I already have the sci and i2c stuff brought into my i2cleds project.

Converting the interrupt and reset vectors from Microchip over to Hi-tech was a real pain. You’ve got several interrupts to add to the interrupt chain. Do them one at a time and check them out!

@robodude666

You may actually have to modify a bit of the original code. If the interrupts take up tooo much time, then USB won’t get enough time to do its stuff so windows will return errors and scream that the USB device has failed. Not a good thing =P

Yes, BAD! Also, the 'bot code won’t get enough execution time. Keep code in interrupts to a minimum… Set flags, service later.

The Atom code has some long running routines making it difficult to make it behave. It’s was ALL in one main routine, I’ve split it up considerably, but I still have the long command xmit sequences to deal with.

@linuxguy

I will keep this in mind when I get to a point I can start working with the USB stuff. Assuming for now that everything will work at 48 MHz, interrupts should not take too long considering the original code is designed for 10 Mhz.

Don’t forget you’re adding more interrupts!

@robodude666

For the most part, it won’t be very hard. I’ve used the 4550 for a few months before so I can help ya out if you have any questions. I’m online almost 24/7 =P

@linuxguy

You are the reason I decided to try and go for the 4550 instead of the 4620. I know the 4550 has a bit less program memory, but I think USB is a very desirable upgrade to Pete’s design. I am going to create the MCU schematic in Eagle using the 4550 instead of the 4620, which I don’t have a symbol for right now.

Your help with this USB stuff is appreciated, Grasshoppah.

8-Dale

Alan KM6VV

[km6vv]

Hi ?,

Now that was a little while back. It’s running, and doing what I want. Good to get the code ported over to the Hi-Tech compiler! I don’t remember what you were posting about, and don’t remember 66666

The 4455 on as small development board would be good.

I bought the $20 UBW board, and ported over to Hi-tech. I also ported (back!) over to the PICDEM. So I’m ready when I get a work work project for USB (device). I can use the standard Microchip boot loader (which I prefer).

Alan KM6VV

@robodude666

Awww :oops: Your welcome!

I was searching around the SF forums earlier today and guess who I saw posting? =P Hows that USB Bit Wacker - 18F2550 PTH Kit coming for your KM6VV? I am thinking of putting together the 44pin TQFP 18F4455 version of the UBW as a small development platform for future projects. Not to mention its a good chance to learn SMD soldering! But I will use the regular microchip bootloader rather than UBW.

Oh, one thing I forgot to mention. If you are interested in the UBW project and want to test it out for the hell of it, then go get SparkFun UBW schematic off of the SF website. Their version uses the 20MHz crystal. It is almost identical design, actually it IS, to the microchip bootloader. They just have UBW SF bootloader on board which gives i/o and other functions.

-robudude666

[km6vv]

Hi ?,

I always like to sign my postings. I’m afraid I don’t remember. KM6VV is my Ham Radio call, I use it on the ham lists I’m on, well, all the lists I’m on.

Alan KM6VV

@robodude666

@robodude666

I was searching around the SF forums earlier today and guess who I saw posting? =P Hows that USB Bit Wacker - 18F2550 PTH Kit coming for your KM6VV

?

Does that give you a hint? :lol:

[robodude666]

@KM6VV

Don’t quite follow that recommendation. If you want USB, then use the “framework” that Microchip provided; LOOK at and study user.c JUST to get the hang of interfacing to the framework.

Well, yes. Thats what I recommended. Use microchip’s USB “framework” Don’t use UBW because it has a ton of code and things that linuxguy simply does not need and will not use. He should look at the user.c file from the project to learn more about the USB functionality, but he shouldn’t use the project as the start for his project.

-robodude666

[linuxguy]

@KM6VV

Don’t quite follow that recommendation. If you want USB, then use the “framework” that Microchip provided; LOOK at and study user.c JUST to get the hang of interfacing to the framework.

The only reason I got the UBW source is to look at it. We don’t plan to actually use it, in favor of the stock Microchip code.

@KM6VV

Let’s hear of the results!

I can blink 9 LEDs (8 in sequence, one heartbeat each cycle) using the 4550 so far. I am gradually getting into more complex stuff. There is still quite a bit I can work with using the 8 Mhz internal oscillator. I am going to see if I can get the I2C stuff working at 8 Mhz, so I can move on to using the MCP23017. I still have to move my ICSP connections so I can reach all both the 4550 and dsPIC4011 and get 8 more LEDs wired up for the MCP23017 output. I’ve run out of low value (220, 330, and 470 ohm) resistors so will be getting more when I get my crystals and DMM.

@linuxguy

I plan to start out at 10 Mhz, then move up to 20 Mhz, then 40 Mhz, and finally 48 Mhz with Pete’s original code before moving on to work with the USB stuff. This is important in case something starts failing at a higher speed, I will have a better idea where when it starts failing and can work to deal with that before moving on.

@KM6VV

Do we really want the download capability? I have it “conditionally” in the code, but I’d much rather just ICD2 the code over. Saves a little room as well.

We won’t necessarily use the USB bootloader for our stuff. However, I would like to have the option and make sure it works for other applications of our board. Not everyone will want or need to have the dsPIC onboard. I might even want to use the bootloader in some applications. I want to have our board be as flexible as possible. I definitely want ICSP to both chips.

@KM6VV

Converting the interrupt and reset vectors from Microchip over to Hi-tech was a real pain. You’ve got several interrupts to add to the interrupt chain. Do them one at a time and check them out!

Great advice. When I am working on somebody else’s code, it’s way better to just make one change at a time in case something else gets upset. That way, it is much easier to trace what caused the problem. I learned that lesson doing maintenance programming for 4 years.

The Atom code has some long running routines making it difficult to make it behave. It’s was ALL in one main routine, I’ve split it up considerably, but I still have the long command xmit sequences to deal with.

@KM6VV

Don’t forget you’re adding more interrupts!

So far, it looks like Pete’s code allows for faster speeds, but I am still checking into that.

8-Dale

[linuxguy]

I am digging deeper into Pete’s I2C code now. I see one place where I want to make a change to one of the routines. It’s

void i2c_start_packet(utiny device, utiny num_bytes)

This routine always sends a checksum of the data it sends, which is good in a lot of cases, but not when sending to another I2C enabled chip such as the MCP23017. I thought about creating a slightly different version of this routine with a different name, but one simple change would make it usable in all cases - adding a bool flag that says whether calculate and send a checksum or not.

I want to modify the routine like:

void i2c_start_packet(utiny device, utiny num_bytes, bool sendchecksum)

The code would change from:

for (kk=0; kk<num_bytes; kk++) { send_i2c_byte( i2c_buffer[kk] ); checksum += i2c_buffer[kk]; } // Send the checksum. send_i2c_byte( (utiny)(256 - checksum) );
To:

[code] for (kk=0; kk<num_bytes; kk++)
{
send_i2c_byte( i2c_buffer[kk] );

   if (sendchecksum)
       checksum += i2c_buffer[kk];
}
// Send the checksum.
if (sendchecksum)
    send_i2c_byte( (utiny)(256 - checksum) );

[/code]
If sendchecksum is TRUE, the checksum will be calculated and sent, but not of it is FALSE. This should only require changing all the calls to the i2c_start_packet() routine throughout Pete’s code with sendchecksum = TRUE. This change should make the I2C code usable for any purpose.

8-Dale

[robodude666]

shouldn’t it technically be something like

void i2c_start_packet(utiny device, utiny num_bytes, bool sendchecksum = true)

So you don’t have to put it all the time. Or make it false by default, depending on what your more likely to use. This way you also don’t have to modify all of the original code.

[linuxguy]

@robodude666

shouldn’t it technically be something like

void i2c_start_packet(utiny device, utiny num_bytes, bool sendchecksum = true)

So you don’t have to put it all the time. Or make it false by default, depending on what your more likely to use.

This is true, but I prefer to explicitly specify all parameters used in calls. It’s less likely for me to forget what is being done this way, and I think it makes code easier to understand too.

8-Dale

[km6vv]

Hi Dale,

Why don’t you want to send a checksum? Another byte, true. Won’t the MCP23017 chips handle it?

I haven’t had time to do something with a bit of Pete’s code. I’ve been busy designing a Tibia for my 'Bot. OK, it looks very much like the aluminum Lynxmotion leg! I am doing a little different on the tip of the foot, but that’s about all. Next is to mill it out of 1/8" aluminum. What I’d really like to work out is a 2nd bearing support (opposing pivot) for the servo. I could just hog out a little bridge, or bend up a strap I suppose. I guess I’ll check out the hinge that LM sells.

Alan KM6VV

[linuxguy]

@KM6VV

Why don’t you want to send a checksum? Another byte, true. Won’t the MCP23017 chips handle it?

I don’t really know what the MCP23017 would do with an extra byte sent. I am trying to transition from using the Atom chips to only using PICs for now.

@KM6VV

I haven’t had time to do something with a bit of Pete’s code.

I am to the point where I can actually start exercising some of Pete’s code, the I2C stuff specifically. I have reduced my test circuit to just the 4550 and one MCP23017. I created an mcp23017.h file with the same register definitions I was using for the Atom PRO code. So far I have not gotten anything to work, and am not sure Pete’s code will work at 8 MHz. I get a brief instance when both SDA and SCL are high. I think this is during what is supposed to be initialization. Then the circuit goes into normal operation and just the heartbeat blinks (directly controlled by the 4550).

I have the initialization set to what I believe is the correct sequence. One thing I noticed about Pete’s code is he does not seem to be using registers for his devices, or just one register (0x00) so does not set the register address before addressing his devices. At least that is what it looks like to me. I need to write to specific addresses, so might not be able to use Pete’s code without modifying it. I really don’t want to mess with his low level I2C stuff.

8-Dale

[km6vv]

Hi Dale,

I’m afraid I’m not up yet on Pete’s code. Are you saying he’s not doing the addressing for the I2C? Well need that.

By “registers”, do you mean the setup registers for I2C? They are bound to be different for a PIC then an H8 chip.

Check out this Japanese 'bot video at about 1:18:

youtube.com/watch?v=nHvaqpcGI1c&mode=related&search

I like the RED 'Bot. Hex body. Must have an extra segment in the legs, and an extra “rotate” joint, I think. Notice the way the leg is turned around to allow it to behave like an arm!

Alan KM6VV

@linuxguy

I don’t really know what the MCP23017 would do with an extra byte sent. I am trying to transition from using the Atom chips to only using PICs for now.

I am to the point where I can actually start exercising some of Pete’s code, the I2C stuff specifically. I have reduced my test circuit to just the 4550 and one MCP23017. I created an mcp23017.h file with the same register definitions I was using for the Atom PRO code. So far I have not gotten anything to work, and am not sure Pete’s code will work at 8 MHz. I get a brief instance when both SDA and SCL are high. I think this is during what is supposed to be initialization. Then the circuit goes into normal operation and just the heartbeat blinks (directly controlled by the 4550).

I have the initialization set to what I believe is the correct sequence. One thing I noticed about Pete’s code is he does not seem to be using registers for his devices, or just one register (0x00) so does not set the register address before addressing his devices. At least that is what it looks like to me. I need to write to specific addresses, so might not be able to use Pete’s code without modifying it. I really don’t want to mess with his low level I2C stuff.

8-Dale

[linuxguy]

@KM6VV

I’m afraid I’m not up yet on Pete’s code. Are you saying he’s not doing the addressing for the I2C? Well need that.

By “registers”, do you mean the setup registers for I2C? They are bound to be different for a PIC then an H8 chip.

I mean I2C device registers. The MCP23017 has a set of registers that control how it works and for data. I don’t see where Pete’s code uses device registers at all. He uses device addresses, of course. We will need to be able to read and write device registers for various devices. I have been looking for some other C example code for I2C, but have only found assembly examples so far, which don’t help me. I am going to peruse the Open Servo code and see if I can gain some insight. I may pull the entire current code tree.

@KM6VV

Check out this Japanese 'bot video at about 1:18:

youtube.com/watch?v=nHvaqpcGI1c&mode=related&search

I like the RED 'Bot. Hex body. Must have an extra segment in the legs, and an extra “rotate” joint, I think. Notice the way the leg is turned around to allow it to behave like an arm!

I like those hexes too! I am sure they have more than just 3DOF in those legs. I have had ideas of doing similar things, including putting BiPod legs (4DOF) on a hex. I love the range of motion those hexes have!

8-Dale

[linuxguy]

Have you seen this Diolan USB-I2C/SPI/GPIO Interface Adapter?

This looks like something worth getting, even if just to tinker with I2C and SPI from a regular PC.

8-Dale

[kurte]

@linuxguy

[code] for (kk=0; kk<num_bytes; kk++)
{
send_i2c_byte( i2c_buffer[kk] );

   if (sendchecksum)
       checksum += i2c_buffer[kk];
}
// Send the checksum.
if (sendchecksum)
    send_i2c_byte( (utiny)(256 - checksum) );

[/code]

8-Dale

Not that it maters much here, but inside your loop I would probably remove the if(sendchecksum) from the computation of the checksum. The code will probably be smaller and faster in both cases as the checksum may be computed as simply as adding two registers…

You guys have sure been busy!

It will be interesting to see what you end up with

Kurt

[robodude666]

@KM6VV

youtube.com/watch?v=nHvaqpcGI1c&mode=related&search

I like the RED 'Bot. Hex body. Must have an extra segment in the legs, and an extra “rotate” joint, I think. Notice the way the leg is turned around to allow it to behave like an arm!

I liked the red and blue hexes also. They are very cool. From what it seemed though, they were going down the poll slop thing pre-programmed as they didn’t search for the places to step. They “knew” where to go already. I like when it went to pickup the toy also. At first, I thought it was going to attack it. But then it picked it up and it was like “awwwwww”. Oh, and walking on the chicken mesh was pretty cool. Would of been cooler if the legs were magnets rather than looping onto the mesh.

linuxguy, I think your thread should win #1 award for being most active this weekend!

-robodude666

[km6vv]

Hi Dale, JIM, & ?,

@linuxguy

I mean I2C device registers. The MCP23017 has a set of registers that control how it works and for data. I don’t see where Pete’s code uses device registers at all. He uses device addresses, of course. We will need to be able to read and write device registers for various devices. I have been looking for some other C example code for I2C, but have only found assembly examples so far, which don’t help me. I am going to peruse the Open Servo code and see if I can gain some insight. I may pull the entire current code tree.

You have to configure the 23017? How do you write to it? I’ll have to take another look at the data sheet I guess. I’m a little busy on other parts.

@KM6VV

Check out this Japanese 'bot video at about 1:18:
youtube.com/watch?v=nHvaqpcGI1c&mode=related&search

I like the RED 'Bot. Hex body. Must have an extra segment in the legs, and an extra “rotate” joint, I think. Notice the way the leg is turned around to allow it to behave like an arm!

@linuxguy

I like those hexes too! I am sure they have more than just 3DOF in those legs. I have had ideas of doing similar things, including putting BiPod legs (4DOF) on a hex. I love the range of motion those hexes have!

8-Dale

Looked like one extra segment (bend joint), and an extra rotate joint. IN ALL of the LEGS! I’m wondering if we could add these JUST to a pair of legs. Arm-legs VERY useful for picking up things. I’ve been considering making an octapod, and my son after seeing my friend’s 'bot and my beginnings (2 legs assembled so far), is also interested in 8 legs. SO, what if the two additional legs were a little more articulated? I wonder if they would be compliant enough to “walk with the other legs”? Maybe the other, less articulated leg tibias… that’s it, the new arm-legs would have shorter tibias, and thus have a similar reach! And/or maybe use a longer ‘C’ bracket to lengthen the existing legs; giving more room for the two “enhanced” legs. BiPod legs (4DOF)? There’s an idea. I haven’t really studied them. Just another joint? How do we make up a rotate joint without it being too bulky?

JIM, ARE YOU LISTENING? Thoughts?? Has anyone done weight/torque calculations for various legs? If adding two more legs adds X amount of weight, then the weight/leg goes down in relation to the overhead of uP/battery/payload. I intend to weigh the 'bot, and hopefully calculate/determine the torque (thrust?) per leg. Any MEs out there?

@robodude666

I liked the red and blue hexes also. They are very cool. From what it seemed though, they were going down the poll slop thing pre-programmed as they didn’t search for the places to step. They “knew” where to go already. I like when it went to pickup the toy also. At first, I thought it was going to attack it. But then it picked it up and it was like “awwwwww”. Oh, and walking on the chicken mesh was pretty cool. Would of been cooler if the legs were magnets rather than looping onto the mesh.

linuxguy, I think your thread should win #1 award for being most active this weekend!

-robodude666

Yeah, I liked the pair of dancing 'bots too! I got the same impression seeing the 'bot walk down the pilings; that it was pre-programmed rather then “feeling it’s way”.

Maybe that WAS an attack! The upside-down stint was interesting, but probably not realistic. Think of the size of magnets that would require!

@linuxguy

Have you seen this Diolan USB-I2C/SPI/GPIO Interface Adapter?

That could be useful! Looked like it might use an ARM7; AT91SAM7X from the pin labeling.

Alan KM6VV

[robodude666]

@KM6VV

Hi Dale, JIM, & ?,

Yeah, I liked the pair of dancing 'bots too! I got the same impression seeing the 'bot walk down the pilings; that it was pre-programmed rather then “feeling it’s way”.

Maybe that WAS an attack! The upside-down stint was interesting, but probably not realistic. Think of the size of magnets that would require!

Alan KM6VV

Why do you seem to refer to me as “?” ? I have a name you know!

-robodude666

[robotdude]

@robodude666

Why do you seem to refer to me as “?” ? I have a name you know!

-robodude666

Yeah! He is a name, not a num… um… well, nevermind.

[robotdude]

@KM6VV

JIM, ARE YOU LISTENING? Thoughts?? Has anyone done weight/torque calculations for various legs? If adding two more legs adds X amount of weight, then the weight/leg goes down in relation to the overhead of uP/battery/payload. I intend to weigh the 'bot, and hopefully calculate/determine the torque (thrust?) per leg. Any MEs out there?

There are far too many posts in this thread for me to keep up. I haven’t done anything with Octopods, or the math behind calculating the torques required. If you are thinking of 7 down and 1 up, or 6 down and 2 up, not 4 down and 4 up, then it may be ok. I am not sure.