Nice pen!!! I see your out for revenge. This has caused me to rethink my project as well!!! Lets call a truece here.
Not wanting to make any drastic changes to your project·here, but earlier with the $20 you said you had a composite in memory and compared it to future pics. Is placing that composite in memory something you can do at run time?
( ie. 1.stop the pen, 2.·mark it's position to memory, 3.·alarm when pic no longer matches what's in memory, 4. place new posotion(picture) in memory, 5 repeat)
Ballground figure here. how long would this loop take?
It's up to the user to determine what constitutes an "event". Moving sunlight — especially with strong shadows — will certainly cause an eventual change between the key frame and the current one, if the key frame isn't refreshed occasionally. But the frequency of change could be used to decide whether an event has occurred. Changes in overall lighting, as from a sudden cloud, are less likely to trigger anything, since the autoexposure mechanism can respond fast enough to keep up.
··1. Set EOPTR to 0 (even). ··2. Read even rows from camera and write them to even or odd rows in buffer, depending on EOPTR. ··3. Count the number of pixels that differ between even and odd buffer rows by more than 1/2 of full scale. ··4. Is this count > 20? ······Yes: Call it an "event". ············Retrieve the average position of the changed pixels and draw a crosshair there. ············Set EOPTR := 1 - EOPTR (i.e. swap key frames). ··5. Go back to step 2.
With the lighting in my shop, the loop can be repeated 15 times per second. Actual image acquisition can take from 2 to 22 mSec, depending on the required exposure time. Comparing the two "halves" of a frame takes less than 9 mSec. Because I'm using fluorescent lights, exposures occur at fixed intervals of 1/30th second to avoid flicker and have to be captured "on the fly". With incandescent or natural lighting, exposures can be taken at shorter intervals or at random, as needed.
The PropCAM could easily focus its own lens, given the proper mechanism. From a programming standpoint, it would amount to taking full frames (even and odd rows together) and comparing the even rows to the odd ones. The more in-focus the lens is, the more contrast there will be between adjacent rows. The idea, then, would be to maximize that contrast.
For focusing another lens, the two lenses could be focussed in tandem using the above method (twin lens reflex style). The PropCAM could also be used with a fixed-focus lens and some sort of modulated and projected LED or laser light source to compute subject distance based on triangulation.
Thankyou for the feedback. Do you know how the digital slrs' can have different focus points in a frame? Like only the center portion of the frame needs to be scanned for objects?
Zoned focusing could certainly be accommodated, since all the image processing routines work within a user-defined bounding box. This box can be made smaller than the captured frame.
Phil,
I have the pan-tilt fixture just about done. I have a mounting board for the BOE-BOT. But I didn't realize that the Propeller demo board doesn't fit the BOE chassis. Also the Propeller demo board don't have any mounting holes.
What type of propeller board do you think this would be connected to ? Assuming that you use the BOE chassis.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap 4-digit LED display with driver IC·www.hc4led.com
Bean, I had a piece of scrap PC board material slightly larger than the BOE and cut it down to fit along with drilling mounting holes. I then mounted the Propellor Demo Board with some double sided sticky tape (2 layers). Worked great on the BOE-BOT chassis. I did have problems when I switched to the crawler accessory since I put the connectors on the sides and there wasn't clearance for the USB cable. A right-angle RCA adapter cleared the crawler hardware for video out and the same for a right angle power plug.
The controller board shown in this thread (http://forums.parallax.com/showthread.php?p=590369) might be a good candidate. But I'm not sure what the hole spacing is or whether it will fit the Boe-Bot chassis. ('Looks like it will.)
An alternative way to mount the Demo Board would be to fasten spacers or threaded standoffs to the DB15 holes and to the Boe-Bot chassis. Then put nylon standoffs, fastened only to the chassis, under the other three corners to hold them up.
I have modified the main mounting board so that there is room to mount the propeller demo board. I think I'll just leave it solid and the end user can do whatever makes them happy to mount the board.
Phil, could you do me a favor and print the attached PDF (make sure not to shink or enlarge it) and let me know if the camera and connector match up. The lines are tool paths, so the holes in the board will be on the OUTSIDE of the black lines. (You know what I mean...)
Any suggestions ?
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap 4-digit LED display with driver IC·www.hc4led.com
The connector is on the bottom of the board and is offset from the center. Attached is a dimensioned photo. The outer dimension of the connector shell is 0.545" x 0.195". The connector shell needs to flex a bit to accept the locking ramp of its mate, so I'd make the cutout a bit bigger. If the part is going to be machined instead of stamped, you'll need to make it bigger anyway to account for the tool radius at the corners. (The corners of the connector are square.)
This physical layout and the connector are cast in stone. They will not change. What might change, however, is the interface from the board to the rest of the system. The cable illustrated at the top of this thread is made up of parts available from DigiKey. They need to crimp the terminals onto the leads, though, and they charge a fortune for that service. It might actually be less expensive to make an adapter board for each end of a flex or ribbon cable, one of which plugs into the PropCAM, the other plugging into the processor board. I can't yet guarantee that this adapter board wouldn't hang below the 2mm header, though. In one scenario, the PropCAM would plug into an adapter board, which would plug directly into the processor board at a right angle using a single row of 0.1" header pins. If someone wanted the camera board and processor board separated, they would get a 0.1" flex cable from DigiKey with header connectors assembled to the ends (P/N A9CAG-1006F-ND). This increases the overall cost for a cabled configuration, but makes the cost of entry smaller for the PropCAM itself.
I've got a lot of different proto boards with this same footprint (no extra PropCAM boards, though). If you PM me your mailing address, I'll send you one with a connector soldered in place and a lens holder attached.
Okay, here is what I came up with for a Pan-Tilt fixture.
This was made on my LPKF cnc mill. This is the 4th version.
It uses the BOE-Bot chassis and the Propeller demo board.
I think the hard part is going to be routing the cables so they don't get tangled...
Another problem is that the Ping))) header sticks straight up.
Yes, I know the camera is facing the rear. If you turn in around it is really top heavy and tips over [noparse]:([/noparse]
Phil, · I will send this to you tomorrow.
[noparse][[/noparse]edit Aug 4, 2006] · Phil has informed me that the PropCam requires all 8 of the I/O pins on the demo board. Leaving NONE for the servos. That would be a pretty useless pan-tilt fixture. So I'm back to the drawing board with the Brian Riley's Propeller board.
Bean. ·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap 4-digit LED display with driver IC·www.hc4led.com
Bean:
I don't know if this will help, but...
On a old project I needed to get 4 wires into the upper part of a 360 spinning top. WHat I did was use one of the telephone "untangle" attacments (it attaches between the handset and the handset cord. I out washers and a spring between the upper and lower halves creating a thrust berring type assembly. It was able to rotate indefentally in either direction without the lines getting tangled. Maybe something simular might work?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller + Hardware - extra bits for the bit bucket =· 1 Coffeeless KaosKidd
·
I am interested in making a camera app, for my other hobby, small bore sillhouette target shooting.
With this, you shoot small steel 'animals'. 5 at a time. 2.5 minutes for the 5 shots.
I would like to make a 'tool' which watches the targets, and records the hits, or misses. and can then display where the target was hit, or the miss went.
Your FPS should be fine. But I would need to boost the standard lens to much bigger. The furthest target is 110 yards, and about 6"x8".
On my rifle I use a 24x scope. so someting similar would be needed for your camera.
Q. Can your cameras be adapted to bigger lenses/spotting scopes so I could get into the 24x+ range?
Adapting the camera to a longer lens shouldn't be a problem. The longest lenses I've seen that will fit the PropCAM directly are 50mm. But they're expensive, and the field of view at 110 yards would still be a wide 16 feet. The cheapest way might be to craft an adapter that uses the normal lens with a spotting scope. This way, you could make use of the spotting scope's focus mechanism. The other option would be to remove the camera lens and the spotting scope's eyepiece, leaving the scope's objective lens to function as the camera lens. But focussing might be more difficult.
Thanks for the info. I figured I would need to adapt the spotting scope. The some brands make adapters for digital cameras, (the normal consumer type, not the kind you use.)
My hope was to have the whole setup be small enough so I could mount it on a pan/tilt, and have it move from target to target. (The 5 targets are right next to each other. The PropCam could be adapted to identify the target, and then center it automatically.)
The great thing about this project, is I would have an excuse for my lousy scores. "I was tweaking the code."
The next step is to have the Prop control the rifle, but I think they would think that is cheating.
Do you have a timeframe for the PropCam? This year?
Oh, heavens yes, this year: a couple months or so at the most. The software is virtually complete. The lens is the main holdup: I'm now going into round two of sampling.
BTW, for your pan/tilt, be thinking, "Heavy base and worm drives."
Five seconds of live video at 30fps would occupy almost 1M byte, which is well beyond the memory capacity of the Propeller. But you could capture the video on your PC and replay it from there.
Five seconds of live video at 30fps would occupy almost 1M byte, which is well beyond the memory capacity of the Propeller. But you could capture the video on your PC and replay it from there.
-Phil
Would it be possible to have another cog write the frames to external memory? SRAM? I don't know if SD cards would be fast enough.
That's not outside the realm of possibility. Doing it serially would require a 1.5Mbaud data rate, which amounts to 13 Propeller instructions per bit. Of course, there would be some hub-access overhead, too. I haven't really followed the SD card discussions, so I'm not sure what data rate they can sustain. Write-durability might be an issue with SD cards, as well. Parallel access would be quicker, but might entail some special multiplexing hardware to keep the pin count to a minimum.
They use a 'ripple counter' chip to address the SRAM locations sequentially. This should be perfect for my 'recording' needs, since I just need to store the frames one after another. This only takes 2 pins for the ram address.
My questions for you are:
1. How many pins are free on the PropCam
2. Could the 'recording' routine be added to your PropCam processing COG code? This way, there should be less overhead comunicating from COG to COG thru the hub.
3. Do you have any object recognition code in the PropCam? To identify a small white chichen? Just kidding on this one... mostly.
Thanks
Seth
Phil Pilgrim (PhiPi) said...
That's not outside the realm of possibility. Doing it serially would require a 1.5Mbaud data rate, which amounts to 13 Propeller instructions per bit. Of course, there would be some hub-access overhead, too. ... Parallel access would be quicker, but might entail some special multiplexing hardware to keep the pin count to a minimum.
I've been thinking along these same lines. My approach would probably use a CPLD instead of discrete ripple counters for maximum flexibility.
To answer your other questions:
1. The PropCAM module uses eight of the Propeller's I/O pins: four for data, and four for control.
2. A better approach might be to parallel the PropCAM's data pins with the external RAM's data pins. That way no cog-to-cog — or even pin-to-pin — transfer is necessary, and fewer pins are used up. I'm still working out the details of how this might be implemented. The acquisition routines are busy enough that two tag-teamed cogs are necessary to keep up.
3. White chicken recognition will be left as an exercize for the user.
Phil,
It would be nice to have a general SRAM interface using a PLD. You could use 3 data lines, one for a clock and two for a mode (00-load, 01-increment, 10-shiftIn0, 11-shiftIn1). The load mode would transfer the shift register to the counter (and outputs). There could be one or two configuration pins that would assign a block of address pins to a decoder (either 2 bit or 3 bit) attached to the appropriate counter bits. This would eliminate the need for a separate decoder. The most significant bit of the counter would disable the decoder if a one. The counter would be initialized to all ones on power up. That would leave any SRAM unselected until the PLD is initialized. Two more control pins for the SRAM (/OE,/WE) would complete the set.
Mike
Post Edited (Mike Green) : 8/4/2006 5:29:09 AM GMT
I think you're on the right track there. My first inclination was to load bytes of the address in parallel from the data bits. But with the CPLD I was considering, I ran out of I/Os. Loading the address serially makes a lot more sense, since the PLD doesn't need to see the data bits, thus saving 8 I/Os. I'm even inclined to load the mode and R/W bits that way, too, to cut down on needed Propeller pins. Then it's just a matter of clocking the data in or out with a single strobe.
What would be nice is a nybble data interface, plus four or fewer control lines. But that entails an extra 4-bit holding register for writes and a quad 2:1 multiplexer for reads which, again, depletes the PLD resources — unless I add discrete logic.
They use a 'ripple counter' chip to address the SRAM locations sequentially. This should be perfect for my 'recording' needs, since I just need to store the frames one after another. This only takes 2 pins for the ram address.
Neat...
That's exactly the same techniques used in my 1984 Psion Organiser One.
Well... Except that it used it to read and write user data to EPROM...
Anyway, it can be made faster and more compact than what you see in that PDF, if you use the same pin that you clock the first counter with also act as A0 on the SRAM.
You may also want to clock the second counter from the Propeller, and not cascade it off the first counter.
(If you need Random access, as it·speeds it up·a lot. )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
Comments
Nice pen!!! I see your out for revenge. This has caused me to rethink my project as well!!! Lets call a truece here.
Not wanting to make any drastic changes to your project·here, but earlier with the $20 you said you had a composite in memory and compared it to future pics. Is placing that composite in memory something you can do at run time?
( ie. 1.stop the pen, 2.·mark it's position to memory, 3.·alarm when pic no longer matches what's in memory, 4. place new posotion(picture) in memory, 5 repeat)
Ballground figure here. how long would this loop take?
It's up to the user to determine what constitutes an "event". Moving sunlight — especially with strong shadows — will certainly cause an eventual change between the key frame and the current one, if the key frame isn't refreshed occasionally. But the frequency of change could be used to decide whether an event has occurred. Changes in overall lighting, as from a sudden cloud, are less likely to trigger anything, since the autoexposure mechanism can respond fast enough to keep up.
-Phil
The moving pen demo works as follows:
··1. Set EOPTR to 0 (even).
··2. Read even rows from camera and write them to even or odd rows in buffer, depending on EOPTR.
··3. Count the number of pixels that differ between even and odd buffer rows by more than 1/2 of full scale.
··4. Is this count > 20?
······Yes: Call it an "event".
············Retrieve the average position of the changed pixels and draw a crosshair there.
············Set EOPTR := 1 - EOPTR (i.e. swap key frames).
··5. Go back to step 2.
With the lighting in my shop, the loop can be repeated 15 times per second. Actual image acquisition can take from 2 to 22 mSec, depending on the required exposure time. Comparing the two "halves" of a frame takes less than 9 mSec. Because I'm using fluorescent lights, exposures occur at fixed intervals of 1/30th second to avoid flicker and have to be captured "on the fly". With incandescent or natural lighting, exposures can be taken at shorter intervals or at random, as needed.
-Phil
Nothing bothers my machine while its moving, it's just startup that's critical to my operator.
So this seems very doable in my app..
Stop machine, run camera!
Operator requests to start machine.
if no squirrels or hands have been in machine then
····· start machine
Else
····· Send picture of squirrel or hand to operator
End if
You seem pretty knowledgable on camera systems, do you think this could used as a base for an autofocus operation ?
kelvin
Yes, depending on what you wanted to do.
The PropCAM could easily focus its own lens, given the proper mechanism. From a programming standpoint, it would amount to taking full frames (even and odd rows together) and comparing the even rows to the odd ones. The more in-focus the lens is, the more contrast there will be between adjacent rows. The idea, then, would be to maximize that contrast.
For focusing another lens, the two lenses could be focussed in tandem using the above method (twin lens reflex style). The PropCAM could also be used with a fixed-focus lens and some sort of modulated and projected LED or laser light source to compute subject distance based on triangulation.
-Phil
Thankyou for the feedback. Do you know how the digital slrs' can have different focus points in a frame? Like only the center portion of the frame needs to be scanned for objects?
kelvin
Zoned focusing could certainly be accommodated, since all the image processing routines work within a user-defined bounding box. This box can be made smaller than the captured frame.
-Phil
I have the pan-tilt fixture just about done. I have a mounting board for the BOE-BOT. But I didn't realize that the Propeller demo board doesn't fit the BOE chassis. Also the Propeller demo board don't have any mounting holes.
What type of propeller board do you think this would be connected to ? Assuming that you use the BOE chassis.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap 4-digit LED display with driver IC·www.hc4led.com
Low power SD Data Logger www.sddatalogger.com
"Remember, you are unique, just like everyone else." Unknown.
·
The controller board shown in this thread (http://forums.parallax.com/showthread.php?p=590369) might be a good candidate. But I'm not sure what the hole spacing is or whether it will fit the Boe-Bot chassis. ('Looks like it will.)
An alternative way to mount the Demo Board would be to fasten spacers or threaded standoffs to the DB15 holes and to the Boe-Bot chassis. Then put nylon standoffs, fastened only to the chassis, under the other three corners to hold them up.
-Phil
Phil, could you do me a favor and print the attached PDF (make sure not to shink or enlarge it) and let me know if the camera and connector match up. The lines are tool paths, so the holes in the board will be on the OUTSIDE of the black lines. (You know what I mean...)
Any suggestions ?
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap 4-digit LED display with driver IC·www.hc4led.com
Low power SD Data Logger www.sddatalogger.com
"Remember, you are unique, just like everyone else." Unknown.
The connector is on the bottom of the board and is offset from the center. Attached is a dimensioned photo. The outer dimension of the connector shell is 0.545" x 0.195". The connector shell needs to flex a bit to accept the locking ramp of its mate, so I'd make the cutout a bit bigger. If the part is going to be machined instead of stamped, you'll need to make it bigger anyway to account for the tool radius at the corners. (The corners of the connector are square.)
This physical layout and the connector are cast in stone. They will not change. What might change, however, is the interface from the board to the rest of the system. The cable illustrated at the top of this thread is made up of parts available from DigiKey. They need to crimp the terminals onto the leads, though, and they charge a fortune for that service. It might actually be less expensive to make an adapter board for each end of a flex or ribbon cable, one of which plugs into the PropCAM, the other plugging into the processor board. I can't yet guarantee that this adapter board wouldn't hang below the 2mm header, though. In one scenario, the PropCAM would plug into an adapter board, which would plug directly into the processor board at a right angle using a single row of 0.1" header pins. If someone wanted the camera board and processor board separated, they would get a 0.1" flex cable from DigiKey with header connectors assembled to the ends (P/N A9CAG-1006F-ND). This increases the overall cost for a cabled configuration, but makes the cost of entry smaller for the PropCAM itself.
I've got a lot of different proto boards with this same footprint (no extra PropCAM boards, though). If you PM me your mailing address, I'll send you one with a connector soldered in place and a lens holder attached.
-Phil
This was made on my LPKF cnc mill. This is the 4th version.
It uses the BOE-Bot chassis and the Propeller demo board.
I think the hard part is going to be routing the cables so they don't get tangled...
Another problem is that the Ping))) header sticks straight up.
Yes, I know the camera is facing the rear. If you turn in around it is really top heavy and tips over [noparse]:([/noparse]
Phil,
· I will send this to you tomorrow.
[noparse][[/noparse]edit Aug 4, 2006]
· Phil has informed me that the PropCam requires all 8 of the I/O pins on the demo board. Leaving NONE for the servos. That would be a pretty useless pan-tilt fixture. So I'm back to the drawing board with the Brian Riley's Propeller board.
Bean.
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap 4-digit LED display with driver IC·www.hc4led.com
Low power SD Data Logger www.sddatalogger.com
"You're braver than you believe, stronger than you seem, and smarter than you think" Christopher Robin to Pooh
Post Edited (Bean (Hitt Consulting)) : 8/4/2006 3:16:21 PM GMT
I don't know if this will help, but...
On a old project I needed to get 4 wires into the upper part of a 360 spinning top. WHat I did was use one of the telephone "untangle" attacments (it attaches between the handset and the handset cord. I out washers and a spring between the upper and lower halves creating a thrust berring type assembly. It was able to rotate indefentally in either direction without the lines getting tangled. Maybe something simular might work?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller + Hardware - extra bits for the bit bucket =· 1 Coffeeless KaosKidd
·
First off, great project.
I am interested in making a camera app, for my other hobby, small bore sillhouette target shooting.
With this, you shoot small steel 'animals'. 5 at a time. 2.5 minutes for the 5 shots.
I would like to make a 'tool' which watches the targets, and records the hits, or misses. and can then display where the target was hit, or the miss went.
Your FPS should be fine. But I would need to boost the standard lens to much bigger. The furthest target is 110 yards, and about 6"x8".
On my rifle I use a 24x scope. so someting similar would be needed for your camera.
Q. Can your cameras be adapted to bigger lenses/spotting scopes so I could get into the 24x+ range?
Thanks and can't wait to buy your camera.
Wow! Interesting app!
Adapting the camera to a longer lens shouldn't be a problem. The longest lenses I've seen that will fit the PropCAM directly are 50mm. But they're expensive, and the field of view at 110 yards would still be a wide 16 feet. The cheapest way might be to craft an adapter that uses the normal lens with a spotting scope. This way, you could make use of the spotting scope's focus mechanism. The other option would be to remove the camera lens and the spotting scope's eyepiece, leaving the scope's objective lens to function as the camera lens. But focussing might be more difficult.
But in any event, I know there's a solution.
-Phil
Thanks for the info. I figured I would need to adapt the spotting scope. The some brands make adapters for digital cameras, (the normal consumer type, not the kind you use.)
My hope was to have the whole setup be small enough so I could mount it on a pan/tilt, and have it move from target to target. (The 5 targets are right next to each other. The PropCam could be adapted to identify the target, and then center it automatically.)
The great thing about this project, is I would have an excuse for my lousy scores. "I was tweaking the code."
The next step is to have the Prop control the rifle, but I think they would think that is cheating.
Do you have a timeframe for the PropCam? This year?
Seth
Oh, heavens yes, this year: a couple months or so at the most. The software is virtually complete. The lens is the main holdup: I'm now going into round two of sampling.
BTW, for your pan/tilt, be thinking, "Heavy base and worm drives."
-Phil
Great!
Another Q.
Can the 'video' be recorded to a ring type buffer? Something like 5 sec of video, so I can replay the shot.
Seth
Five seconds of live video at 30fps would occupy almost 1M byte, which is well beyond the memory capacity of the Propeller. But you could capture the video on your PC and replay it from there.
-Phil
Would it be possible to have another cog write the frames to external memory? SRAM? I don't know if SD cards would be fast enough.
Seth
That's not outside the realm of possibility. Doing it serially would require a 1.5Mbaud data rate, which amounts to 13 Propeller instructions per bit. Of course, there would be some hub-access overhead, too. I haven't really followed the SD card discussions, so I'm not sure what data rate they can sustain. Write-durability might be an issue with SD cards, as well. Parallel access would be quicker, but might entail some special multiplexing hardware to keep the pin count to a minimum.
-Phil
Any way to pull a video signal from firewire?
kelvin
I haven't the foggiest!
-Phil
I've been doing some studying on external ram, and it seems that the technique used here http://www.avrfreaks.net/index.php?module=FreaksTools&func=viewItem&item_type=tool&item_id=318 would work perfectly for this app.
They use a 'ripple counter' chip to address the SRAM locations sequentially. This should be perfect for my 'recording' needs, since I just need to store the frames one after another. This only takes 2 pins for the ram address.
My questions for you are:
1. How many pins are free on the PropCam
2. Could the 'recording' routine be added to your PropCam processing COG code? This way, there should be less overhead comunicating from COG to COG thru the hub.
3. Do you have any object recognition code in the PropCam? To identify a small white chichen? Just kidding on this one... mostly.
Thanks
Seth
I've been thinking along these same lines. My approach would probably use a CPLD instead of discrete ripple counters for maximum flexibility.
To answer your other questions:
1. The PropCAM module uses eight of the Propeller's I/O pins: four for data, and four for control.
2. A better approach might be to parallel the PropCAM's data pins with the external RAM's data pins. That way no cog-to-cog — or even pin-to-pin — transfer is necessary, and fewer pins are used up. I'm still working out the details of how this might be implemented. The acquisition routines are busy enough that two tag-teamed cogs are necessary to keep up.
3. White chicken recognition will be left as an exercize for the user.
-Phil
It would be nice to have a general SRAM interface using a PLD. You could use 3 data lines, one for a clock and two for a mode (00-load, 01-increment, 10-shiftIn0, 11-shiftIn1). The load mode would transfer the shift register to the counter (and outputs). There could be one or two configuration pins that would assign a block of address pins to a decoder (either 2 bit or 3 bit) attached to the appropriate counter bits. This would eliminate the need for a separate decoder. The most significant bit of the counter would disable the decoder if a one. The counter would be initialized to all ones on power up. That would leave any SRAM unselected until the PLD is initialized. Two more control pins for the SRAM (/OE,/WE) would complete the set.
Mike
Post Edited (Mike Green) : 8/4/2006 5:29:09 AM GMT
I think you're on the right track there. My first inclination was to load bytes of the address in parallel from the data bits. But with the CPLD I was considering, I ran out of I/Os. Loading the address serially makes a lot more sense, since the PLD doesn't need to see the data bits, thus saving 8 I/Os. I'm even inclined to load the mode and R/W bits that way, too, to cut down on needed Propeller pins. Then it's just a matter of clocking the data in or out with a single strobe.
What would be nice is a nybble data interface, plus four or fewer control lines. But that entails an extra 4-bit holding register for writes and a quad 2:1 multiplexer for reads which, again, depletes the PLD resources — unless I add discrete logic.
-Phil
That's exactly the same techniques used in my 1984 Psion Organiser One.
Well... Except that it used it to read and write user data to EPROM...
Anyway, it can be made faster and more compact than what you see in that PDF, if you use the same pin that you clock the first counter with also act as A0 on the SRAM.
You may also want to clock the second counter from the Propeller, and not cascade it off the first counter.
(If you need Random access, as it·speeds it up·a lot. )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...