@kuroneko - The wave player should have been just fine except for the needed extra delay that you previously mentioned. However, unless it is just a faulty cable, which I highly doubt, this is really going to be a !&*)?^*. I will get back to you and let you know what I find. It may be a while, but I will let you know. It is probably a stray piece of solder that I missed. Thanks for your help and guidance Marko. I definitely appreciate it.
On a another note, I bought all the materials and packaging that I need for a good size production run. Like I told you before, if this works out for me, I won't forget about you. My project has come a long way with your help and the help of a few others. Over the past several months, I have been doing several modifications to increase machine speed. I have not been able to do a serious test for a couple weeks now, but the machine should now be capable of producing one unit every 4-5 seconds. Thats between 17,000-20,000 units per day. Over the last month, it has changed enormously and it is really turning out to be a nice machine. I am naming it "The Gift" out of respect to the God that I believe in, because I can't believe that I came up with this all on my own.
Odd. Where is the low coming from? Any chance to scope the input? Or at least measure the voltage level? I'd have thought that the pullup is stronger than an unpowered prop pin ... what about noise on the line?
Just for fun, can you run this follower (the LED probably stays dark):
dira[16]~~
repeat
outa[16] := ina[4]
Also, what happens when you power the proto-board and drive the pin high?
That simply tells us that something is pulling the line low. Any info regarding voltage when attached? What about driving pin 10 from the proto-board?
...could cause a short circuit if the other is driven low.
If you only ever drive pin 10 and leave pin 4 alone (always input) then there is no problem. What I'm trying to get at here is: the slave has a pullup on pin 4 so someone else can drive said input (either high or low). The problem ATM is that it registers a low without (apparently) being driven. I'm trying to figure out whether driving the pin high explicitly will overcome this ghost low.
Just in case, you could add a serial resistor to the cable in order to limit potential short damage.
CON
_CLKMODE = XTAL1 + PLL16X
_XINFREQ = 5_000_000
PUB Main
OUTA[16]~ ' Note: Changed from Pin10 for easier access during testing
DIRA[16]~~
With no cable attached to the slave, the LED turns on.
OK. Expected.
With cable attached and the master unpowered the light goes off.
With cable attached and the master powered the light goes on
Is the master running anything? Just checking because the above program will briefly pull outa[16] low and then the cog will shutdown (leaving all the work for the pullup again). What I don't get is why an unpowered proto-board will have enough juice to pull the line low. Is that the USB version with the cable plugged in?
Just for completeness, can you let the master generate pulses and check with an LED at the other end of the cable (LED playing pin 4)?
Also, as powering the master seems to indicate that the pullup does its job, what about adding the pulse generator again?
CON
_CLKMODE = XTAL1 + PLL16X
_XINFREQ = 5_000_000
PUB Main
DIRA[4]~
REPEAT
IF NOT INA[4]
DIRA[16]~~
OUTA[16]~~ 'Shine brightly my beautiful LED
WAITCNT(CLKFREQ + CNT)
OUTA[16]~
This test was performed with the new spare Protoboard.
Results:
The LED lit up for 1 second every 5 seconds, just as programmed.
The LED remained lit up if the cable was plugged into the master without the master having power.
A little progress. While you think about you response, I am going to put the test code into the "true master" (Interface board) and see what happens.
@kuroneko - Oddly enough the following code does not work at all.
Slave:
CON
_CLKMODE = XTAL1 + PLL16X
_XINFREQ = 5_000_000
VAR
LONG LED_Cog
LONG Stack[64]
PUB Main
DIRA[4]~
REPEAT
IF NOT INA[4]
LED_Cog := COGNEW(ShineBrightly, @Stack) + 1
WAITCNT(CLKFREQ / 50 + CNT)
PUB ShineBrightly
DIRA[16]~~
OUTA[16]~~ 'Shine brightly my beautiful LED
WAITCNT(CLKFREQ + CNT)
OUTA[16]~
I assume it is because Pin 4 on the slave is pulled low at startup and it trys to run multiple cogs. I am beginning to think that I should have used a pulled down on the slave and went high with the master.
@kuroneko - Realistically I don't believe I should have to do that. Why is that pin going low with just the cable plugged into an unpowered board? Is the resistor value correct?
I'm as baffled as you are. The busy flag is just to protect you from re-using the stack before it's released again (cog stopping) and this is only an issue when the pulse is too long (i.e. when you have a chance that multiple effects are started). As for the pullup, the demoboard uses 10k. Maybe try half (4k7). BTW, is it the USB version of the board?
The master only sends a new pulse every 5 seconds, during which time the slave waits well past the signal time. Additionally, starting, running, and stopping the cog should be completed way before 5 seconds have elapsed. That is the only thing it can be.
The master only sends a new pulse every 5 seconds, during which time the slave waits well past the signal time. Additionally, starting, running, and stopping the cog should be completed way before 5 seconds have elapsed. That is the only thing it can be.
The point is that the SPIN task is kept alive for about a second and cognew only has a granularity of 1/50 sec. Meaning if I have a 1/10 sec low pulse the cognew part is executed several times within the one second keep-alive-period. You'd have to make sure that the task exits before another cognew can come around (and trash the stack).
Remember, cognew returns almost immediately.
Update: But I see what you're getting at (1/50 vs 1/100). It's getting late here Does it work under simulation?
Standard meaning serial in this case (given that you can get serial and USB versions)? Did you do any measurements re: voltage on pin 10 (unpowered)? The low has to come from somewhere.
LOL No it does not work under simulation, if it did, the problem would be solved I believe the voltage on the unpowered pin was 0.001 volts. Go to bed and get some my friend. I will probably go get and optoisolator, add it on and be done with it. Thanks for your help Marko.
@kuroneko - Ah ha. So the pullup goes on the sender instead of the receiver.
And since you said this:
and it just works
I assume it just barely completes everything in the 5 second time span? And since you have .9 secs., should I further assume that my 2 second wav file just won't cut it?
This sample is an outline for one propeller chip to signal another propeller chip.
For those of you that do not know how to do this, please do not try my previous attempts, they were a huge waste of time and provided many hours of frustration. The solution is to wire it and treat it exactly like a pushbutton. Please look at the code for both Master and Slave, and also look at the schematic.
For those of you who knew I was having a problem and knew how to solve the problem, and did not say anything, well you already know my opinion of you.
Comments
On a another note, I bought all the materials and packaging that I need for a good size production run. Like I told you before, if this works out for me, I won't forget about you. My project has come a long way with your help and the help of a few others. Over the past several months, I have been doing several modifications to increase machine speed. I have not been able to do a serious test for a couple weeks now, but the machine should now be capable of producing one unit every 4-5 seconds. Thats between 17,000-20,000 units per day. Over the last month, it has changed enormously and it is really turning out to be a nice machine. I am naming it "The Gift" out of respect to the God that I believe in, because I can't believe that I came up with this all on my own.
Bruce
- New spare Protoboard with identical connections on the board (Pin 10, etc...)
- New cable
Test Code:CON _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 PUB Main REPEAT IF NOT INA[4] DIRA[16]~~ OUTA[16]~~ 'Shine brightly my beautiful LED WAITCNT(CLKFREQ / 1 + CNT) OUTA[16]~ WAITCNT(CLKFREQ * 5 + CNT)Results:
With the cable plugged into the new Protoboard and without providing power to the Protoboard, the LED flashes.
Bruce
Just for fun, can you run this follower (the LED probably stays dark):
dira[16]~~ repeat outa[16] := ina[4]Also, what happens when you power the proto-board and drive the pin high?CON _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 PUB Main dira[16]~~ repeat outa[16] := ina[4] { REPEAT IF NOT INA[4] DIRA[16]~~ OUTA[16]~~ 'Shine brightly my beautiful LED WAITCNT(CLKFREQ / 1 + CNT) OUTA[16]~ WAITCNT(CLKFREQ * 5 + CNT) }The LED lights up without being attached to the protoboard and does not light up when attached to the protoboard
If you only ever drive pin 10 and leave pin 4 alone (always input) then there is no problem. What I'm trying to get at here is: the slave has a pullup on pin 4 so someone else can drive said input (either high or low). The problem ATM is that it registers a low without (apparently) being driven. I'm trying to figure out whether driving the pin high explicitly will overcome this ghost low.
Just in case, you could add a serial resistor to the cable in order to limit potential short damage.
SLAVE
CON _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 PUB Main dira[16]~~ repeat outa[16] := ina[4] { REPEAT IF NOT INA[4] DIRA[16]~~ OUTA[16]~~ 'Shine brightly my beautiful LED WAITCNT(CLKFREQ / 1 + CNT) OUTA[16]~ WAITCNT(CLKFREQ * 5 + CNT)MASTER
With no cable attached to the slave, the LED turns on.
With cable attached and the master unpowered the light goes off
With cable attached and the master powered the light goes on
Is the master running anything? Just checking because the above program will briefly pull outa[16] low and then the cog will shutdown (leaving all the work for the pullup again). What I don't get is why an unpowered proto-board will have enough juice to pull the line low. Is that the USB version with the cable plugged in?
Just for completeness, can you let the master generate pulses and check with an LED at the other end of the cable (LED playing pin 4)?
Also, as powering the master seems to indicate that the pullup does its job, what about adding the pulse generator again?
Here is the new scenario!
Identical setup to interface board (MASTER), back to using Pin 10 for signaling.
Master Code:
CON _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 PUB Main REPEAT OUTA[10]~ DIRA[10]~~ WAITCNT(CLKFREQ / 100 + CNT) DIRA[10]~ WAITCNT(CLKFREQ * 5 + CNT)Slave Code:
CON _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 PUB Main DIRA[4]~ REPEAT IF NOT INA[4] DIRA[16]~~ OUTA[16]~~ 'Shine brightly my beautiful LED WAITCNT(CLKFREQ + CNT) OUTA[16]~This test was performed with the new spare Protoboard.
Results:
- The LED lit up for 1 second every 5 seconds, just as programmed.
- The LED remained lit up if the cable was plugged into the master without the master having power.
A little progress. While you think about you response, I am going to put the test code into the "true master" (Interface board) and see what happens.Bruce
Slave:
CON _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 VAR LONG LED_Cog LONG Stack[64] PUB Main DIRA[4]~ REPEAT IF NOT INA[4] LED_Cog := COGNEW(ShineBrightly, @Stack) + 1 WAITCNT(CLKFREQ / 50 + CNT) PUB ShineBrightly DIRA[16]~~ OUTA[16]~~ 'Shine brightly my beautiful LED WAITCNT(CLKFREQ + CNT) OUTA[16]~Master:
CON _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 PUB Main REPEAT OUTA[10]~ DIRA[10]~~ WAITCNT(CLKFREQ / 100 + CNT) DIRA[10]~ WAITCNT(CLKFREQ * 5 + CNT)I assume it is because Pin 4 on the slave is pulled low at startup and it trys to run multiple cogs. I am beginning to think that I should have used a pulled down on the slave and went high with the master.
Bruce
The master only sends a new pulse every 5 seconds, during which time the slave waits well past the signal time. Additionally, starting, running, and stopping the cog should be completed way before 5 seconds have elapsed. That is the only thing it can be.
Remember, cognew returns almost immediately.
Update: But I see what you're getting at (1/50 vs 1/100). It's getting late here
Standard meaning serial in this case (given that you can get serial and USB versions)? Did you do any measurements re: voltage on pin 10 (unpowered)? The low has to come from somewhere.
Bruce
CON _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 VAR LONG LED_Cog LONG Stack[64] PUB Main cognew(Master, @Stack[32]) REPEAT IF NOT INA[24] LED_Cog := COGNEW(ShineBrightly, @Stack{0}) + 1 WAITCNT(CLKFREQ / 50 + CNT) PUB ShineBrightly DIRA[16]~~ OUTA[16]~~ 'Shine brightly my beautiful LED WAITCNT(CLKFREQ/3 + CNT) OUTA[16]~ WAITCNT(CLKFREQ/3 + CNT) OUTA[16]~~ 'Shine brightly my beautiful LED WAITCNT(CLKFREQ/3 + CNT) OUTA[16]~ PUB Master REPEAT OUTA[24]~ DIRA[24]~~ WAITCNT(CLKFREQ / 100 + CNT) DIRA[24]~ WAITCNT(CLKFREQ * 5 + CNT) DATCatch you tomorrow.And since you said this: I assume it just barely completes everything in the 5 second time span? And since you have .9 secs., should I further assume that my 2 second wav file just won't cut it?
This sample is an outline for one propeller chip to signal another propeller chip.
For those of you that do not know how to do this, please do not try my previous attempts, they were a huge waste of time and provided many hours of frustration. The solution is to wire it and treat it exactly like a pushbutton. Please look at the code for both Master and Slave, and also look at the schematic.
For those of you who knew I was having a problem and knew how to solve the problem, and did not say anything, well you already know my opinion of you.
Master Code:
CON _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 PUB Main DIRA[10]~~ REPEAT OUTA[10]~~ WAITCNT(CLKFREQ / 100 + CNT) OUTA[10]~ WAITCNT(CLKFREQ * 5 + CNT)Slave Code:
CON _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 VAR LONG LED_Cog LONG Stack[64] PUB Main DIRA[8]~ REPEAT IF INA[8] LED_Cog := COGNEW(ShineBrightly, @Stack) + 1 WAITCNT(CLKFREQ / 50 + CNT) PUB ShineBrightly DIRA[16]~~ OUTA[16]~~ 'Shine brightly my beautiful LED WAITCNT(CLKFREQ + CNT) OUTA[16]~Well there you have it. It works for me.
Bruce