Hi Dale,
So are you using external power on the ICD2 now? I believe you can read the VDD voltage via an ICD2.
I’ve made a little more progress with the '4620 'Bot code, it’s running some of the minor functions of the Atom code on my friend’s 'Bot. I’m going to have to reverse 1/2 of the knee joint directions, as his 'bot does not have “three left and three right” legs. And I’m sure there are some other “flips” I’ll need to contend with.
Alan KM6VV
Yes, I have external power to my breadboard and the ICD2 is powered from the circuit now. I have 4.84V for Vdd according to MPLAB and everything passes the self-test.
No working I2C yet.
Very cool! So you have some of Pete’s code running on your friend’s bot now?
Does this bot walk funny?
8-Dale
Hi Dale,
Power up! Continue testing/developing! If you have a comm port implemented, then you you could use one or more A/D channels for meters and report the values on the PC. If you had an LCD, then you’d be able to display values there.
None of Pete’s code in yet, although as we’ve discussed, I’m interested in the I2C. I did find out that I2C shares pins and internal serial hardware (MSSP).
For my 'Bot (and my friend’s) I’m working on a piece of code inspired/derived from sample code for the BASIC Atom. Kudos to Laurent Gay!
He probably would! I haven’t put him on the ground yet. I want to observe leg motion a little more first.
I figured out how to reverse the Left side HipV and Knee servo positions. Acutally, un-reverse them. That’s what the “3000 -” term does in the tripod update code.
Alan KM6VV
I am still working on the I2C stuff, trying to figure out what I am not doing, not doing right, or need to do that I am not doing. 
I am trying to get my I2C ducks in proper order. 
I’m using the Microchip I2C libraries now and seeking help on the Microchip forums.
8-Dale
Hi Dale,
I’m getting slowed down by seemingly seeing several problems at once in the 'Bot CPU port. That’s the trouble trying to get an INTIRE program to run at once. I’m not totally satisfied with the PS2 inputs; and not sure how often they should be requested. I might have to limit my requests to .14 seconds; according to one comment (the legs DO look a little fast). The step rate is probably tied to this rate. And I started getting trash on the LCD display if I use PS2 (not with comm.) for joystick command inputs. Ouch!
I’m using the little LCD to display RUN/STANDBY status, Locked legs, and to flash the commands being received. Handy! The Renisys (?) also has a little LCD, I found it in the bottom of the box!
Although I think I’ve worked out the differences between CH3-R and my friend’s 'Bot (servo orientations), the movements don’t look the same for Attack and Fly. I think I need a way to “step through” these and other “canned cycles” of operation to get them worked out. Walking is of course a separate function, run by gait generator. Corrections for different servo orientations SHOULD all go into the generation of the full tripod message, but maybe it’s not that simple!
Those problems, and between the 'Bot battery and the PS2 battery going weak on me (that makes for poor operation), I’m struggling!
The forum should be a good place to ask for your I2C project. You are trying to run the I/O chip, maybe try just implementing Peter’s PIC to PIC communications first, and observe that?
What more do you know about I2C? Does it only send when there is data, or do you have it set up on a periodic interrupt? For SPI, in a controller I just did, it was reasonable to have it run and update a set of relays at a periodic rate. Buttons and trigger inputs were thus were also read. I think I would set up a periodic interrupt, and send a fixed message. Then one would be able to observe the “traffic” on the interface lines. Can you possibly BORROW a 'Scope? If I wasn’t still hung up on my project, I’d try a simple I2C interface to say, an EEPROM. There should be some good examples of communications with EEPROMS available. If the 4620 were the master, that might be OK too.
A “logic probe” is naturally cheaper then a 'scope. There are simple circuits for logic probes on the net. Basically, they often trigger a F/F; stretching received pulses out long enough to flash an LED. I’ve got LEDs on my board showing commands received from the “joystick” (PS2 or PC); gait steps supposedly being taken, and a heartbeat. With the complicated interface used (multiple use of left joystick and four ‘L’ buttons, commands that only work in certain modes), I’m tempted to commit LEDs to some of these states. Hard to keep track of what’s going on! But part of that could be my shaky battery situation. Stop troubleshooting, recharge the battery!
Alan KM6VV
P.S. too much “Other 'Bot” comments for this thread?
I think I have made a breakthrough in my understanding of Pete’s i2c routines. 
He has four main routines.
i2c_start_packet
i2c_read_bytes
i2c_finish_packet
i2c_packet (calls the above 3 in order)
Well, I do not need the i2c_read_bytes call when communicating with an MCP23017. I believe I just need to do i2c_start_packet and i2c_finish_packet.
I believe this is the right way to talk to the MCP23017 using Pete’s I2C routines. However, I made the change to my code and it still does not work. 
It is possible there is something else in Pete’s code that is needed when communicating between PIC and dsPIC, but not when using a device such as the MCP23017.
I am still digging through Pete’s code, but it does take time. I added a flag to control whether the checksum is sent by i2c_start_packet or not since I don’t think I need this for the MCP23017. I just set the flag FALSE in calls to i2c_start_packet for the MCP23017. I made the change to set the flag TRUE when Pete’s code calls i2c_packet to preserve the way he uses the routine.
8-Dale
I have some more thoughts on stacking of boards. It ocurred to me that if we have the ability to stack boards, we don’t need to put the 3 pin headers on the main MCU board - they could be put on a stacked board, along with other things we robotics folks like, need, or just want to tinker with.
People who don’t need or want the 3 pin headers for servos and sensors would not have to use the “robotics board” at all. This would also help create a very modular and configurable stacking system. It should also help keep boards small and easier to produce.
It would be very nice if it is possible to create a dual PIC board of the same or very close size to the Mini Atom Bot Board. However, larger is OK if we can maintain a compatible mounting hole pattern.
Thoughts?
8-Dale
Hi Dale,
Maybe distribute the 3-pin I/O headers between 2 or 3 boards? One can have an LCD interface, another additional RS-232 interfaces (I wish I had that now). But they would be different boards then.
Same size is desired! Remember, we need to have an SSC32 board in the stack as well.
Alan KM6VV
If we were to go with a stacking board on top of the MCU board for the sensor/servo header pins, there would be additional room for other interfaces as long as the cabling is done from headers. I really want to keep the 3 pin headers on one board, wheather on the main board or a stacked board.
It would be a shame to waste the added board space… There could be a socket for a BlueSmirf, maybe a couple of MCP23017 I/O Expanders (16 GPIO per chip, with 8 and 16 bit modes, and interrupt on change). How about a USB 2.0 Host interface and/or ethernet? There is always the possibility of additional ADCs. The MCP3208 has 8 channels of 12 bit A/D but interfaces using SPI. I need to learn about SPI.
This is exactly what I am after. I have seen various kinds of stacking arrangements, but nothing quite like we are talking about here. I think this would allow anyone to create a stack to suit pretty much any application. If you want more A/D, there can be a board with lots ADCs and perhaps some DACs also.
I would not have any problem with the board(s) being larger than the bot board, as long as a compatible mounting hole pattern can be maintained. While this dual pic board can stand very well by itself with any added boards in a stack, maybe somebody might want to slave some additional processing to an Basic Atom or Atom PRO… I want to make the 4550 be able to be either master or slave, perhaps set with a jumper.
I’ve also got my sights on that 18F87J50, with it’s added I/O capabilities (including two MSSP’s that can each do either I2C or SPI). I would love to be able to use these very cool PICs.
8-Dale
You will not believe this…
My I2C is working now.
There was a piece of lead stuck under the PIC between the SCL and a pin next to it. That must have been keeping the SCL line HIGH. I could not see the lead until I took out my new magnifier and did a closer inspection around the chips.
Whew! This problem was driving me crazy because I knew my circuit was wired right and could not find any problems in my code. I2C and SPI will probably play a very big role in WALTER’s new brain. It’s too bad the I2C and SPI pins are on the same shared pins on most of the PICs, except for the larger ones like the 18F87J50. There are some real nice chips that only interface via SPI.
8-Dale
Hi Dale,
Great! Glad to hear it!
I’ll have to get around to getting my “Quick Flash” boards talking to each other (I’ve got a 2nd one running). But like we’ve discovered, most PICs share pins between SPI and I2C. What with SPI often requiring chip select signals, and I2c a software “addressing”, it might be possible to switch back and forth between SPI and I2C. It would be a pain, 'tho.
Yeah, I believe it, it’s happened to all of us.
Did you see the pix of the legs I’m machining?
Alan KM6VV
Greets, Alan!
Now that I know I2C works for me, I think my next step will be to add a 4011 to my circuit with the 4620 I have wired to the MCP23017. I want to make an addition to the 4011 firmware command structure to allow blinking LEDs on at least one port. It will be an easy way to tell if the two chips are communicating. I think Pete already has a status command for getting status from the 4011.
The bus signals might have to be isolated so they only went to the appropriate bus in each mode. It might be workable. You’d have to keep track in software which bus mode you are in. Then you could initialize the bus you want to talk to.
I may have missed that. I will have to check it out.
8-Dale
Hi Dale,
I’m thinking they might coexist, because each can’t read the other. Maybe not. SPI parts (w/ Chip Enables) will conveniently ignore traffic on the MOSI and MISO lines. I2C might simply ignore traffic if it doesn’t see the protocol addresses. Might be worth a try.
http://www.marconettengineering.com/Femur20.jpg
This is a femur I’m cutting out of 1/8" aluminum plate. I’ve got 3 cut so far, I think I’m going to go ahead and make 8. I’ve also been working on the plates for the body. Seeing the Phoenix today gave me ideas! I’ve just got to figure out how to mill it out on a mill that’s designed to cut stock about one half as big. I’ll probably do one side, then flip it around for the 2nd side.
Alan KM6VV
I think it would be safer to isolate the two bus signal sets somehow, maybe with buffers or drivers of some sort, if we want to allow switching between I2C and SPI on the fly. There would probably have to be a GPIO dedicated for the switching to enable the appropriate set of buffers/drivers. I do think this would be desirable, but don’t know if adding buffers/drivers would affect the bus timings.
I have the dsPIC30F4011 all wired up with the 18F4620 and MCP23017 now. I just have to figure out how to specify the oscillator setup I need for the 4011 (HS/2 with PLL16). I have 14.7456 MHz crystals instead of the 7.3728 Mhz crystals called for in Pete’s design. Luckily, the 4011 has an oscillator setup that divides the crystal frequency by 2 before applying the PLL.
Nice!
8-Dale
Greetings everyone!
I have made more progress on the PIC to dsPIC communication. I have an 18F4620 wired to a dsPIC30F4011 and an MCP23017 I/O expander. Everything is communicating via I2C to some degree. I can write to the MCP23017 from the 4620 without problems. I can also get a successful loopback test between the 4620 (master) and 4011 (slave).
I have 4 LEDs wired to PORTE of the 4011 now, and I can tell the dsPIC to light these in any sequence. I am using the 0x04 write to digital port E command.
8-Dale
I just wired an 18F2680 (20 MHz), dsPIC30F412 (14 MHz), and an MCP23017 up for I2C. I have I2C communication with all chips! I had to do some pin changing to get things setup on the 4012 because it only has a single UART. I am really after the quadrature encoder module on the 4012, and there is only one. If I use two 4012’s with a regular PIC, I can get two quadrature encoder modules as well as two UARTs, and I don’t think this will take up much more board space than a dsPIC30F4011.
I still have the 18F4620 (20 MHz) wired up to the dsPIC30F4011 (14 MHz) also, and that works perfectly. I have had the I2C bus running at 100 kHz, 400 kHz, and 800 kHz, without any problems as far as I can tell.
However, I am having some difficulty with I2C and an 18F4550 setup to run at 48 Mhz. I have not been able to get the 4550 to communicate with anything via I2C yet. I may have to drop the 4550’s speed down to 20 Mhz or 40 MHz (requires a 10 MHz crystals and 4X PLL) to get I2C to work. I need to find out if I can still get a 48 MHz clock rate for USB and still run the 4550 at 40 Mhz.
Any thoughts on replacing the dsPIC30F4011 with two dsPIC30F4012’s? The 4012 is the 28 pin version. We could also use two 4011’s to get two quadrature encoder modules, as well as two additional UARTs, more analog inputs, etc, but this would take up considerably more board space unless they are put on a stacked board. Hmmm, a dual dsPIC DSP board…
I have implemented a command to allow changing the base (high byte) I2C address of the dsPIC chips. I have not yet written the code to store the base I2C address in EEPROM or to read jumpers to set the default I2C address. I want to use 3 pins for jumpers, which would allow having up to eight dsPICs connected to the I2C bus per base address. I2C addresses must be paired - even address for write and odd address for read.
Additional thoughts… Maybe we could get everything on the main MCU board including such things as a socket for a Bluetooth module, except the dsPIC(s). We could still put the 3 pin headers on a separate board with other goodies we might want. I have not yet figured out now many 3 pin headers we will need just for one 40 pin PIC or for each 28/40 pin dsPIC.
I don’t think we should worry about keeping a stackable arrangement to allow including an SSC-32. The SSC-32(s) can be in a separate stack. This will remove any size restriction on our new boards.
I found the Maxim MAX127/MAX128 - 8 channel 12 bit ADC (I2C, DIP) - and I have two of these to play with now. Of course, I also have the MCP23017 8bit/16 bit I/O Expander (I2C, DIP) for additional GPIOs. I am still looking for an I2C DAC in a DIP package - there are a lot for SPI.
I am at a point now where getting one of the OOBOT boards would be useful. I built one of the little Bread Board Power Supplies from Spark Fun, so now I can start putting WALTER back together. I can now program 4620/4680/4685 PICs with working I2C, and these will work on the OOBOT boards.
8-Dale
Hi Dale,
I haven’t looked up the 2680, what’s new about it?
That’s great. I’ve yet to include in I2C code, or try it out. I got some 4012 chips, but nothing to put them on yet. I have a shaft encoder on my Quick Flash boards, but no special hardware to read them. I just sample them at a fast enough rate, and deduce the steps from that, if needed.
Is 600 kHz a standard rate? Maybe it doesn’t matter, although I’m guessing they must match. I’m running at 40 Mhz.
You might need to change the divisor settings, remember it runs at 48. Otherwise I wouldn’t think there’d be any difference. You shouldn’t need to run at 40 Mhz.
I don’t see a problem, but where are you going to put all of these chips? Stack them?
You can just read them out of the EEPROM.
A socket for the Bluetooth? I thought it was a module that connected to the RS-232. LOTS OF PINS!
I wouldn’t stack the SSC-32, I was planning to put it on the deck below. I was still thinking about octapods when I figured out my custom body needed to mount my quick flash board. I discovered I could put TWO quick flash boards next to each other on an octapod layout! I’ll work out a hexapod first, then determine the load it can handle. Then I can expand to an octapod if I want… it’s just a few more parts to buy! I’m also thinking of adding a rotating joint between the tibia and coxa on the two front legs. Remember the red hexapod with the two additional appendages?
That’s a lot of stuff on the bus. What are you going to do with it all?
What all goes back on WALTER? All of it? Are you planning on building a legged robot? I think you mentioned a quad. I’d like to try a quad gait sometime.
Alan KM6VV
The 2680/4680 has CAN bus. The 2620/4680 don’t have CAN bus. The nice thing about CAN bus, is the pins on the chip do not conflict with the I2C/SPI pins.
If possible, I want to change the communication between the dsPICs and the main controller, which would be a 2680/4680, to use CAN bus. This would allow ALL dsPICs and PICs to be I2C slaves (except the dsPIC4012) if a user wants to use a different MCU (like, say, and ARM unit) as the master controller. I have to do a lot more reading on CAN bus to see if this is really feasible.
I am working on I2C slave code for regular PICs, like the 2550/4550, 2620/4620, 2680/4680, 2685/4685, and others. The 4680/4685 is a drop in replacement for the 4620 in Pete’s dualPIC board. One reason I am working on this code is to see if I can make a 2550/4550 into a slave to allow adding USB. The dsPIC4011 and dsPIC4012 have CAN bus. The 4012’s CAN bus pins are multiplexed with the I2C pins, but I don’t see this being a problem if CAN bus is used for all inter PIC/dsPIC communication.
When you get ready to fiddle with I2C, just let me know, and I will send you my modified versions of Pete’s pic_i2c.h and pic_i2c.c files. This is all that is required to communicate with slave dsPICs, PICs, and devices such as the MCP23017. I am already doing this now! I can make most PICs (except for the 2550/4550 at present) communicate with dsPIC4011, dsPIC4012, and dsPIC4013 chips.
Standard I2C data rates are 100 kHz and 400 kHz. I do not know if any higher speeds are standard, but I know several chips do support higher speeds. For instance, the MCP23017 supports up to 1.7 MHz I2C. I have had a 4620 doing 800 kHz I2C with a dsPIC4011 and an MCP23017 with no apparent problems.
I don’t fully understand the oscillator setups for using USB on the 2550/4550 yet. The info is spread across several sections of the datasheet. I’ve been told that I2C will work on a 2550/4550 running at 48 MHz, so I just have to find out what is wrong with my configuration and correct it. I have calculated the values for SSPADD (holds the baud rate load value for master I2C), which uses the SSPADD = ((CLOCKRATE / BITRATE) / 4) - 1 equation. There is already an Osc_Freq_Mhz variable for clock speed (MHz), and I could add an I2C_Bus_kHz variable to plug into that equation, which would make it much easier to set SSPADD to the right value.
Remember, we don’t need to be constrained by the size of the SSC-32 or mini-ABB. If the mini-ABB is used, it can be stacked with the SSC-32 on the EC-02 carrier. This is also one reason I want to have the main controller on our board be able to be either an I2C slave OR master. Some folks might want to use our board and control it with a Basic Atom, Atom PRO, or other MCU (like ARM, any Linux based board/computer, or even a Windows PC). If I were going to design a board for myself, I would put a 2680 on it as main controller, with two dsPIC4012’s, and a 2550 slave for USB and other I/O. This could all be put on a single board not much larger than a mini-ABB. The master controller could even be a 4680 and the board would not be much larger than the mini-ABB, assuming there is a stacked board with all the 3 pin sensor/servo headers. Once I get the master/slave I2C code working on a 4550, this will be possible, as this is the only PIC/dsPIC communication issue I still have to overcome with I2C.
Yes, of course. However, the EEPROM needs to be initialized with a default address. The easiest way to allow changing the I2C device address (low byte) is via jumpers for each slave dsPIC/PIC. I can change the base address through a software command to the slave. I added code to read three jumpers tonight. All I need to do is write the code to read/write the I2C address in EEPROM. The jumpers will be read on power up or reset, and EEPROM updated if needed.
Yes, Bluetooth modules do connect to a TTL level serial port. That’s another good reason for having more UARTs available. The Bluetooth module I am thinking of can be put into a socket on our board (or a stacked board) and wired to UART pins.
This is the approach I will take when I finally start building my Walk 'N Roll bot which will be an octapod with 4WD in the final version. I’ll start out building a basic hexapod, keeping in mind the future addition of 4WD. Then I can expand to an octapod configuration with grippers on the two front legs. While I am working on the walking part, I can also be working on the 4WD part separately. Finally, I can combine the two parts one both are working as I want them to. I expect Walk 'N Roll to be a 2 to 4 year long project.
Yes, this has ocurred to me also, as well as putting regular biped style feet on each leg - basically using BiPod style 4DOF legs.
One reason for getting the MAX127/MAX128 ADC chips is so more of the I/O pins on the main controller and dsPICs can be used as GPIO’s. The Maxim chips also have 12 bit ADC of the same type (Successive Approximation) seen in PICs and many other microcontrollers, including the Atoms
If we can do the four microcontroller (quadPIC) board with a 4680 as main controller, two dsPIC4012’s, and a 2550 (for USB), then this will become WALTER’s new main brain board. Otherwise, with a dualPIC board (4680 and dsPIC4011), I’ll need a stacked board that has at least a dsPIC4012 (or another 4011) and a 2550/4550 (for USB).
I also have the compass module (I2C), 3-axis accelerometer module (analog), and RTC module (I2C) to integrate into WALTER’s design. I’ll have connectors for all of these next week.
Now, wouldn’t you like to have a quadPIC board? It will be insanely easy to expand Pete’s dualPIC design. I only have to solve my 2550/4550 I2C problem to make it all workable.
8-Dale
Greetings Dale,
I don’t know that I need another interface.
This is getting really overly complex. Maybe too much for a simple walker.
The 4550 is possibly more suited to being the master, although I no longer thing USB is needed on the 'Bot. There is a Robo-brick (?) standard (HB Robotic club). You might check into that.
What mods were made? Sure, I might as well look at it now; as I have a second 'Bot board to play with. Are the drivers set up to allow them to be switched between slave/master easily? What changes from the MicroChip examples and demo code?
Well I guess 400K already is faster then 115K (RS-232).
I’m sure it’s all in the calculations. As I have some PICDEM USB boards (18F4550), I might try a connect with them.
That’s pretty tight for a mini-AAB form factor. I see no reason to be tied to it. The Atmel ARM7 demo board (AT91SAM7S256-EK) is the same size as my '452 demo boards, although it doesn’t have mounting holes in the corners! The EK without the LCD, '380 and other interfaced parts would have the TWI (IC2) pins available. More possibilities!
It would be easy to use 3 jumpers for the address, but that takes up pins. The EEPROM is easily programed along with the Flash EEPROM when loading the code.
OK, I hadn’t looked at that one. Can’t have too many USARTS!
Supporting 4WD would be a tremendous burden on the legs; although I did find the “rollerskating” 'Bot quite interesting.
Which bipod legs? I just looked, and I didn’t see any that appeared appropriate. I need to find that video again and take another look at the two legs with the extra rotate joint. Not at all like I saw in the biped collection. I think the two appendages could double as legs, and be used together for a jaw. But the Femur on my 'Bot doesn’t really lend it’s self to a jaw. However these are temporary, I’ll have my son design me a more appropriate set. The Low Profile Axis (LPA-01) is what I had in mind adding between the coxa and tibia.
And what are you going to use the A/D chips for?
Have you started the layout? I’ve got enough board to get my 'Bot going, With the addition of some leg sensors and ultrasonic sensors.
That and a little layout! sounds like too many chips and I/O connections to but on a board that could be laid out with Eagle. Although one of days I intend to upgrade my Eagle license.
Alan KM6VV
Hi Alan!
Well, I am really more of a software dude than a hardware dude, although I can design electronics control stuff. With all the microcontrollers we have access to, it’s gotten to be a lot more fun fiddling with electronics - something I have very much missed doing. I need some SPI routines, since there are a lot of cool SPI chips available in DIP form. CAN bus seems really complex, compared to I2C and SPI, but I can see a use for it in robots that have multiple controllers of various sizes and capabilities.
Is there any such thing as a “simple” walker? You get six or eight legs moving and then you see how hard it can be to coordinate the movements. Jim and James make it looks so easy. and of course PowerPod simplifies things considerably. I am amazed that Jim paid to have it developed and is just giving it away to us for FREE.
My original intent is to have a 4550 and a dsPIC4011 on a dualPIC board. The reason I like the idea of having USB available, is the board can be used as a slave to any other controller, whether it be a PC running Windows or Linux, or an ARM or other microcontroller. This is one reason I am pushing to get slave I2C code working for regular PICs like the 4550. I just started a new MPLAB project for this. I pretty much have the I2C interrupt routine ported from the dsPIC to the PIC and have written an I2C slave init routine. I still need to finish porting the rest of the background processing code for the mainline from the dsPIC code. Then I can start testing it all!
Original Code:
[code]void i2c_start_packet(utiny device, utiny num_bytes)
{
utiny kk;
SSPCON2bits.ACKDT = 0; // ack
DelayMs(3);
set_sspcon2(START_EN);
if (SSPCON2bits.SEN)
{
// Failed.
printf("SEN iic_start_read\n");
}
DelayMs(2);
send_i2c_byte( device ); // mode is WRITE
checksum = 0;
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) );
set_sspcon2(REP_START_EN); // Repeated Start, to change from WRITE to READ
DelayMs(2);
send_i2c_byte(0x01 | device); // mode is now READ
DelayMs(2);
// Ensure SSP is idle before setting recv mode (see A4 Silicon Errata).
kk = 0;
while(SSPCON2 & 0b00011111)
{
ClrWdt();
DelayMs(1);
kk++;
if (kk > 20) break;
}
set_sspcon2(RECV_EN); // enable receive mode (wait for RCEN to clear)
} // i2c_start_packet()
void i2c_packet(utiny device, utiny send_count, utiny recv_count)
{
i2c_start_packet(device, send_count);
i2c_read_bytes( recv_count, FALSE);
i2c_finish_packet();
//if (checksum != 0)
// printf("%02x cs %02x\n", i2c_buffer[0], checksum);
} // i2c_packet()
[/code]
Modified Code:
[code]void i2c_start_packet(utiny device, utiny num_bytes, bool sendchecksum)
{
utiny kk;
SSPCON2bits.ACKDT = 0; // ack
DelayMs(3);
set_sspcon2(START_EN);
if (SSPCON2bits.SEN)
{
// Failed.
// printf(“SEN iic_start_read\n”);
}
DelayMs(2);
send_i2c_byte( device ); // mode is WRITE
checksum = 0;
for (kk=0; kk<num_bytes; kk++)
{
send_i2c_byte( i2c_buffer[kk] );
checksum += i2c_buffer[kk];
}
if (sendchecksum) {
// Send the checksum.
send_i2c_byte( (utiny)(256 - checksum) );
set_sspcon2(REP_START_EN); // Repeated Start, to change from WRITE to READ
DelayMs(2);
send_i2c_byte(0x01 | device); // Mode is now READ
DelayMs(2);
// Ensure SSP is idle before setting recv mode (see A4 Silicon Errata).
kk = 0;
while(SSPCON2 & 0b00011111) {
ClrWdt();
DelayMs(1);
kk++;
if (kk > 20) break;
}
set_sspcon2(RECV_EN); // Enable receive mode (wait for RCEN to clear)
} // sendchecksum
} // i2c_start_packet()
void i2c_packet(utiny device, utiny send_count, utiny recv_count, bool sendchecksum)
{
i2c_start_packet(device, send_count, sendchecksum);
i2c_read_bytes( recv_count, FALSE);
i2c_finish_packet();
//if (checksum != 0)
// printf("%02x cs %02x\n", i2c_buffer[0], checksum);
} // i2c_packet()[/code]
I had to change the i2c_start_packet() routine so I could disable sending of the checksup and switching to receive mode when talking to devices such as the MCP23017. Of course, I had to also modify any routine that calls i2c_start_packet(), which is just i2c_packet(). Now I can use the same I2C routines to write to smart MCU slaves and device slaves.
Initialization of the 4550/2550 for USB operation is a little strange, and I still don’t understand it fully. I do have I2C working with the 4550 now, but I am not sure it is running at a full 48 Mhz. Next week I will have the rest of the stuff to allow me to actually connect a 4550 to the USB bus. I just need to get two of the proper type of push button switches (normally open, instead of normally closed) and I am getting a mini USB connector breakout from Spark Fun.
I think any size up to 4" by 4" or 5" would be reasonable, but I don’t think we will have to go that large unless we go with putting the 3 pin headers on the main board. If I need to choose, I would choose to give space to the stacking connectors instead.
I think there are enough odd sized ports on the 40 pin PICs to make using those for jumpers reasonable. I definitely don’t want to use any of the full 8 bit ports for jumpers. Remember, a single MCP23017 chip can gain us 16 GPIOs real easily, including interrupt on change capability.
I am hoping Spark Fun gets more of those Bluetooth DIP modules in before next month, since I am going to get something for Bluetooth. I’d rather get the DIP module, but will get a BlueSmirf if they are not in stock at the time I place my next order.
it’s actually not the legs I am worried about. It’s the servos in the legs that might have trouble supporting the weight of Walk 'N Roll with 6 or 8 legs and 4 retractable wheel towers.
My BiPod thread should have the info you are looking for on the legs I have designed. I actually have all the brackets assembled. I just need to fill them with 10 servos and get a copy of SEQ. The BiPod legs only have 1DOF at the ankles, where most bipeds have 2DOF at the ankles. I want The BiPod’s main locomotion to be in the sideways mode of the hexapod.
The Sharp IR rangers require one ADC per sensor, and my 3-Axis accelerometer requires one ADC per axis. There are other sensors that also either only have analog outputs or a choice of analog and other outputs.
I have some parts places on a schematic, but nothing much done on wiring yet. I’ve been waiting to get a better idea of what the board will really have on it before I do too much on the schematic. I also have to create some Eagle symbols for some parts. I already have symbols for the 4550 and dsPIC4011, which is nice.
I think even a quadPIC board would fit within the limits of the free Eagle version I have. I have been thinking I might upgrade to the personal license at some point after I learn how to use it better.
8-Dale