thanks for your post. I would like to ask further:
Your example shows how to share VARIABLES
would it be even possible with viewport to "share" IO-pins in that way:
if ina[noparse][[/noparse]16] == 1
doSomeCode
now inside viewport can I have a virtual switch for 0.0V / 3.3V and this virtual switch sets ina[noparse][[/noparse]16] to 0 or 1 like I would connect the real IO-pin to 0.0V or 3.3V ?
next thing is to establish a "serial connection" by defining Rx/Tx-pins and Viewport "listens" to these IO-pins interprets the bitbanging as serial data
and shows the serial bytes as characters on a VIRTUAL LCD on the PC monitor ?
Hi Stefan,
Check out sample #3 in ViewPort. It uses the "multi" control to display and control individual bits, which correspond to IO pins.
See screenshot. Does exactly what you want.
The second thing you ask for is IO analysis. Have built infrastructure to support SPI, I2C, RS232 protocols- need to finish them if there's sufficient demand.
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here), 12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
Hi Chris,
Bob (a novice ViewPort user only a week ago) put together an excellent "Tips" manual to help others quickly get started with ViewPort. It's here: http://forums.parallax.com/showthread.php?p=856350 Feel free to ask for help- ViewPort is full of features...
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here), 12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
i dont have this working in viewpoit yet but i do have a small issue in Beau Schwabe (Parallax) code that i have 80% working with alot of my mini programs put to gether this is a very important part it can be software or a hardare issue.
PUB Command(Compare)|_Length
_Length := StrSize(Compare)
if StrComp(Compare,@StringBuffer[noparse][[/noparse]FIFOBufferSize-_Length])
result := 1
else
result := 0
this is in my main program please let me know if i need to post the full program agian.
for SURE you have to post the complete program !
the syntax of the lines posted seem to be OK.
If the WHOLE program is working or not depends highly on the rest of the code
You added an "again" to your posting. I was thinking about what you meant by this "again"
Don't get me wrong I just list up POSSIBLE reasons
1) just an objectiv fact
2) Chris wants to avoid annoing the forum with too many attachments
3) Maybe he is to lazy to add the actual code
NOT attaching the actual code rises up a lot of questions, that other forum-members have to ask back
That's the only thing that is annoying.
You can see attaching your actual code as THE standard-procedure to provide information.
Anybody who reads your posting has a free choice to download or not
and if she/he downloads, how long to look inside etc.
as I can't test it at the moment I can't say how the "some_offset_calculation" has to be done
but that's another thing you can find out by sending all values to the PC as debug-output
I just want to add a general thing
what I'm suggesting here is to analyse EVERY DAMMED DETAIL by debug-output
so you can see the value of every single byte and by looking at the values seeing what's happening
If you don't know what is going on you have to analyse EVERY DAMMED SINGLE DETAIL of what is going !
There is no other way to do it
best regards
Stefan
Post Edited (StefanL38) : 11/19/2009 8:57:07 AM GMT
I downloaded your program. There is an easy to find bug in it.
If you don't see thi sbug yourself I can think of two possible resons
1) tomatos on your eyes
2) much too less knowledge about spin for such a complex program
I'm on my way to become a teacher. And as a teacher it is very important to me that people learn to help themselve
There was a reform-teacher in 1930 who said: "help me that I can do it on my own". That's my philosophy about teaching.
It's not clear to me if you followed my advice of making small testprograms. What you uploaded seems to be your complete program.
I got the impression that you are asking for help when your code does not work as expected. Asking again and again.
and whenever a bug is inside asking can somebody point me to the bug.
With a friendly smile on my face: NO !! I don't tell you where the bug is. I just tell you where to search and how to search for the bug
With programming microcontrollers one way to help yourself is to add debug-output to your program.
As a hint: add debug-output to analyse the program-FLOW
Now maybe you don't know where to start adding debug-output
For the first bug it is enough to add debug-output to start in main.spin
Did you try my code before you made any modifications?
In your code, I see that there are elements from the "RF_Transceiver" code the you have brought into your "Main" code that should have remained encapsulated.
Are you observing a proper wiring connection between the Propeller and the RF Transceiver?
You can assign your own pins, but it should look something like this...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 11/21/2009 7:47:23 PM GMT
@ StefanL38· you are correct i dont know much about spin i am here on the forum asking help to understand some things not everything.if you like i can give you 3 small test programs that work that are located in my code to prove that i have helped myself and did my homework.
PROGRAM LINEUP
1. output to debug window and lcd screen done
2. add clock timer to my code done
3. pass varables from one function to another then print to debug wiondow done
4. making my rf units talk from 1 board to another Unfinished
i dont understand why you think i am not trying i have even started to use viewpoint to help me out still working on it but trying almost done with the manual actualy.
I think I understand what you are asking (a few extra characters in there).... If you wire both transceivers correctly to two separate Propeller Demo Boards... i.e.
... then yes the code that I provided should work. The Receiver will illuminate all 8-LEDs on the Propeller Demo Board indicating that it is in SYNC with the Transmitter and receiving data. On the Receiver side, if you open up the Propeller Serial Terminal software and configure it for 38400 Baud and the correct COM port, you should 'see' the data from the Transmitter being displayed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Hi Chris,
Good job on sticking with this project and making progress with ViewPort. Any questions so far?
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here), 12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
You need to power the Transmitter and Receiver with 3.3V not 5V, and you need to split the TX and RX pin on the Propeller as shown in the schematic I provided, as well as specifying which pins to use in software.
You >might< be able to combine the RX TX pins on the Propeller side into 1, but I have another application in mind (hint: with much greater data speed capabilities) that absolutely needs the RX and TX split. Keep in mind though, that currently the software is only written to have the two lines split.
Edit:
Looking at your code...
- You need to lose the FIFO portion of the program and the Command Compare subroutine that is associated with it. Initially I had good intentions with this but it ends up slowing things down and is not the best approach.
- The Transmitter and Receiver units should not be connected to the same Prop, the TX-DEMO and the RX_DEMO are two separate programs meant to be run on individual Props with their own dedicated Transceiver.
- I didn't see in your schematic that you were attaching the TX-RX mode pin this needs to be connected as well. The default is pin 5 but could be changed to something else.
- In you Main code, you are calling a routine called "Send" but inside the Send routine your actually telling the unit to receive
- The ReceiveLOGIC subroutine never gets called.
- RF.Initialize(PacketLength) ... only needs to happen once at the beginning of your program regardless if you are going to send or receive.
- The same is true for the DEBUG.start(31, 30, 0, 38400) ... it only needs to happen once at the beginning of your program.
As far as trouble shooting, the very first thing to do is load the code that I initially provided and make sure that connection is working. From there you can customize it and add the things you want that way, but first get a baseline that you can work with.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 11/22/2009 7:33:53 PM GMT
you said "- The Transmitter and Receiver units should not be connected to the same Prop, the TX-DEMO and the RX_DEMO are two separate programs meant to be run on individual Props with their own dedicated Transceiver."
i wanted to send info back and foward on both boards.
You can but you must do it in Half-Duplex ... like talking on a CB or walkie-talkie, each transceiver must take turns communicating and you can only have one transmitter active at a time. Multiple receivers are ok, but only one transmitter is allowed at a time. My statement is still correct... "The Transmitter and Receiver units should not be connected to the same Prop, the TX-DEMO and the RX_DEMO are two separate programs meant to be run on individual Props with their own dedicated Transceiver."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Transmitter (#27980)
Pin Name Function
1 PDN Power Down - active low, pulled high internally so may be left floating
2 DATA Data Output
3 5v Power – connect to +5v DC (such as Vdd)
4 GND Ground → 0 v (such as Vss)
Receiver (#27981)
Pin Name Function
1 RSSI Received Signal Strength Indicator
2 PDN Power Down - active low, pulled high internally so may be left floating
3 DATA Data Input
4 5v Power – connect to +5v DC (such as Vdd)
5 GND Ground → 0 v (such
StefanL38 is referring to functionality. i.e. you get the Serial working, then you get the LCD working, etc. within each of those 'functions' you can break it down even further into 'sub-functions' exactly like what I did with the RF Transceiver object by making a flow chart first. Each section of the flow chart can then be classified as it's own 'sub-function'. You get each 'sub-function' working the way you want it and THEN piece your code together and group it into a function.
Below is a revised schematic that will work with my original code and the RF Transmitter(#27980) and RF Receiver(#27981).
Focus on getting this communication connection or "function" working and then we can move on to the next step.
·· Out of the box, Your code runs very well using 2 transceivers on 2 separate propeller demo boards. ·· Thank you for all the work - it is greatly appreciated. ·· Here is a photo of the minimum test setup described in the code header.· When the transmitting board on the right is on - you see expected data on the left and on the Parallax Serial Terminal connected to the receiving left board.
Comments
thanks for your post. I would like to ask further:
Your example shows how to share VARIABLES
would it be even possible with viewport to "share" IO-pins in that way:
if ina[noparse][[/noparse]16] == 1 doSomeCodenow inside viewport can I have a virtual switch for 0.0V / 3.3V and this virtual switch sets ina[noparse][[/noparse]16] to 0 or 1 like I would connect the real IO-pin to 0.0V or 3.3V ?
next thing is to establish a "serial connection" by defining Rx/Tx-pins and Viewport "listens" to these IO-pins interprets the bitbanging as serial data
and shows the serial bytes as characters on a VIRTUAL LCD on the PC monitor ?
now THAT would be great !!
best regards
Stefan
Check out sample #3 in ViewPort. It uses the "multi" control to display and control individual bits, which correspond to IO pins.
See screenshot. Does exactly what you want.
The second thing you ask for is IO analysis. Have built infrastructure to support SPI, I2C, RS232 protocols- need to finish them if there's sufficient demand.
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
John Abshier
Bob (a novice ViewPort user only a week ago) put together an excellent "Tips" manual to help others quickly get started with ViewPort. It's here: http://forums.parallax.com/showthread.php?p=856350 Feel free to ask for help- ViewPort is full of features...
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
PUB Command(Compare)|_Length _Length := StrSize(Compare) if StrComp(Compare,@StringBuffer[noparse][[/noparse]FIFOBufferSize-_Length]) result := 1 else result := 0this is in my main program please let me know if i need to post the full program agian.
for SURE you have to post the complete program !
the syntax of the lines posted seem to be OK.
If the WHOLE program is working or not depends highly on the rest of the code
You added an "again" to your posting. I was thinking about what you meant by this "again"
Don't get me wrong I just list up POSSIBLE reasons
1) just an objectiv fact
2) Chris wants to avoid annoing the forum with too many attachments
3) Maybe he is to lazy to add the actual code
NOT attaching the actual code rises up a lot of questions, that other forum-members have to ask back
That's the only thing that is annoying.
You can see attaching your actual code as THE standard-procedure to provide information.
Anybody who reads your posting has a free choice to download or not
and if she/he downloads, how long to look inside etc.
best regards
Stefan
MY CODE POSTED
as the manual says the strcmp compares two strings
the strings have to be zero-terminated
this means the strcmp results in true only if the bytesequence of
f.e. you call
Command(string("!S"))this means the stringbuffer has to contain "!$",zero otherwise the strcmp results in false
the "@"-operator delivers the adress of the begin of the array
I don't know if the "@"-operator delivers a different value if you do
you can check this yourself in a small testroutine
if it does deliver always the same adress I think (but without testing I'm not sure)
you have to code
as I can't test it at the moment I can't say how the "some_offset_calculation" has to be done
but that's another thing you can find out by sending all values to the PC as debug-output
I just want to add a general thing
what I'm suggesting here is to analyse EVERY DAMMED DETAIL by debug-output
so you can see the value of every single byte and by looking at the values seeing what's happening
If you don't know what is going on you have to analyse EVERY DAMMED SINGLE DETAIL of what is going !
There is no other way to do it
best regards
Stefan
Post Edited (StefanL38) : 11/19/2009 8:57:07 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
·i tried your code and it does not work with my transmitter and reciver is there something i am doing wrong
CODE POSTED
I downloaded your program. There is an easy to find bug in it.
If you don't see thi sbug yourself I can think of two possible resons
1) tomatos on your eyes
2) much too less knowledge about spin for such a complex program
I'm on my way to become a teacher. And as a teacher it is very important to me that people learn to help themselve
There was a reform-teacher in 1930 who said: "help me that I can do it on my own". That's my philosophy about teaching.
It's not clear to me if you followed my advice of making small testprograms. What you uploaded seems to be your complete program.
I got the impression that you are asking for help when your code does not work as expected. Asking again and again.
and whenever a bug is inside asking can somebody point me to the bug.
With a friendly smile on my face: NO !! I don't tell you where the bug is. I just tell you where to search and how to search for the bug
With programming microcontrollers one way to help yourself is to add debug-output to your program.
As a hint: add debug-output to analyse the program-FLOW
Now maybe you don't know where to start adding debug-output
For the first bug it is enough to add debug-output to start in main.spin
best regards
Stefan
Did you try my code before you made any modifications?
In your code, I see that there are elements from the "RF_Transceiver" code the you have brought into your "Main" code that should have remained encapsulated.
Are you observing a proper wiring connection between the Propeller and the RF Transceiver?
You can assign your own pins, but it should look something like this...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 11/21/2009 7:47:23 PM GMT
PROGRAM LINEUP
1. output to debug window and lcd screen done
2. add clock timer to my code done
3. pass varables from one function to another then print to debug wiondow done
4. making my rf units talk from 1 board to another Unfinished
i dont understand why you think i am not trying i have even started to use viewpoint to help me out still working on it but trying almost done with the manual actualy.
i have a RF_Reciveand a RF_Transmiter will the same code for your RF_Transceive work for y two devices
I think I understand what you are asking (a few extra characters in there).... If you wire both transceivers correctly to two separate Propeller Demo Boards... i.e.
... then yes the code that I provided should work. The Receiver will illuminate all 8-LEDs on the Propeller Demo Board indicating that it is in SYNC with the Transmitter and receiving data. On the Receiver side, if you open up the Propeller Serial Terminal software and configure it for 38400 Baud and the correct COM port, you should 'see' the data from the Transmitter being displayed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
your method start does the following:
starting the FDX-driver
set tow variable
send some characters
and that's it !?!?!?
the cog just stops working as there is no repeat loop INSIDE your method start nor any calls to other methods who may have a repeat-loop
best regards
Stefan
this is my setup
TRANSMITER
Vss ─────────── GND
P2 ────/\/\/─────── DATA
Vdd ─────────── 5+
RECIVER
Vss ─────────── GND
P1 ────/\/\/─────── DATA
Vdd ─────────── 5+
Post Edited (chris jones) : 11/22/2009 4:16:23 PM GMT
Good job on sticking with this project and making progress with ViewPort. Any questions so far?
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
You need to power the Transmitter and Receiver with 3.3V not 5V, and you need to split the TX and RX pin on the Propeller as shown in the schematic I provided, as well as specifying which pins to use in software.
You >might< be able to combine the RX TX pins on the Propeller side into 1, but I have another application in mind (hint: with much greater data speed capabilities) that absolutely needs the RX and TX split. Keep in mind though, that currently the software is only written to have the two lines split.
Edit:
Looking at your code...
- You need to lose the FIFO portion of the program and the Command Compare subroutine that is associated with it. Initially I had good intentions with this but it ends up slowing things down and is not the best approach.
- The Transmitter and Receiver units should not be connected to the same Prop, the TX-DEMO and the RX_DEMO are two separate programs meant to be run on individual Props with their own dedicated Transceiver.
- I didn't see in your schematic that you were attaching the TX-RX mode pin this needs to be connected as well. The default is pin 5 but could be changed to something else.
- In you Main code, you are calling a routine called "Send" but inside the Send routine your actually telling the unit to receive
- The ReceiveLOGIC subroutine never gets called.
- RF.Initialize(PacketLength) ... only needs to happen once at the beginning of your program regardless if you are going to send or receive.
- The same is true for the DEBUG.start(31, 30, 0, 38400) ... it only needs to happen once at the beginning of your program.
As far as trouble shooting, the very first thing to do is load the code that I initially provided and make sure that connection is working. From there you can customize it and add the things you want that way, but first get a baseline that you can work with.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 11/22/2009 7:33:53 PM GMT
you said "- The Transmitter and Receiver units should not be connected to the same Prop, the TX-DEMO and the RX_DEMO are two separate programs meant to be run on individual Props with their own dedicated Transceiver."
i wanted to send info back and foward on both boards.
You can but you must do it in Half-Duplex ... like talking on a CB or walkie-talkie, each transceiver must take turns communicating and you can only have one transmitter active at a time. Multiple receivers are ok, but only one transmitter is allowed at a time. My statement is still correct... "The Transmitter and Receiver units should not be connected to the same Prop, the TX-DEMO and the RX_DEMO are two separate programs meant to be run on individual Props with their own dedicated Transceiver."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Transmitter (#27980)
Pin Name Function
1 PDN Power Down - active low, pulled high internally so may be left floating
2 DATA Data Output
3 5v Power – connect to +5v DC (such as Vdd)
4 GND Ground → 0 v (such as Vss)
Receiver (#27981)
Pin Name Function
1 RSSI Received Signal Strength Indicator
2 PDN Power Down - active low, pulled high internally so may be left floating
3 DATA Data Input
4 5v Power – connect to +5v DC (such as Vdd)
5 GND Ground → 0 v (such
Ok, let me get back to you... the individual RF Receiver and RF Transmitter work differently than the RF Transceiver.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
you really seem that you want to do it the hard and long way
changing things at 3 to 5 different places at the same time beeing confused about what happens
Can't avoid to be a little sarcastic here. OK doing it that way can be a hobby too ...... feel free to do it.
My way is is strictly change ONE thing at ONE time. If it works add the next detail
best regards
Stefan
Post Edited (StefanL38) : 11/22/2009 10:06:36 PM GMT
StefanL38 is referring to functionality. i.e. you get the Serial working, then you get the LCD working, etc. within each of those 'functions' you can break it down even further into 'sub-functions' exactly like what I did with the RF Transceiver object by making a flow chart first. Each section of the flow chart can then be classified as it's own 'sub-function'. You get each 'sub-function' working the way you want it and THEN piece your code together and group it into a function.
Below is a revised schematic that will work with my original code and the RF Transmitter(#27980) and RF Receiver(#27981).
Focus on getting this communication connection or "function" working and then we can move on to the next step.
RF Transmitter(#27980): 4.7K 1K +3.3V >---/\/\---o---/\/\---> DATA | P7 >----------o Vss >---------------------> GND +5V >---------------------> +5V RF Receiver(#27981): 4.7K 1K GND >---/\/\---o---/\/\---> DATA | P6 >----------o Vss >---------------------> GND +5V >---------------------> +5V▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 11/23/2009 12:06:49 AM GMT
·· Hi, I was looking for an object for the Parallax 433 MHz Transceiver and came across your software from another post here.
http://forums.parallax.com/showthread.php?p=853681
·· Out of the box, Your code runs very well using 2 transceivers on 2 separate propeller demo boards.
·· Thank you for all the work - it is greatly appreciated.
·· Here is a photo of the minimum test setup described in the code header.· When the transmitting board on the right is on - you see expected data on the left and on the Parallax Serial Terminal connected to the receiving left board.
·· /michael