Question Propeller
Discovery
Posts: 606
What "C" program Instructions should I use to set the I/O direction registers for COG#0 and COG#1 so that:
COG#0:
P0 through P7, P12 and P13 are OUTPUTS
P14 through P20 are INPUTS
COG#1:
P8 through P11 are OUTPUTS
P21 though P24 are INPUTS
Sincerely,
Discovery
COG#0:
P0 through P7, P12 and P13 are OUTPUTS
P14 through P20 are INPUTS
COG#1:
P8 through P11 are OUTPUTS
P21 though P24 are INPUTS
Sincerely,
Discovery
Comments
I think you can do this using the high() and low() functions. If this is so, you should be able to do this in each method that is used when you start a new cog.
Below is an example of setting P10 to high ( output ).
Hope this helps,
ValeT
void high(int pin) // high function definition { int mask = 1 << pin; // Set up mask OUTA |= mask; // Bitwise OR w/ OUTA & DIRA DIRA |= mask; }If you just want to set the output direction for a set of pins you can do something like this:DIRA |= (1 << 13) | (1 << 12) | (1 << 7); DIRA |= (1 << 24) | (1 << 23) | (1 << 22) | (1 << 21);If you want to do this on different cogs you need to execute this from code running on the appropriate cogs.The documentation for simpletools.h is located here:
https://propsideworkspace.googlecode.com/hg-history/029efb9bf270758003c0a67571d1cbe4cc9986b5/Learn/Simple%20Libraries/Utility/libsimpletools/Documentation%20simpletools%20Library.html
There are a number of commands described in the documentation that control the input or output state of the I/O pins, depending on whether you are setting an individual pin:
Or setting a contiguous group of pins:
You would use the statement in the code run by the specific cog. 1 = out, 0 = in.
As long as the I/O pins are unique to each cog (as in your example), it's straightforward.
The direction register of all the active cogs are ORed. So if multiple cogs share pins, any cogs setting direction to output (1) have precedence, and all active cogs must be set to input to change it to input. The same with the output value. If any cogs set high the pin is high until all active cogs set it to zero. Shutting down a cog resets both its direction and value (0) essentially removing it from influencing the pins.
Tom
I use the "high" and "low" commands on four pins in COG#1 to turn a stepper motor and use two sets of four in COG#0 to turn two stepper motors.
What I find is in COG#1 the square waves on the pins act as if they are floating. The amplitures will change from a nice square top to a noisy ripple and drop in voltage until the wave is gone. It happens on all four pins but not at the same time. These stepper signals from the Propeller feed HEXFETs that drive the stepper motors. The first indication of trouble was while the stepper was turning nicely...it began to fibrilate and jerk. Looking at the scope on the four signals from the Propeller showed the loss of one signal, then another, then another. Why?
I can touch the wire leading from the Propeller to the breadboard where the HEXFETs are located and can cause the output signals to re-appear momentarily. These are signals comming right off the Propeller Activity Board.
Discovery
I found the problem. Deep in the COG#1 code is a pause(3) command that inadvertently had a space between the e and the (. The compiler did not catch this type-O as an error so the the program ignored the pause which allowed the I/O high and low commands to execute very rapidly. At times, the signals disappeared then re-appeared.
Taking out the space error the pause became a command and the code ran correctly. I never thought that the loss of the pause command would cause the problem.
Problem solved...thank you for your help.
Discovery
Further work found that I/O p(8) is defective on my Propeller Activity Board. The pin drifts...sometimes outputting the square wave and other times not, This pin was used as the sync for all the instrumentation instruments and as such produced the problems reported earlier.
Discovery
Propeller I/O pins can be damaged but I've never heard of one sometimes working and other times not working. In my experience they either work or don't work.
There are lots of ways to make a pin appear not to work with bug in the code. If you post your complete code, others may be able to find the problem.
I switched the synchroniztion output squarewave from P(8) to P(9) and the Plasma Cutter system functions properly. As a test, I sent the same sync signal out on both P(8) and P(9). An insulated wire was inserted into the P(8) socket and monitored on the scope. Just squeezing the insulated wire between my fingures would cause the signal to drop in amplitude and disappear. After a few minutes the signal would reappear. This property is not exhibited on any of the other I/O pins. P(8) is not used in any other COG.
My conclusion is that the propeller IC P(8) I/O on my Activity Board is defective.
Discovery
After transcribing the "C" program into the post, the software notified me that I was no longer signed in and would not save the posting. I was able to copy the posting and enter it again but it contained all the line control characters. I have no idea how to extract the post from the line control characters. If you folks at Parallax can do it...please do.
Otherwise, I will have to make another attempt later.
Discovery
Not so fast! Additional monitoring of signals on the scope showed that P(9), P(10), P(11), and P(12) also exhibit the same issue as the last reported problem with P(8). Because of extenuating circumstances, the "C" code cannot be uploaded over the internet to you for evaluation, so the next best option is to transcribe portions of the extensive code that are germane to the problem at hand. Three sets of four (four phase) pulse trains are generaed by the propeller activity board. Two of the four phase sets feed HEXFETs that drive two stepper motors and the signals are generated out of the main COG program and they do not exhibit any instabiity problems. The X and Y axes move smoothly with no problems. However, the Z axis set of four phase signal trains also feed HEXFETs that drive a single stepper motor and are generated in another COG as shown below. I/O that are set HIGH and LOW in the Zaxis COG are unstable. Randomly unstable.
I will try to hand transcribe the code and not introduce errors. By the way, the code compiles with no errors and runs. Sometimes one or two of the Zaxis motor phase signals stop operating as monitored at the output of the propeller.
/*
Plasma Cutter Code(4) ***2014/11/2***
Added the ADC Code
COG(0) and COG(1) work but four phase
outputs are not stable
ADC works
Modified the ZaxisControl
*/
#include"simpletools.h"
#include"propeller.h"
#include"stdio.h"
#include"math.h"
#include"stdlib.h"
#include"adcDCpropab.h"
int i, A,B,C,E,Q,R,L;
int X_AxisLimit;
int Y_AxisLimit;
int Z_AxisLimit;
int SlewX_AxisMinus;
.
.
.
int BeginOps;
int StopProcess;
int TriggerState;
.
.
.
float ScaleFactor=773.731;
.
.
.
void Zaxis(void* par);
unsigned int stack[40+25];
main()
{
cogstart(&Zaxis,NULL,stack, sizeof(stack));
BeginOps=1;
zeroDrivers();
do
{
.
.
.
}
void Zaxis(void * par)
{
adc_int(21, 20, 19, 18);
float v2;
while (BeginOps==1)
{
v2 = adc_volts(2);
if(v2<1.8)
{
StepperControlM3();
ZaxisPlusControl();
}
if(v2>2.0)
{
StepperControlM3();
ZaxisMinusControl();
}
}
}
StepperControlM3()
{
pause(3);
if(s==0)
{
high(9),low(10),low(11),low(12);
}
if(s==1)
{
high(9),high(10),low(11),low(12);
]
if(s==2)
{
low(9),high(10),low(11),low(12);
if(s==3)
{
low(9),high(10),high(11),low(12);
}
if(s==4)
{
low(9),low(10),high(11),low(12);
}
if(s==5)
{
low(9),low(10),high(11),high(12);
}
if(s==6)
{
low(9),low(10),low(11),high(12);
}
if(s==7)
{
high(9),low(10),low(11),high(12);
}
}
ZaxisPlusControl()
{
if(s==7)
{
s=0;
}
else
{
s=s+1);
}
return(s);
}
ZaxisMinusControl()
{
if(s==0)
{
s=7;
}
else
{
s=s-1);
}
return(s);
}
Discovery
What is next?
Discovery
You can just cut and paste code into the post edit box and then put "[ code ]" at the top and "[ /code ]" at the bottom. But without the spaces I have shown there, obviously if I did that it would create a code block out of what I am trying to say.
Or go to "advanced edit", paste your code in there, then highlight it, then hit the "#" button.
You just gotta know how is all.
Discovery
How do you know the program is running and outputting square waves on P(0) through P(7) before attaching the scope?
How do you know the program is running at all, do you have other LEDs flashing or serial output or what?
Do you have your scope ground connected to the same ground as the Propeller?
I have had all kinds of problems with the Prop resetting when attaching lengths of wire, with nothing on the other end, to the reset pin. Usually cured with pullup resistors and capacitors on the reset pin.
But never a problem with an actual IO pin. Certainly a scope probe should not be an issue.
Discovery
My four channel digital scope had three channels observing three phases of the Xaxis outputs and readying the fourth channel to observe one phase of the Yaxis output signal when attaching a short lead wire to the output caused the problem...the scope probe was not yet attached to the wire. In addition, yellow LEDs on the board are turned on by P(26) and P(27) when the program is running.
A common single point ground is used for the propeller board, power supply, scope, and other instruments.
The reset pin was not involved in this incident.
Discovery
If the pin really is configured as an output it is hard to see how this can be.
Do you have pictures of this set up?
Does the problem move around as you change scope leads from pin to pin?
The same "C" code running on the propeller activity board was loaded and run on the 40 pin DIP version of the propeller.
All the stepper motor drive signals are correct for output pins P(0) through P(7). The generation of the signals uses the same code as that shown for the Zaxis stepper in this thread above.
The signals for P(9), P(10), P(11), and P(12) however show on the four channel scope that P(9) goes from low to high and stays high, P(10) and P(11) toggle correctly, and P(12) goes from low to high and stays high. The code was run many times and the same pattern persists.
I suspect that setting up the new COG to run the Zaxis code is insufficient in some manner. I notice in the "C" code manual that there are several commands for the COG including COG_RUN, COG_START and there are examples of starting a new COG that are very different depending upon who wrote the code.
I used example code to write my new COG but I don't know the details of how the propeller sets up the functional space. I changed the stack size to double with no change in the outputs.
Would someone please write the new COG start code and I will load it into the 40 pin DIP version of the propeller to test it?
Sincerely,
Discovery
Do you have an decoupling caps? Do you have all the power and ground pins connected?
Also, it is very difficult to try to debug your code without seeing the whole program. If you can't post the whole thing at least post a subset of the code that we can test on our own hardware platforms.
All power and ground pins are connected and bypassed.
If you read the thread above you will find that the same code runs on the Propeller Activity Board and similar problems are observed.
As a test of the Zaxis COG, instead of calling the StepperControlM3() function and the ZaxisPlusControl() function and the ZaxisMinusControl() from the Zaxis COG I pulled the code into the Zaxis COG and ran the program. Three outputs now toggle properly...P(11) went from low to high and stays at high.
Clearly the problem is not power and grounds. The problem resides, I feel, in the setup of the Zaxis COG.
A subset of the code in question was posted earlier in this thread which you can find on page 1.
Sincerely,
Discovery