I also started the "glue" route but decided a second Prop to only drive 24 servos and a couple of digital output pins would be simpler. Of course it only uses 2 cogs which is a waste but was much simpler than a half dozen additional decoder/driver chips.
Commodore's 1541·disk drive only had 2K of RAM and they managed a way to have several·disk drives sharing a bus and each·drive listened to the bus.· I'm sure the patents have long been expired but I think the answer is to have a bus and an input / output scheme.··The 1541 drive·would listen and only use the bus when commanded to talk.· It is what I would do.· You could have two pins devoted to the bus and they would operate different devices on the bus.
Mike Green said...
dMajo,
heater is absolutely correct. CMP and SUB are the same instruction with different default settings of WR / NR. They set the flags the same.
The C1541 Bus is "sort of" a I2C bus, you can have more than one device and it will answer when commanded... you can even have I2C at 1 MHz or break the standard a bit and rise the frequency even more... . No need to think of a new protocol...
Yeah, I had hoped they were moving ahead on it. Last I heard IIRC Beau was going to look into fixing the verification software issues, but that was moons ago. Maybe after the shuttle for Prop II is sent off Beau will look into it. Looking back, I think they would have done well in getting MUL and MULS working (4 clock) and maybe ONES and ENC, but I really don't know what they are, and then the 64 I/O pins and call that a Propeller 2. It could be in the same low power technology, and would provide a LOT more calculation power with a real multiplier. With 64 pins(mostly for external memory) and a multiplier would make graphics really rock! Of course, there is a lot of wiz-bang stuff like texturing in the P2 in the works, but I have been anxious. I may be annoying on this subject, but I REALLY do appreciate what parallax does.
As long as it has more cogs, that's the key. Double the number is good. Ten times more is better. I'll take a cut in speed if required to accomplish it.
I have a project that uses 62 IOs, and 10 cogs. If I combined the project into one propeller, I could combine 3 of the cogs. I have to run on batteries at times, so a single propeller (and less cogs) would mean less power, and even if the 64 IO propeller were double the cost, it would be cheaper than my current setup because there are less BOM parts for assembly.
Multiplying the number of COGs by 10 has the effect of dividing the access speed to shared HUB RAM by 10. Some would say this is not a good outcome.
As the number of COGs goes up overall performance can go down. In the limit there is a infinite number of COGs that have to wait an infinite amount of time for any HUB access. Overall performance drops to zero!
Where the "sweet spot" is re the number of CPU's sharing RAM is, is a matter of debate.
A while back Chip did pose the question here "more COGs or more RAM for Prop II" I think the majority were speaking up for more RAM with the above thoughts in mind.
Comments
(Edited to clarify)
Post Edited (Chuckz) : 10/1/2009 3:33:11 AM GMT
(There was once a rock band that thought "10" wasn't loud enough, so they got knobs that went up to eleven.)
Over the years they went from "parody" to serious reality. But then in the rock/pop world I find it hard to tell the difference quite often anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
i did not know that the picture on 2:18 of this video is an insider like "42".
LOL-ROFL. Here you can see what happens if you screw the knob to eleven
best regards
Stefan
CMP_C: D<S········· SUB_C: overflow
It not seems to me that the two instructions sets the flags the same way, or am I wrong?
@All
If the IO timing is not critical, they are not used directly in code (eg. as pointers, byte/word values); than an I2C IO expander can do the job. Beside the traditional solutions [url=http://www.nxp.com/#/pip/pip=[pip=PCA9672_2]|pp=[t=pip,i=PCA9672_2]]PCA9672[/url]/[url=http://www.nxp.com/#/pip/pip=[pip=PCA9673_1]|pp=[t=pip,i=PCA9673_1]|]3[/url]/[url=http://www.nxp.com/#/pip/pip=[pip=PCA9674_PCA9674A_5]|pp=[t=pip,i=PCA9674_PCA9674A_5]]4[/url]/[url=http://www.nxp.com/#/pip/pip=[pip=PCA9675_1]|pp=[t=pip,i=PCA9675_1]]5[/url] there is also the [url=http://www.nxp.com/#/pip/pip=[pip=PCA9698_2]|pp=[t=pip,i=PCA9698_2]]PCA9698[/url](40 I/O) and the Cypress CY8C9520A/40A/60A (20/40/60 IO with programable state retention between power/reset cycles and hardware pwm).
Quiet sure (because of the prop's boot nature) there is a I2C driver available in nearly every program so it is enough to attach these ICs on the eeprom's I2C bus
PEDIT: Also TI TCA6424 (24 IOs) is nice
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates);·· Vaati's custom search
Post Edited (dMajo) : 10/1/2009 10:22:55 AM GMT
When D == S, D - S == 0. When D < S, D - S results in an unsigned overflow (underflow). So the conditions really are the same.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates);·· Vaati's custom search
Thanks,
Doug
Doug
I have a project that uses 62 IOs, and 10 cogs. If I combined the project into one propeller, I could combine 3 of the cogs. I have to run on batteries at times, so a single propeller (and less cogs) would mean less power, and even if the 64 IO propeller were double the cost, it would be cheaper than my current setup because there are less BOM parts for assembly.
Multiplying the number of COGs by 10 has the effect of dividing the access speed to shared HUB RAM by 10. Some would say this is not a good outcome.
As the number of COGs goes up overall performance can go down. In the limit there is a infinite number of COGs that have to wait an infinite amount of time for any HUB access. Overall performance drops to zero!
Where the "sweet spot" is re the number of CPU's sharing RAM is, is a matter of debate.
A while back Chip did pose the question here "more COGs or more RAM for Prop II" I think the majority were speaking up for more RAM with the above thoughts in mind.
to continually switch programs from the SD card.
We use a couple 16 bit, I2C I/O chips for our low speed devices,
they only cost $1.20 each.