I’d dump it. More intermittent connections, you don’t need.
That should work; looks similar to one I had years ago. You might consider using the Schmart boards for your prototype work. You put .025" wire wrap posts on the sides of the Schmart Boards, and use specially made jumpers to route power and data. I did that to prototype my ARM7 board design. In the distant past, I wire wrapped DIP designs.
I like the Weller electronic stations. Maybe I can get new tips for my old station.
That’s exactly what I am going to do as soon as I get my new breadboard. This has just been causing me too much frustration and I just don’t trust this breadboard anymore.
Actually, I am going to be getting the Global Specialties PB-105 breadboard. Mouser and Newark stock it, and it’s $99.00 both places. It’s twice the size of my current breadboard (6 segments instead of 3) and has a lifetime warranty.
I may end up going this route. I want to ease into the use of Schmart Boards a bit at a time. Once I get my new soldering station, I will have the right tools to make full use of Schmart Boards. After watching the videos of the guy soldering the various chip packages (QFN and QFP) and the tiniest SMD caps, I am much more confident I can do this. I did electronic assembly for 4 years, but never worked on any SMD/SMT stuff. The Open Servo boards are all SMD/SMT.
I am excited about the possibility of creating my own modules that can be reused over and over. There are quite a few chips in QFN, QFP, SOIC, TSOP, etc that I would like to be able to use. This includes various MCUs. TI is real good about sending out samples of a LOT of their chips, including ARM7 and ARM9 MCUs. Some of the other chips I am most interested in come from Dallas-Maxim and Analog Devices.
Oh, I am. That’s why I am getting a new soldering station and such. I have to have better tools than I have now to work with the Schmart Boards. I need a better soldering setup anyway, because even the sensor modules I got from Spark Fun have smaller holes than I can really solder with my current low quality iron.
I’m a Toys 'R Us kid. Does that count?
Oh yeah, I know! Being able to use Schmart Boards will remove that restriction. I am dreaming of a dualPIC board with an 18F87J50 and a dsPIC33FJ256MC710…
OK, OK, back to reality… An 18F4550 and a dsPIC30F4011.
I’ve sent you a pix of Schmart Boards in use. It’s actually an early pix, before another two columns (4 boards) were added, and without the DB9’s for I/O.
And putting the iron back in the fireplace all the time to re-heat it must be a chore too! I’m about ready for a new soldering station as well.
I bought a microscope for the lab at work (for surface mount work). Imagine working under a microscope all day long!
Yeah, the kids these days get ALL the toys! LM comes to mind…
It could happen! But let’s see what we can do with the 18F87J50 parts.
Oh, cool! I will look forward to seeing that. I am anxiously awaiting Friday when I can order my new breadboard and some Schmart Boards for the 18F87J50’s.
Yeah, and that fire is HOT! I think we should both get a Weller WES51.
I need to get my eyes checked and probably need new glasses too, but that is going to have to wait until the new year. I need one of those magnifying lights to work under. I don’t have enough light on my desk.
I know! There are quite a few things I want from Lynxmotion, but that too is going to have to wait until the new year.
Yes indeed!
First I have to get a 4620 setup for slave mode so it can switch between master and slave via a jumper setting. I already have the code to read the address jumpers, set the slave address, and for switching between master and slave modes based on the jumper setting now, but I have to add that to the 4620 code base and get the I2C slave code for it working.
I want to get everything working on the 4620, including I2C slave mode. Then it can all be ported to the 4550 and other chips easily after I add the necessary defines.
I have almost everything I need to connect USB to the 4550, except for two normally open SPST push button switches. I bought normally closed switches by accident. I got 2 of the mini-USB connector breakouts from Spark Fun. I’ve already modified the Microchip USB framwork to move the switches to where I need to have them. The defaults were conflicting with pins I need for other things.
Another thing that can be done is have a set of conditional compile #defines. This way the same code can build several variations of projects. For example, I have a “#define PS2_CODE” and a “#define COM_CODE” to allow me to build for either mode. I also have conditionals set up for generating “commentary” (verbose program data dumps), as well as for outputting SSC32 commands (sometimes it’s nice to turn them off if I’m just watching the flow of data through the calculations).
And of course I’ve already mentioned that one can take advantage of different processors on different boards. I routinely go back and forth between the 4620 and an 18F4550. One board has an LED, the other does not! More boards in the future, I suspect. Of course this implies that the PIC setup code can be conditionally compiled as well.
I don’t really know. He logged in here a few days ago and left me a PM, and I see him post on the Spark Fun forums. You may have seen my dualPIC thread over there.
The 4620 and 4680 have the exact same pinouts as the 16F877A. That’s why I can use them on the ooBOT board when I get it - the ooPIC II+ chip that comes with it is really a 16F877A.
Yes, indeed. I am planning to do that sort of thing. For instance, the 28 piun PICs don’t have all the ports the 40 pin chips have, and fewer peripherals.
Yes, that works, or at least should work well. I have my code setup to accept commands over the serial port also, which I think I mentioned before. Our version of the dualPIC software will be having some additional nice features.
The 4550 has a different pinout than the 462o or 4680, so how do you do that? I have to make two circuit changes in Pete’s design to accommodate the 4550.
I want to get one of the Vinculum VDIP1 modules and see if I can get a 4620/4680 to talk to it. This module has a dual USB 2.0 Host/Device port setup. It would be nice to be able to use this, since it can do both Host and Device modes. I do have reasons to want a USB Host controller available. I’ll say more about this when I get the module and start fiddling with it.
I just want to get one to fiddle with. I would be more likely to want to use it for an ARM board.
It’s correct according to what I read about I2C. I may just not have gotten the change ported over to the 4620 yet. I will check and make sure that gets done when I have my new breadboard.
Well Christmas is coming early this year; my wife ordered enough parts to finish up my CH3-R 'Bot! 'Hope others were able to take advantage of the sale as well.
Happy Anniversary to LM! And thanks for the sale!
Back on I2C, I had a thought last night in the wee hours; If we have an I2C bus, why not add a small PIC (28F1234?) and let it do the communications with either PS2 or a com port? That would off-load the main processor of the task, and would present a uniform interface to receive commands. It could handle other channels as well, I suppose. Andrew Lippitt at
vizlog.com/robot/ is doing that for sensors (FSR), and maybe reading the servo pots as well (?).
I’m working on my own idea for a multi-directional (analog) sensing foot. But I could use the “weight” of one foot if someone knows. Otherwise I’ll figure it out later after my 'Bot is mostly together.
I suppose you want to thoroughly check out your new design on a breadboard before committing to a PCB, but you might consider using a simple PCB with xtal, chip, 7-seg LED, regulator and a few PBs for your initial tests. This board will take a 40-pin DIP ('877, '4620, etc.). Let me know if you’re interested in one.
That’s great! You will be able to test out some of the ideas you have soon.
Yes, that would be a great idea! I have been working on a similar idea for sensors such as the Sharp IR Rangers. You could dedicate a controller to just doing this specific thing, and would not have to worry about taking I/O pins away from the main controllers. However, you could also easily do this with the dsPIC, which will not have too much to do for awhile.
I found this company with a line of PSoC controllers, and have requested a sample. They can be programmed either using an icon system or in C. It was extremely easy to design the programming for a PSoC that could handle up to eight Sharp IR Rangers, including an LED indicator for each sensor, plus a couple other indicators. The bare programming/evaluation kit is just $40.00. They have PSoCs from 28 pin DIP up to 100 pin QFP/QFN. I support the distributed model 100%! It would be possible to use one of these PSoCs to control a pair of 3DOF legs for a walking robot, and that includes the 28 pin DIP PSoC. They also have this technology they call CapSense, which I would like to experiment with.
I believe he is using Open Servos which I think he is using for the feedback from servos. His stuff is very cool, to say the least.
I have been intrigued by the idea of having sensors on the feet of a walker, biped, or The BiPod. Spark Fun has a capacitive touch sensor module I would like to get and fiddle with. It has two channels, which could be the front and back of a foot, or the front right and left with another covering rear right and left. This is another area you could throw a dedicated MCU at ,for each foot if needed. Put the intelligence right where it is required.
I am very interested! I would like to do this sort of thing. I have already had a 4550 talking to a dsPIC4011, so that is not a problem. I could build up a couple boards like this, with a socket for the PIC. I have a few 40 pin sockets. I could socket the crystal also. I did get my 10 MHz crystals, so I have those as well as 20 MHz crystals now. I also got some 32 KHz crystals for the Maxim DS1307 RTC (I2C, 8 pin DIP) chips I have, so we could even put an RTC right on the new dualPIC board.
Yes, I could see having a uP dedicated to IR, and one to SONAR also! Could be done on ANY chip (more or less), but it would be immediately useful to get PS2 out of my hair.
I might have that development system already; got it from a friend a few years ago who was moving to Texas to retire.
SO MANY USEFUL CHIPS! But I hate being diluted over several different processors. I watched a fellow engineer attempt to get a Cypress USB Host up (GNU), I don’t want to go there! I’d recommend staying in as few families of uP as possible!
The cap touch sensor is nice, but it’s $24 or so, my idea is about $6, and works in 2 1/2 axis.
It’s already done! May not exactly fit your needs, but gives you a PCB for the processor and its usual support. Use jumpers to connect it to Schmart Boards, and you’ve got your preliminary design. Interested in one?
Couple of questions:
[code]On the I2C, I’m not seeing much in the way of interrupts. One place where the code POLES an interrupt bit (no IRQ?).
The names of the routines are somewhat descriptive, but it would be nice to have comments on each routine; what they’re for.
What’s the general sequence of events for the Master to send, say, a command to the Slave?
What “wakes up” the Slave?
How does the Slave respond?
How does the Master get back a reply (assuming one was expected) from the Slave?
[/code]
(You can probably tell, I’ve been reading the code).
Just about any PIC could be dedicated for PS2 or any other controller handling, including standard joysticks, etc. I’d use an 18F2620 or similar PIC just so we don’t get limited by memory or I/O pins.
I am going to see if a PSoC can be programmed to do this sort of thing. I got my samples from Cypress today - two CY8C29466-24PXI PSoCs (28 pin DIP). I had not thought that I would need a way to program them. Maybe I can wire up a programmer for them once I get my new breadboard.
If I were to use these PSoCs in designs, I think I would stay with the ICON form of programming them. It really is pretty easy.
Very nice! I could see something like this being used for The BiPod if I ever manage to get servos to fill its brackets.
Yes, I would like at least one. I think it would give me a great way to experiment without using a breadboard.
Interrupts for I2C are only used in the slave mode code on the dsPIC. That’s what I want to get ported to and working on the 18F PICs.
I am working on adding comments as I understand the code more. This is one thing I very much want to do.
The master has to address the slave first, of course. After that it is really just sending data. When it sends a STOP, that terminates the I2C session. According to Pete’s code, there are 4 or 5 states to be handled for slave mode. I am just starting to understand that part now.
It gets addressed by the master.
It sends back an ACK or NAK to the master to let it know it is there and ready to do whatever the master needs. If the slave sends a NAK, it means it got an error on the last byte from the master. There is always an ACK or NAK for every byte received.
This is controlled by the address the master uses to address the slave. Even addresses are to write and the odd addresses are to read. That’s how the slave knows what the master is expecting. The R/!W bit (datasheet, SSPSTAT register) is the LSB of the address.
For some reason, I bought four (4) PIC18F4321 chips; not that much memory, so that wasn’t it. 13 A/D channels, that’s X & Y 6 legs! 36 I/O is still 20+ pins on the 40 pin part. A ‘Z’ contact switch in each leg also. But I can get the same on a '4620 PIC. The '4321 musta been for something else.
Do you really want the complication of a different COMPANIES’ uP on the board? And different COMPILER and programming needs… Want another Cypress kit? I’ll swap you for something interesting. Not trying to discourage you (well, maybe I am), but I just like to keep things simple. Ideally, you’d use IDENTICAL modules, in the “system”, that way they are interchangeable, use same tool suite, same programming, etc.
Might be, but I’m not familiar with ICON.
Where/what joints do you want to put sensors on? Foot as well?
That was the thought. I’ll see about getting you a couple. I wish they had an RS-232 converter on them w/DB9 connector, otherwise they’d be REALLY GREAT for a 'Bot. While the 'Bot is running, TTL interface to the SSC32 is all you need. You can use a little RS-232 dongle (COMPsys) to get your RS-232 levels (I think I’ve mentioned this before, in conjunction with my ARM7 board).
I saw a POLL of the interrupt bit, that’s all. Yes, please DO get it all ported! I did just find a tutorial on I2C on the Microchip site. It looked familiar.
No, I don’t want PSoCs on our main board. I am just looking at them as a possibility for sensor modules like handling 8 Sharp IR Rangers with LED indicators for each sensor. It was really easy to design a PSoC program to do this, although I have not added the glue between the LEDs and the sensors yet. It can all be easily accessed via I2C, which is what I want. I’m looking at these as a possible peripheral to a Linux based controller, or external module to our board. One of these PSoCs on a small board could be put anywhere senors are needed, but I do not know if they can handle a PING Ultrasonic sensor yet. I have no way to actually program my PSoC samples yet.
I prefer to stay with PICs for as much as possible, but the PSoCs do offer some possibilities for modules that can be easily interchanged and swapped around. They only interest me as possible sensor handlers right now.
It’s not the software name. It’s a form of programming using icons to represent internal modules. You connect the modules to do various things. You don’t write code, as such, but use an easier to manage (and yes, simplified) way to glue modules together. However, you can also program these PSoCs using C, which plugs right into the Designer IDE - the C compiler license is $144.00.
One of my requirements for the design of The BiPod is it must be sensor friendly and have plenty of places to add sensors. The feet are two of those places, as well as other places besides the top sensor turret.
That would be great! I have a second brand new SSC-32 that I have only hooked up a couple times. I also have a level shifter I got from SFE that works very well, although I have to change the header connector on it.
I am anxious to get the slave ISR ported over to regular PICs also. Getting this to work will give our board so much more flexibility. We would be able to use them as Master or Slave, just by changing one jumper (that already works).
I am open to changing the names of the routines if you have ideas for more descriptive names. However, I prefer not to do this without a very good reason. I only changed the names I did to make sure the routine names would not collide with any SPI routines I write that have similar purposes.
I had not seen this one. Thanks! I have it bookmarked now and will be checking it out more later.
It took me a bit to get it, but I am understanding it a lot better now. I was amazed at how much I have learned when I was explaining it for you.
I’ve got a PSoC CY3205-DK Development Kit. Has an ICE-4000, plus chips, sockets, cables, all the stuff. I wonder if it has the compiler you need; it has two CD’s in the box. You really NEED this!
OK, got the idea.
There are some rotational sensors that I just saw in one of the design mags. A chip that is placed up against a rotating magnet. Could be a way to pick up joint rotation easily.
Don’t worry about the names, although I’m partial (now) to “CamelCase”. I2cSendByte(), etc. The COMMENTS are a big thing. For instance, since we have code for both MASTER/SLAVE in one file, is this routine for use by the MASTER, the SLAVE, or both? All routines need these comments to say what the module DOES (for others reading the code). Is I2cWriteSlave() USED BY the slave, or SENDING TO the SLAVE?
What do I call to initiate a MASTER data exchange (other then the initialization code)? What happens in the SLAVE mode? I’d guess (want) an I2C interrupt to kick things off like Andy’s AN734 code does, but as there is no ISR, then some thing might have to check SSPSTAT to see when something has come in?
I’m beginning to think that either can call a send, and then wait for an ACK, or call a receive, and then ACK upon reception. It could all be quite symmetrical (should be!).
Sorry for the RASH of questions! But you’re AHEAD of me on the learning curve for I2C!
Here’s some interesting sites I’ve found the last day or so:
Oooooooooooooh, SHINY! Yes, this is something I need. I have a couple of the 28 pin DIP PSoCs, and just got a few more of a couple different types. Perhaps we can negotiate a mutually beneficial arrangement. I already have the latest and greatest software installed - PSoC Express as well as Designer.
Oh yes, this is very interesting! You can daisy chain these - like one per joint down a leg for instance. Quadrature output too - could connect right up to the Quadrature Encoder Module of a dsPIC30F4012 or dsPIC30F4011. I wonder if the quadrature inputs could be multiplexed for several of these sensors. I added the correct link for the AS55140 for you. I wonder if these would interfere with the operation of a servo. I wonder if we could get samples of these. I really want to fully implement the quadrature encoder module of the dsPICs so I can command them to read the encoders (QME-01) I have for WALTER’s motors
I need to look at this code then, because this is how Pete’s I2C Slave ISR looks except he is using if…then…else, which I don’t really like. I find it difficult to track what the code is doing.
As far as I know, there is only one routine that is used specifically in the ISR, which is the interrupt_putch() routine. All the I2C routines are used everywhere. i2c_write_slave() is just a testing routine I added so I didn’t have to keep writing the same code over and over for different code bases. All it does is do a bunch of I2C writes to the addressed slave device.
You initiate a read or write to a specific device address. EVEN addresses are for WRITE, ODD addresses are for READ. Pete’s I2C ISR is only used for the slave mode code. The Master initiates all I2C transactions and controls the clock (SCL pin). There is no way for a Slave to initiate a transfer unless it can interrupt the master, which Pete already has set everything up for. That’s what the INT0 (pin RB0) is used for.
The main I2C routines are i2c_packet(), i2c_start_packet(), i2c_read_bytes(), and i2c_finish_packet(). The last 3 are called by i2c_packet(). i2c_start_packet() is the routine I modified to add the 4th parameter to. This allows disabling the sending of the checksum and the switch to read mode. I also modified i2c_read_bytes() but probably didn’t need to. I think I could just do:
if (sendchecksum) {
i2c_read_bytes(recv_count);
}
and be fine using the unmodified i2c_read_bytes() routine.
No problem, Alan. I am learning more and better every time I have to explain some of this stuff. It helps me get a better grasp of I2C and I can see where I need better understanding.
I will be checking all of these out! Many thanks!
I have ordered my new breadboard, Schmart Boards (ordered 4, getting 6 on sample promo), as well as an LPC-2148 Prototype Board. I should have everything early next week.
I’ve already modified the Microchip USB framwork to move the switches to where I need to have them. The defaults were conflicting with pins I need for other things.