I'm not quite sure what you have been trying to do but while I2C is good for talking to slave chips such as EEPROMs and A/D etc, it's not good for talking to another Prop since the slave software is awkward without any kind of basic hardware support. Same too with SPI.
I find the best interface is serial and for many purposes you really only need a single half-duplex line if the communications is in the form of command/response. There are many examples of all kinds of serial drivers on the forum and the obex and in the C libraries. Rather than how you think you might achieve it perhaps the important question is "what are you trying to achieve"?
I have tried and tried for more than a year and many people say it works(serial ) but I cannot get to work. I think they are withholding important info. With arduino I had luck with I2C. But I had Issues with delaying The loop.I thought That the16MHz speed was to fast. I thinnk that SPI might work if I use Shift_in and Shift_out but I dont know about the registers, maybe using buffers. There are only four bytes for four variables. Let me know if you want the two programs.
You should really try to listen and start with standard setups.
My guess is that you still do not run the P1 at its 'standard' 80Mhz, thus your problem with serial. This might be your important info you are missing.
So instead of switching to I2C SPI or anything else, just get serial running, then start to write your program around it.
As far as the serial I have output on Flip1 reading values and numbers on the serial monitor at 5MHz but I have no input an Flip 2. I read a package on pin31 with my scope but thats as far as it goes. Two of my flips quit reprogramming . Have to wait for new ones
There is a problem with the P1 loader in that if you have a program that transmits continually will cause a problem when the loader resets the P1 and waits for a response after a query, but the PC FIFO buffer is still full of junk that doesn't (but should) get cleared. The workaround here is to hold your P1 in reset and just before you press the F11 to download the code, release the reset button.
There is nothing wrong with your P1 boards. BTW, stop trying to slow it down, leave it at 80MHz. Serial works, always has, always will, but you are the one having the problem then you are the one that needs to provide full information, that is, all your code, your setup, any photos that may help etc. Then, and only then can we see or try out what you have done and go "aha! that is your problem".
Yeah, there's no "withholding" of anything.
My first MCU was the Prop development board + Bluetooth module. I wanted to try communicating with my Android tablet. Had no clue about Spin and so I cut/pasted from examples and it was up and running instantly. Spent the rest of the day playing with the Android code.
I have changed the Freq to your requested 80MHz. System still a slow pulse on the R.A. motor which is good but still no serial at input. Sending codes.
You still had PLL1x mode. Here is a slightly modified version of your code that works and included a test pulse output plus some diagnostics on the serial port.
Here's a scope capture:
1. Yellow = test pulse at 50Hz
2.
3. NS DIR
4. NS PULSE
What is "longcon" in your code?
You did --nav to init this variable which only predecremented it. You needed nav~~ to set it to all 1's since you were &= to latch them low.
EDIT: I've just come back to look at this again as I didn't have much time before. Here is your version fixed up although I don't see where you use the "serial" function.
EDIT: removed my test version and replaced this code with the original + fixes
''Telescope test 2b
con {timing}
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
CLK_FREQ = 80_000_000
MS_001 = CLK_FREQ / 1_000
US_001 = CLK_FREQ / 1_000_000
con { io pins }
RX1 = 31 {I}
TX1 = 30 {O}
SDR1 = 29 {I/O}
SCL1 = 28 {I/O}
con {user io}
NS_PLS = 16
NS_Dir = 15
EW_PLS = 14
EW_Dir = 13
BTN_N = 7
BTN_E = 6
BTN_S = 5
BTN_W = 4
con {navigation}
NORTH = %1000
EAST = %0100
SOUTH = %0010
WEST = %0001
#0, GO_NORTH, GO_SOUTH
#0, GO_EAST, GO_WEST
CYCLE_TIX = CLK_FREQ / 50
MOVE = MS_001 * 15
MOVES = US_001 * 1950
STOP = 0
con
#true, on, off
#false, no, yes
var
long nspulse
long ewpulse
obj
ser: "fullDuplexSerialPlus"
pub main | t, nav
setup
ser.start(31, 30, 0, 115200)
t := cnt
repeat
nav :=scan_nav_buttons(5)
case nav
NORTH :
nspulse := MOVE
outa[NS_Dir] := GO_NORTH
ewpulse := STOP
EAST :
ewpulse := MOVE
outa[EW_Dir] := GO_EAST
nspulse := STOP
SOUTH :
nspulse := MOVE
outa[NS_Dir] :=GO_SOUTH
ewpulse := STOP
WEST :
ewpulse := MOVE
outa[EW_Dir] := GO_WEST
nspulse := STOP
other :
ewpulse := MOVES
outa[EW_Dir] := GO_WEST
nspulse := STOP
phsa := -nspulse
phsb := -ewpulse
waitcnt (t += CYCLE_TIX)
pub scan_nav_buttons(ms) : nav | t
nav~~
t := cnt
repeat ms
waitcnt(t += MS_001)
' BUTTONS ARE ALL IN ORDER - JUST READ IN AS A GROUP
nav &= ina[BTN_N..BTN_W]
' nav &= (ina[BTN_N] << 3) | (ina[BTN_E] << 2) | (ina[BTN_S] << 1) | ina[BTN_W]
pub setup
outa := $00000000
dira := $00000000
ctra := %00100 << 26 | NS_PLS
frqa := 1
phsa := STOP
dira[NS_PLS] := 1
dira[NS_Dir] := 1
ctrb := %00100 << 26 | EW_PLS
frqb := 1
phsb := STOP
dira[EW_PLS] := 1
dira[EW_Dir] := 1
pub serial
repeat
ser.str(string( "value1 :" ))
ser.Dec( EW_PLS )
ser.str(string( "value2 :" ))
ser.Dec( EW_Dir )
ser.str(string( "value3 :" ))
ser.Dec( NS_PLS )
ser.str(string( "value4 :" ))
ser.Dec( NS_Dir )
ser.Tx(13)
nspulse := ser.Getlong
outa[NS_Dir] := ser.Getlong
ewpulse := ser.Getlong
outa[EW_Dir] := ser.Getlong
Program I sent was not updated to pll16x but was tested at 80MHz. Same as last . There was no data on the serial terminal indicating receipt of information from first controller. The data on your scope is the test data from the camera controlled circuits. I still need to see if the serial is receiving any data.
Serial data works but you should always post exactly the same code. In the zip file I have my test version and the startup message should display on your terminal. It all worked first time when I tested it. Send the exact code through again with those adjustments and I will test it.
BTW - Your code was not sending serial data anywhere. The "serial" routine was not being called and nowhere else were you sending data. That's why it's always a good idea to put in a startup message.
A zip file is a zip file and I'm not aware of anything that can't open it so it seems very strange already since you obviously have something that compiles the Prop code.
However, lacking your current version which you still haven't sent, here is one that will produce an output although you still need to call your "serial" routine from inside main if you want that to work.
If you ever want any real help you need to say what you can and can't do, what you do and you don't have and know etc. If you are upfront you will save yourself and others a lot of wasted time.
'Telescope test 2b
con {timing}
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
CLK_FREQ = 80_000_000
MS_001 = CLK_FREQ / 1_000
US_001 = CLK_FREQ / 1_000_000
con { io pins }
RX1 = 31 {I}
TX1 = 30 {O}
SDR1 = 29 {I/O}
SCL1 = 28 {I/O}
con {user io}
' Using some I/O in the 0...15 that I can access
NS_PLS = 15 '16
NS_Dir = 14 '15
EW_PLS = 13 '14
EW_Dir = 12 '13
BTN_N = 7
BTN_E = 6
BTN_S = 5
BTN_W = 4
'setup a test pulse output
tp = 0
con {navigation}
NORTH = %1000
EAST = %0100
SOUTH = %0010
WEST = %0001
#0, GO_NORTH, GO_SOUTH
#0, GO_EAST, GO_WEST
CYCLE_TIX = CLK_FREQ / 50
MOVE = MS_001 * 15
MOVES = US_001 * 1950
STOP = 0
con
#true, on, off
#false, no, yes
var
long nspulse
long ewpulse
obj
ser: "fullDuplexSerialPlus"
pub main | t, nav
setup
dira[tp]~~
ser.start(31, 30, 0, 115200)
ser.str(string(13,10," Telescope test "))
t := cnt
repeat
!outa[tp] ' toggle the test pulse[s][/s]
nav :=scan_nav_buttons(5)
' prints out the current nav variable on the same line (no linefeed)
ser.tx(13)
ser.hex(nav,1)
case nav
NORTH :
nspulse := MOVE
outa[NS_Dir] := GO_NORTH
ewpulse := STOP
EAST :
ewpulse := MOVE
outa[EW_Dir] := GO_EAST
nspulse := STOP
SOUTH :
nspulse := MOVE
outa[NS_Dir] :=GO_SOUTH
ewpulse := STOP
WEST :
ewpulse := MOVE
outa[EW_Dir] := GO_WEST
nspulse := STOP
other :
ewpulse := MOVES
outa[EW_Dir] := GO_WEST
nspulse := STOP
phsa := -nspulse
phsb := -ewpulse
waitcnt (t += CYCLE_TIX)
pub scan_nav_buttons(ms) : nav | t
nav~~ ' IMPORTANT - set nav to 1's (the double tilde is short for set, the single tilde is clear)
t := cnt
repeat ms
waitcnt(t += MS_001)
' read group of buttons in from msb...lsb
nav &= ina[BTN_N..BTN_W]
pub setup
outa := $00000000
dira := $00000000
ctra := %00100 << 26 | NS_PLS
frqa := 1
phsa := STOP
dira[NS_PLS] := 1
dira[NS_Dir] := 1
ctrb := %00100 << 26 | EW_PLS
frqb := 1
phsb := STOP
dira[EW_PLS] := 1
dira[EW_Dir] := 1
''''''''''''''''' WHERE IS THIS USED?
pub serial
repeat
ser.str(string( "value1 :" ))
ser.Dec( EW_PLS )
ser.str(string( "value2 :" ))
ser.Dec( EW_Dir )
ser.str(string( "value3 :" ))
ser.Dec( NS_PLS )
ser.str(string( "value4 :" ))
ser.Dec( NS_Dir )
ser.Tx(13)
nspulse := ser.Getlong
outa[NS_Dir] := ser.Getlong
ewpulse := ser.Getlong
outa[EW_Dir] := ser.Getlong
Photo is a control panel with a 4 speed compass control pad containing a Flip module running a Simple IDE program(LX50A) And a CoStar Guide camera. The original set up used a pair of Arduinos communicating with I2C which was successful but ran too fast . The two programs in use now function well but I need the Hand controller to send it's information to the main panel and since Propellers cannot act as slaves I need to use serial or SPI. Serial would be better since the plug only offers two lines for communicating.Thus The Serial send and serial receive.
In your PUB serial the repeat is doing nothing, you need proper indentation in your spin code, so back space the repeat so the ser.str are in the repeat tree.
Depends, are you wiring Tx pin to Rx pin on the two props. Or do you have both props plugged into your PC and using it as a terminal to communicate with both, in any case I can serial two props that are wired pin to pin, and then also communicate to the PC terminal at the same time. But you'll have to start and stop serial and alternate. Your ser.Dec(EW_PLS) is only going to show what pin number you issued it in the CON. And you haven't flipped the high direction pin by changing the Con to #1, GO_EAST, GO_WEST.
@bbrien - do you have a diagram showing how you intend to connect everything? You mention two Props, so what do each of these Props do? Is one the controller and the other the driver or something like that? Every sentence I'm typing is a question even this one if I end up asking you: can you supply more and clearer photos and more information? Don't try to process the photos, just use the original. That last one was blurry, so just hold it steady or give yourself more light as there is nothing you can do for a photo if it's blurry.
If you have links to websites which you are looking to for that information, then please supply those links too. While we are not sitting around with nothing to do, we do love to help, but we are not psychics, you have to tell us what you can. Even let us know why you are doing it and what you hope to achieve.
Pretty much lay it all out on the table and let us decide which part is important or not and then I am pretty sure that you will have your telescope drive up and running in very short time.
Don't use Pins 30 and 31 on both modules. change the pins, any two your not using, could be 25, 26 or 10, 11, etc.. Then wire Tx master to Rx slave and Rx master to Tx slave. Lets say Main Flip Tx = pin 10 and Rx= 11. On the slave flip it could be Tx = 26 and Rx = 25. Then wire Tx= Pin 10 flip one to Rx=Pin 25 flip two, and Rx=Pin 11 flip one to Tx=Pin 25 flip two. Then change your PUB serial start to "ser.start(11,10,0,9600)" on flip one, and "ser.start( 26,25,0,9600)" on flip two. I run a 10k resistor from Pin 11 on flip one to the 3.3v supply. And a 10K resistor from Pin 10 on flip one to ground. The resistors should take care of any glitches on your wiring. There are many ways you can do your coding loop, remember when you do a ser.Rx or ser.Getlong it could hang up on that line if it doesn't have a signal from the transmitting prop or terminal. And load the Eproms F11 with your spin file not just the ram F10
I almost forgot the all important ground. From prop to prop. The two flip module's will use three wires for serial, Tx, Rx, and 0V (ground). Use pins 30 and 31 for your PC terminal communications.
I make a new photo of the connections The top is the main panel and the middle is the hand controller and the bottom is the guide camera with 80 mm lens. They are connected to their respective ports. For DigitralBob The Flip one unit draws its power from the "mount board" , so already share a common ground.
Only one photo with three items showing the connections . the laptop not in picture. the laptop runs the program(costar) which works the camera.Will make block diagram but will take time, my hands shake. Have not done schematic for boards until everything works.Tried your last post with serial monitor, column of zeros , no "Telescope Test" on monitor no values from the first prop.
That's a nice photo but it doesn't offer any details on your project. My last post was about wiring two props for serial and leaving pins 30 and 31 open for terminal communications. Your posted zip filed worked after I corrected the repeat statement in the PUB serial. It showed the pin numbers for values 1,2,3 etc. If you can't provide more details about your project, there is not much myself or anyone else on here can do for you. Follow Mr. Jakacki's post and give more details.
You seem to have left out the details about the Starshoot autoguider. Thats not going to magically communicate with the prop. Looks like it outputs pulses for the RA and Dec motor. You would have to capture those pulses based on movement and the autoguider's setup menu. Then you could write a control loop for the prop.
Comments
I find the best interface is serial and for many purposes you really only need a single half-duplex line if the communications is in the form of command/response. There are many examples of all kinds of serial drivers on the forum and the obex and in the C libraries. Rather than how you think you might achieve it perhaps the important question is "what are you trying to achieve"?
My guess is that you still do not run the P1 at its 'standard' 80Mhz, thus your problem with serial. This might be your important info you are missing.
So instead of switching to I2C SPI or anything else, just get serial running, then start to write your program around it.
Enjoy!
Mike
There is nothing wrong with your P1 boards. BTW, stop trying to slow it down, leave it at 80MHz. Serial works, always has, always will, but you are the one having the problem then you are the one that needs to provide full information, that is, all your code, your setup, any photos that may help etc. Then, and only then can we see or try out what you have done and go "aha! that is your problem".
My first MCU was the Prop development board + Bluetooth module. I wanted to try communicating with my Android tablet. Had no clue about Spin and so I cut/pasted from examples and it was up and running instantly. Spent the rest of the day playing with the Android code.
Here's a scope capture:
1. Yellow = test pulse at 50Hz
2.
3. NS DIR
4. NS PULSE
What is "longcon" in your code?
You did --nav to init this variable which only predecremented it. You needed nav~~ to set it to all 1's since you were &= to latch them low.
EDIT: I've just come back to look at this again as I didn't have much time before. Here is your version fixed up although I don't see where you use the "serial" function.
EDIT: removed my test version and replaced this code with the original + fixes
BTW - Your code was not sending serial data anywhere. The "serial" routine was not being called and nowhere else were you sending data. That's why it's always a good idea to put in a startup message.
However, lacking your current version which you still haven't sent, here is one that will produce an output although you still need to call your "serial" routine from inside main if you want that to work.
If you ever want any real help you need to say what you can and can't do, what you do and you don't have and know etc. If you are upfront you will save yourself and others a lot of wasted time.
If you have links to websites which you are looking to for that information, then please supply those links too. While we are not sitting around with nothing to do, we do love to help, but we are not psychics, you have to tell us what you can. Even let us know why you are doing it and what you hope to achieve.
Pretty much lay it all out on the table and let us decide which part is important or not and then I am pretty sure that you will have your telescope drive up and running in very short time.