I had to make several changes to compile the code (extra work for me because you didn't do 1.)
Make guessings what YOU can do if the compiler says (see attached picture
One more question: Do you write dozens of lines of code and AFTER that trying to compile it?
That's a very unefficient way to write programs
COMPILE them as soon as possible this will guide you to syntax-errors and fix them right after you made them
If you don't understand what the reason for the error is consult the manual.
best regards
Stefan
Post Edited (StefanL38) : 11/8/2009 11:52:36 AM GMT
sorry to be so unspecific most of this is what we talked about in earlyer posts, this is just an object i will call with your exmpale.
rfRTX.Start(TXpin,RXpin,Baud) 'Setup RF Transceiver
rfRTX.Send({DataAddress},PacketLength,Polynomial) 'Send Data string from address starting at
'{DataAddress} for 'PacketLength' BYTES
rfRTX.Receive({DataAddress},PacketLength,Polynomial) 'Receive Data string into address starting
no i do not write lines of code befor i test it i just added the while loop to reflect the loops cutoff point the while is the only part i have added. if the while loop is taken out i get no compile errors.
Also· how should i have asked this question so i will not make the same mistake agian , should i always attach my full code everytime i have a change.
Post Edited (chris jones) : 11/8/2009 3:49:07 PM GMT
chris jones, ·
Just an update... I had something come up on Friday where I couldn't get back to the RF Transceiver object, but I plan on having something early this next week.· I have decided to make the CRC routine a one-shot rather than running in the background, and I have already modified it to accept LONG polynomials, as well as return LONG CRC values.· as it is the CRC value returned is fixed at 1 BYTE (the lower LSB of the entire LONG).· The reason is that the CRC value should always be the same bit width (rounded up to the nearest BYTE) as the polynomial minus 1. ·
Attached is a flow diagram of the basic RF-Transceiver object.· I wanted to make this as seamless as possible.· You load the buffer with what you want to send and you give a command to send... if it doesn't get an acknowledgement it will send again, and again... until a confirmation is reached.· On the receive end there are two receive buffers.· The thinking here is that at any time at least one buffer would hold the last 'valid' data and when you read the buffer, the Index value would point to the most recent valid data.· Upon receipt, the CRC is compared and if it matched, the Receiver will send an acknowledgement to the Transmitter, who by this time is waiting for a reply. ·
Both Send and Receive would work in the background, but not the CRC routine.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 11/8/2009 7:26:22 PM GMT
I have a very personal style what I expect from others that want help from me.
I'm willing to help. But first attach an archive WITHOUT propeller.exe with your actual code.
If your archive is more than 1MB you have included the propeller.exe
and I don't want to have the propeller.exe all over in subdirectories and I don't want to delete it out of your archives.
Without your ACTUAL code I feel like guessing in the fog.
For a general question like "how do I create an object ?" you can read the manual.
You don't want to do that and you are working on a certain project.
So please do me a favour and attach your complete actual code.
Maybe you are thinking if you attach code all the time this would be annoying.
With me it is the opposite: NOT attaching makes me upset.
best regards
Stefan
Post Edited (StefanL38) : 11/10/2009 5:06:40 PM GMT
' Start the serial communications for the RF Transmiter
ser.Start(RF_TX, -1, 1, 9600)
' Wait a bit
Pause_ms(1000)
' Start the serial communications for the RF receiver
ser.Start(RF_RX, -1, 1, 9600)
the first call of ser.start configures the driver to use RF_TX as RECEIVE pin (use pin 2 as rx-pin)
first parameter of the method start
the second start stops the cog and configures the cog new to use the RF_RX as RECEIVE pin (use oin 1 as rx-pin
the second parameter is always -1 which is not a valid value you can only use valid io-pin-numbers (0-31)
the second parameter configures the TX-pin
what is not clear to me is do you want the propeller act as a relay-station ? where TWO seperate RF-units are connected to
or do you want to do biderectional data-transfer from and to the prop with ONE rf-unit ?
your code does just start the fullduplexserial-driver
For sending serial data it should use
ser.tx()
ser.dec()
ser-str()
but I can't see any of these commands.
As sereral things are unclear please describe in normal words what you would like to do
after that I can say you how you have to change your code that the code does what
you want
I have 3 propeller demo boards with TX and RX devices on all, I want to send data to each propeller board. For example
Box 1 sends to box 2 and 3
Box 2 sends to box 3 and 1
Box 3 sends to box 2 and 1
This is my overall goal but for now I just want to send a simple string of data to 1 board from another.
EXMAPLE “123456”
Since I am using full duplex I want to send and receive at the same time to save time.
MY PROGRAM NEEDS TO
1. Start the RX and TX devices
2. Send out data
3. Receive data
4. Log data( later in my explorations)
to answer your question
"biderectional data-transfer from and to the prop with ONE rf-unit ?"
on each board there is a RX and TX device not the all in one transiver
The meaning of FullDuplexSerial is this ONE driver does send AND receive at the same time.
It is enough to call the start-method ONCE.
To learn how an object works take a look inside the code of the object itself.
If you look onto the code of the method start inside of the file FullDuplexSerial.spin you see
PUB start(rxpin, txpin, mode, baudrate) : okay
the method has four parameters
first parameter "rxpin" number of the IO-Pin that receives serial data.
second parameter "txpin" number of the IO-Pin that sends serial data.
send and receive meant from the perspective of the propeller
propeller-txpin-->-->-->--> device
propeller-rxpin<--<--<--<-- device
third parameter
mode defines operation modes. In most cases mode 0 will work
If mode 0 does NOT work you have to provide detailed information about your rf-units: manual and schematics
fourth parameter
baudrate means what it says
So as a short example if you have connected the rf-receiver to pin 10
and the transmitter to pin 11 and the rf-units should work with 9600 baud the code looks like this
ser.start(10,11,0,9600)
My 25 years of experience in programming tought me:
if you do something new - first write a SMALL testprogram to get familiar with the new
the reason is:
a small testprogram with a small number of lines of code has a smaller number of bugs than a bigger one.
In the testprogram where there is NOTHING else but the new thing to test
there are less possaibilities for bugs
So I highly recommend that you test the serial communication with fullduplexserial in a TINY SMALL
testprogram that does nothing else then receive a single byte and echo back that single byte
first step: DIRECT connection between Propeller and PC (NO rf-units in between)
this way you know: if it does not work - it is the software
If you do it with rf-units included a bug CAN be in the hardware OR the software
and this makes you fiddle around in the software/hardware for hours or days until
you switch over to analyse hardware/software
It's much easier - and in the long run FASTER - to test ONE thing at a time
If send and receive data prop---PC works next thing is to test serial communication between two PCs
PC1
cable
PC2
each PC running a terminal software testing send and receive bytes
from that test you know the com-ports of both PCs work reliable
next test
PC1---rf-unit .......wireless......rf-unit-PC2
PC1 and PC2 running the terminal-software from the PC1--PC2-test
from that test you know the rf-units work reliably and if not you are sure it is NOT the com-port of one of the PC
By that way you keep most "parameters" constant for easy narrowing down where a bug can be
AFTER ALL these pre-tests the next thing is to test
prop
rf-unit....wireless........rf-unit----PC
if you try to do prop
rf-unit....wireless........rf-unit-prop
there are the following places where the bug can be
and 1) / 6) have two dozens possabilities what you can dow wrong inside the software
Now it is up to you to believe me without testing the complex way
or maybe you are in a hurry and you want to go on the complex way
and have to make the experience yourself: if you want it superfast it becomes superslow
(remember how many postings and days it already took to reach the point we are)
best regards
Stefan
Post Edited (StefanL38) : 11/10/2009 10:32:10 PM GMT
i must be doing something wrong on the debuging end i can run this con the computer but i dont get a debug screen so i dont know whats going where i am using the propeller tool do i need to use anothe interfave.
open the file TestSerialConnection.spin with the propellertool
load the program with F11 into the EEPROM
start PST.EXE
adjust baudrate of PST.EXE to 115200
connect to propeller by clicking on the enable-button of PST.EXE
PST.EXE should receive the following text every second
type any kind of a letter or number key like abc or 123
the pressed key is echoed back to PST.EXE
type any kind of a letter or number key like abc or 123
the pressed key is echoed back to PST.EXE
as soon as you press a letter or number key on the PC-keyboard
PST.EXE will echo back this key
If you want to connect the rf-unit to the propeller you have to insert a 1kOhm resistor
between rf-unit and propeller-IO-pin
rf-unit
1kOhm
prop-IO-pin
the rf-unit needs a 5V powersupply. The serialdata-pin "sends" 5V if 5V are connected DIRECTLY to a propeller-pin
the IO-port can be damaged !!
So it might be useful to check with a 330 ohm-resistor and a LED if the IO-port is still working
prop-IO-pin----330 ohm----LED
ground
Post Edited (StefanL38) : 11/11/2009 12:16:04 AM GMT
I apologize for my delay, I was planning on having something last Friday, but something unexpected concerning Prop II layout came up that took precedence and is still a priority at the moment.
Here are some of the updated files I have to date... the CRC routines have been modified slightly to allow the CRC to be returned as a LONG rather than a BYTE. This only affects the results if your polynomial is greater than 1 BYTE wide... i.e. CRC 16 or 32 implementations.
This version of CRC is set for continuous decoding mode however 'ideally' to work with the flow diagram, it should be made to operate in a one-shot mode.
The TX DEMO and RX DEMO have also been modified slightly to improve decoding/detecting speeds.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
you are right !
there is one variant where you can put the while at the end of the loop
BUT !! INDENTION is CRITICAL !!!
the word "WHILE" has to start in the SAME columm as the columm of the REPEAT
otherwise you get an compiler-error-message
That is what was wrong in your original code at the beginning of this thread
so the code with the WRONG INDENTION of the keyword while
PUB Send(ArrayList,PL,PO) 'ArrayList= Array to read in PL = Packet Length 'PO = Polynomial
repeat
X := PL ' paclet length
while X < 0 '<<<<<<<<<<<<this while is too deep indented
ArrayList[noparse][[/noparse]X++] := X
ser.str(string("!S")) ''<-- Send SYNC characters
ser.tx(X) ''<-- Apply CRC
ser.tx(CRCvalue) ''<---Automatically generated on the fly when 'Dividend' variables are set
while this code does compile
PUB Send(ArrayList,PL,PO) 'ArrayList= Array to read in PL = Packet Length 'PO = Polynomial
repeat
X := PL ' paclet length
while X < 0
ArrayList[noparse][[/noparse]X++] := X
ser.str(string("!S")) ''<-- Send SYNC characters
ser.tx(X) ''<-- Apply CRC
ser.tx(CRCvalue) ''<---Automatically generated on the fly when 'Dividend' variables are set
once again with explanation in the code
PUB Send(ArrayList,PL,PO) 'ArrayList= Array to read in PL = Packet Length 'PO = Polynomial
'the repeat starts in columm 6

repeat
X := PL ' paclet length
while X < 0

'the while starts in columm 6 too ONLY THEN it compiles
ArrayList[noparse][[/noparse]X++] := X
ser.str(string("!S")) ''<-- Send SYNC characters
ser.tx(X) ''<-- Apply CRC
ser.tx(CRCvalue) ''<---Automatically generated on the fly when 'Dividend' variables are set
Full Duplex Serial starts an additional cog to handle the actual serial I/O, so you would have the main cog and one additional cog. You don't need to start up extra cogs yourself.
The Propeller Education Kit has a good tutorial on the use of multiple cogs. Try it.
Revision History:
Version 1.0.a - (10-30-2009) original file created
Version 1.0.b - (11-04-2009) improved bit width routine
Version 1.0.c - (11-05-2009) optimized flow of long division routine
Version 1.0.d - (11-06-2009) adjusted CRC to return LONG value instead of BYTE value
this allows for the full remainder to be returned for
polynomials greater than 1 BYTE wide.
Version 1.0.e - (11-13-2009) converted CRC engine driver for one shot mode
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 11/13/2009 8:03:33 AM GMT
i need some help, i have used the code that Beau Schwabe (Parallax)
provided in my code and i can not seem to get the code to work it will not display anything in my debug screen. I let it run for a while.Attached is my code with no errors and archived any input will help alot, i know i have lots of code but i have only focused on the RF devices
I didn't see anything in your code at first glance that stood out. Did it work before with the older version of the CRC? One thing you might want to consider... remove the FIFO buffer. I originally thought that this approach was a good idea, but it slows things down enough to cause errors. Also are you testing this as a direct connection? The reason I ask, is that I did not see a pin to the RF module dedicated to switching its mode from TX to RX and besides you had that module remarked in your OBJ reference.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
if I understood right you are still a newbee to programming.
The complexity of your project has, compared to your experience a HUGE amount of complexity.
You maybe are thinking "no that's not complex I just added some objects"
Yes the number of projects is small compared to what f.e. microsoft word needs.
You just comment "i can not seem to get the code to work".
For me this has two possible reasons:
1) you do know a lot about programming but you are lazy in describing the problem
2) you don't have ANY idea WHERE in the code what might be the bug
if 2) is the case I HIGHLY recommend to reduce the complexity of your project
This means writing a small testprogram that does NOTHING ELSE but calculating CRC-values
- if this is working properly, you can add send and receive a TESTstring
- if this is working properly, you can add the next small part
etc. etc.
This will help you to narrow down the problem
You can go on for days, weeks, months, guessing in the fog, change the code here a bit change the code there a bit
looking at the results and again scratch your head: "why does it do .... ?? it should do ... !!"
A program does ALWAYS what YOU have programmed. If the program does something else than you expected
you don't understand what you have programmed.
The only way to narrow down a problem is to narrow down the code
What do you think the experts here do if they analyse your code ?
The take a PIECE of it and start analysing to understand what this PIECE of code is doing
Then they take the next PIECE and analyse to understand what this PIECE of code is doing
Then these experts start to write small testprograms to analyse in more details what is going on
Beautiful dream that somebody else does all the work for you
So now back to reality
If you take a look at other threads: most of the threads talk about SMALL problems
or there is a situation that somebody has become an expert TOGETHER with somebody else and now BOTH of them
are well knowing the code and can talk about details
To get QUICK help you have to reduce your code to a state that
1) the code can run on any kind of propellerboard WITHOUT additional hardware as long as the problem is not hardware-related
2) the code is reduced to ONE issue like the crc-problem
If you now think "oh - how should I reduce the code to one issue ? I just don't know"
Then your level of understanding programming is far away from that you can cope with a project like this.
Don't get me wrong I'm 100% sure that you can learn it ! The way to learn it is going back to small testprograms
testing ONE thing at ONE time.
best regards
Stefan
Post Edited (StefanL38) : 11/14/2009 6:42:53 AM GMT
your right StefanL38 this project is geting big and almost to much for me to handle at once, i will start a test program and see if it works then add to it.Alo haveing the hardware should not be a issue is someone is willing to hepli will send them the hardware [noparse]:)[/noparse].
with small testprograms it is not nescessary to send them hardware.
Most of the things can be done over the serial connection.
Sending data to an LCD could be emulated this way.
Maybe a software on the PC that EMULATES the serial display
(knowing the commands for set cursor etc.) and displaying it on the PC-screen the same way as
on the LC-Display is enough.
Maybe somebody would like to write a wrapper-object for PropTerminal
that PropTerminal can be used this way ?
If you define some kind of an interface between parts of the software that REALLY use the hardware and another part
that does the rest it will be easy to replace the real hardware by a simulator-method
(Which might be even remotecontroled over a serial connection to change values)
@Hanno: can ViewPort do something like this easily ? Defining knobs and switches that can simulate hardware ?
f.e. using another cog to create a signal that the original cog (wich has a setup as a delta-sigma ADC) sees in the same way
as a real analog voltage ?
Hi Chris,
Very interesting and ambitious project. Stefan, Brad, and Beau have done a great job of helping you get closer to success. I'm a big fan of "KISS"- keep it simple stupid. Whenever you can, start with something simple that you can quickly succeed at- while still learning something. Then, keep going until you've solved big/complex problems.
Ok, Stefan asked if ViewPort can be used to "replace" hardware. I do this all the time. None of my projects have real switches/knobs/leds (PropScope, DanceBot, IODreamkit). Instead, during development or when I need to diagnose bugs, I connect a serial cable to the Propeller and start up ViewPort. Then, on my nice monitor and with big, labeled controls like dials, sliders, and buttons I control my device. Pretty much all the ~15 tutorials included in ViewPort show this concept. Here's the basic idea:
Declare and use a variable to affect some part of your program- for example, part of an "if" to control whether part of your code is run and to control how often something is run:
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
var doCode,numTimes
pub run
repeat
if doCode
repeat numTimes
'run some code
To integrate with ViewPort, you must include the "conduit" file which transfers data to/from the PC application at up to 2mbps. You must also tell the object which variables you wish to share with the application. So, your program will look like this:
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
OBJ
vp : "Conduit" 'transfers data to/from PC
var doCode,numTimes
pub run
vp.share(@doCode,@numTimes) 'share the memory from docode to numtimes: 2 variables
repeat
if doCode
repeat numTimes
'run some code
That's it! Load to your Propeller and start up ViewPort. (See my signature for my website and a review for more information)
ViewPort gives you lots of tools to monitor variable values and even a fully integrated graphical debugger. However, in this case we'll focus on the "ViewPort Overview" panel in the bottom right. You should see 2 channels, v1 and v2- these correspond to the variables you've shared. Click on v1 to configure the name, how it'll be displayed, and how you wish to edit it. Here's where you choose what type of controls you'll use for each variable. Once you've configured everything to your liking you can "copy configuration string" and paste that code into your program.
Good luck! (As Stefan has asked previously- if you do have problems please upload your code and take your time to accurately and precisely describe your problem)
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
Comments
to be as unspecific as you: Yes you are in the right direction
... - ... very (un)satisfying answer on a unsatifying question
1.)
http://forums.parallax.com/forums/attach.aspx?a=35975
I had to make several changes to compile the code (extra work for me because you didn't do 1.)
Make guessings what YOU can do if the compiler says (see attached picture
One more question: Do you write dozens of lines of code and AFTER that trying to compile it?
That's a very unefficient way to write programs
COMPILE them as soon as possible this will guide you to syntax-errors and fix them right after you made them
If you don't understand what the reason for the error is consult the manual.
best regards
Stefan
Post Edited (StefanL38) : 11/8/2009 11:52:36 AM GMT
sorry to be so unspecific most of this is what we talked about in earlyer posts, this is just an object i will call with your exmpale.
rfRTX.Start(TXpin,RXpin,Baud) 'Setup RF Transceiver rfRTX.Send({DataAddress},PacketLength,Polynomial) 'Send Data string from address starting at '{DataAddress} for 'PacketLength' BYTES rfRTX.Receive({DataAddress},PacketLength,Polynomial) 'Receive Data string into address startingno i do not write lines of code befor i test it i just added the while loop to reflect the loops cutoff point the while is the only part i have added. if the while loop is taken out i get no compile errors.
Also· how should i have asked this question so i will not make the same mistake agian , should i always attach my full code everytime i have a change.
Post Edited (chris jones) : 11/8/2009 3:49:07 PM GMT
·
Just an update... I had something come up on Friday where I couldn't get back to the RF Transceiver object, but I plan on having something early this next week.· I have decided to make the CRC routine a one-shot rather than running in the background, and I have already modified it to accept LONG polynomials, as well as return LONG CRC values.· as it is the CRC value returned is fixed at 1 BYTE (the lower LSB of the entire LONG).· The reason is that the CRC value should always be the same bit width (rounded up to the nearest BYTE) as the polynomial minus 1.
·
Attached is a flow diagram of the basic RF-Transceiver object.· I wanted to make this as seamless as possible.· You load the buffer with what you want to send and you give a command to send... if it doesn't get an acknowledgement it will send again, and again... until a confirmation is reached.· On the receive end there are two receive buffers.· The thinking here is that at any time at least one buffer would hold the last 'valid' data and when you read the buffer, the Index value would point to the most recent valid data.· Upon receipt, the CRC is compared and if it matched, the Receiver will send an acknowledgement to the Transmitter, who by this time is waiting for a reply.
·
Both Send and Receive would work in the background, but not the CRC routine.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 11/8/2009 7:26:22 PM GMT
best regards
Stefan
i figured out that i was not checking the right varable so the statement was incorrect, i have that part working now.
is there anything i cam help with i tried to create an object but i can not get it to work.
I have a very personal style what I expect from others that want help from me.
I'm willing to help. But first attach an archive WITHOUT propeller.exe with your actual code.
If your archive is more than 1MB you have included the propeller.exe
and I don't want to have the propeller.exe all over in subdirectories and I don't want to delete it out of your archives.
Without your ACTUAL code I feel like guessing in the fog.
For a general question like "how do I create an object ?" you can read the manual.
You don't want to do that and you are working on a certain project.
So please do me a favour and attach your complete actual code.
Maybe you are thinking if you attach code all the time this would be annoying.
With me it is the opposite: NOT attaching makes me upset.
best regards
Stefan
Post Edited (StefanL38) : 11/10/2009 5:06:40 PM GMT
here is my archive of my project
OK I downloaded your code.
You coded two starts of the object "ser"
' Start the serial communications for the RF Transmiter ser.Start(RF_TX, -1, 1, 9600) ' Wait a bit Pause_ms(1000) ' Start the serial communications for the RF receiver ser.Start(RF_RX, -1, 1, 9600)the first call of ser.start configures the driver to use RF_TX as RECEIVE pin (use pin 2 as rx-pin)
first parameter of the method start
the second start stops the cog and configures the cog new to use the RF_RX as RECEIVE pin (use oin 1 as rx-pin
the second parameter is always -1 which is not a valid value you can only use valid io-pin-numbers (0-31)
the second parameter configures the TX-pin
what is not clear to me is do you want the propeller act as a relay-station ? where TWO seperate RF-units are connected to
or do you want to do biderectional data-transfer from and to the prop with ONE rf-unit ?
your code does just start the fullduplexserial-driver
For sending serial data it should use
ser.tx()
ser.dec()
ser-str()
but I can't see any of these commands.
As sereral things are unclear please describe in normal words what you would like to do
after that I can say you how you have to change your code that the code does what
you want
best regards
Stefan
Box 1 sends to box 2 and 3
Box 2 sends to box 3 and 1
Box 3 sends to box 2 and 1
This is my overall goal but for now I just want to send a simple string of data to 1 board from another.
EXMAPLE “123456”
Since I am using full duplex I want to send and receive at the same time to save time.
MY PROGRAM NEEDS TO
1. Start the RX and TX devices
2. Send out data
3. Receive data
4. Log data( later in my explorations)
to answer your question
"biderectional data-transfer from and to the prop with ONE rf-unit ?"
on each board there is a RX and TX device not the all in one transiver
OK that clears things up.
The meaning of FullDuplexSerial is this ONE driver does send AND receive at the same time.
It is enough to call the start-method ONCE.
To learn how an object works take a look inside the code of the object itself.
If you look onto the code of the method start inside of the file FullDuplexSerial.spin you see
the method has four parameters
first parameter "rxpin" number of the IO-Pin that receives serial data.
second parameter "txpin" number of the IO-Pin that sends serial data.
send and receive meant from the perspective of the propeller
propeller-txpin-->-->-->--> device
propeller-rxpin<--<--<--<-- device
third parameter
mode defines operation modes. In most cases mode 0 will work
If mode 0 does NOT work you have to provide detailed information about your rf-units: manual and schematics
fourth parameter
baudrate means what it says
So as a short example if you have connected the rf-receiver to pin 10
and the transmitter to pin 11 and the rf-units should work with 9600 baud the code looks like this
My 25 years of experience in programming tought me:
if you do something new - first write a SMALL testprogram to get familiar with the new
the reason is:
a small testprogram with a small number of lines of code has a smaller number of bugs than a bigger one.
In the testprogram where there is NOTHING else but the new thing to test
there are less possaibilities for bugs
So I highly recommend that you test the serial communication with fullduplexserial in a TINY SMALL
testprogram that does nothing else then receive a single byte and echo back that single byte
first step: DIRECT connection between Propeller and PC (NO rf-units in between)
this way you know: if it does not work - it is the software
If you do it with rf-units included a bug CAN be in the hardware OR the software
and this makes you fiddle around in the software/hardware for hours or days until
you switch over to analyse hardware/software
It's much easier - and in the long run FASTER - to test ONE thing at a time
If send and receive data prop---PC works next thing is to test serial communication between two PCs
PC1
cable
PC2
each PC running a terminal software testing send and receive bytes
from that test you know the com-ports of both PCs work reliable
next test
PC1---rf-unit .......wireless......rf-unit-PC2
PC1 and PC2 running the terminal-software from the PC1--PC2-test
from that test you know the rf-units work reliably and if not you are sure it is NOT the com-port of one of the PC
By that way you keep most "parameters" constant for easy narrowing down where a bug can be
AFTER ALL these pre-tests the next thing is to test
prop
rf-unit....wireless........rf-unit----PC
if you try to do prop
rf-unit....wireless........rf-unit-prop
there are the following places where the bug can be
1) prop-send-software
2) rf-unit1 connected wrong to prop
3) rf-unit1 powersupply
4) rf-unit 2 connected wrong to prop
5) rf-unit2 powersupply
6) prop-receive-software
and 1) / 6) have two dozens possabilities what you can dow wrong inside the software
Now it is up to you to believe me without testing the complex way
or maybe you are in a hurry and you want to go on the complex way
and have to make the experience yourself: if you want it superfast it becomes superslow
(remember how many postings and days it already took to reach the point we are)
best regards
Stefan
Post Edited (StefanL38) : 11/10/2009 10:32:10 PM GMT
how should I know which DETAIL is wrong if you don't upload your COMPLETE code that you are working with ????
What do you mean by writing I can run this "con" the computer ?
You really seem to be in a hurry as you make such kind of typos.
Look at the result: you don't get an answer helping you. I have to ask back what you mean exactly.
How many rounds would you like to play this ping-pong-game ?
unzip it.
open the file TestSerialConnection.spin with the propellertool
load the program with F11 into the EEPROM
start PST.EXE
adjust baudrate of PST.EXE to 115200
connect to propeller by clicking on the enable-button of PST.EXE
PST.EXE should receive the following text every second
as soon as you press a letter or number key on the PC-keyboard
PST.EXE will echo back this key
If you want to connect the rf-unit to the propeller you have to insert a 1kOhm resistor
between rf-unit and propeller-IO-pin
rf-unit
1kOhm
prop-IO-pin
the rf-unit needs a 5V powersupply. The serialdata-pin "sends" 5V if 5V are connected DIRECTLY to a propeller-pin
the IO-port can be damaged !!
So it might be useful to check with a 330 ohm-resistor and a LED if the IO-port is still working
prop-IO-pin----330 ohm----LED
ground
Post Edited (StefanL38) : 11/11/2009 12:16:04 AM GMT
any update on the object you are working on?
I apologize for my delay, I was planning on having something last Friday, but something unexpected concerning Prop II layout came up that took precedence and is still a priority at the moment.
Here are some of the updated files I have to date... the CRC routines have been modified slightly to allow the CRC to be returned as a LONG rather than a BYTE. This only affects the results if your polynomial is greater than 1 BYTE wide... i.e. CRC 16 or 32 implementations.
This version of CRC is set for continuous decoding mode however 'ideally' to work with the flow diagram, it should be made to operate in a one-shot mode.
The TX DEMO and RX DEMO have also been modified slightly to improve decoding/detecting speeds.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Whatever gives you that idea?
PUB Start | X X := 0 repeat X++ While X < 10▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
i seen this in the manual on while loops
PUB Start | X
X := 0
repeat
X++
While X < 10
you are right !
there is one variant where you can put the while at the end of the loop
BUT !! INDENTION is CRITICAL !!!
the word "WHILE" has to start in the SAME columm as the columm of the REPEAT
otherwise you get an compiler-error-message
That is what was wrong in your original code at the beginning of this thread
so the code with the WRONG INDENTION of the keyword while
PUB Send(ArrayList,PL,PO) 'ArrayList= Array to read in PL = Packet Length 'PO = Polynomial repeat X := PL ' paclet length while X < 0 '<<<<<<<<<<<<this while is too deep indented ArrayList[noparse][[/noparse]X++] := X ser.str(string("!S")) ''<-- Send SYNC characters ser.tx(X) ''<-- Apply CRC ser.tx(CRCvalue) ''<---Automatically generated on the fly when 'Dividend' variables are setwhile this code does compile
PUB Send(ArrayList,PL,PO) 'ArrayList= Array to read in PL = Packet Length 'PO = Polynomial repeat X := PL ' paclet length while X < 0 ArrayList[noparse][[/noparse]X++] := X ser.str(string("!S")) ''<-- Send SYNC characters ser.tx(X) ''<-- Apply CRC ser.tx(CRCvalue) ''<---Automatically generated on the fly when 'Dividend' variables are setonce again with explanation in the code
PUB Send(ArrayList,PL,PO) 'ArrayList= Array to read in PL = Packet Length 'PO = Polynomial 'the repeat starts in columm 6  repeat X := PL ' paclet length while X < 0  'the while starts in columm 6 too ONLY THEN it compiles ArrayList[noparse][[/noparse]X++] := X ser.str(string("!S")) ''<-- Send SYNC characters ser.tx(X) ''<-- Apply CRC ser.tx(CRCvalue) ''<---Automatically generated on the fly when 'Dividend' variables are setbest regards
Stefan
The Propeller Education Kit has a good tutorial on the use of multiple cogs. Try it.
Revision History: Version 1.0.a - (10-30-2009) original file created Version 1.0.b - (11-04-2009) improved bit width routine Version 1.0.c - (11-05-2009) optimized flow of long division routine Version 1.0.d - (11-06-2009) adjusted CRC to return LONG value instead of BYTE value this allows for the full remainder to be returned for polynomials greater than 1 BYTE wide. Version 1.0.e - (11-13-2009) converted CRC engine driver for one shot mode▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 11/13/2009 8:03:33 AM GMT
provided in my code and i can not seem to get the code to work it will not display anything in my debug screen. I let it run for a while.Attached is my code with no errors and archived any input will help alot, i know i have lots of code but i have only focused on the RF devices
I didn't see anything in your code at first glance that stood out. Did it work before with the older version of the CRC? One thing you might want to consider... remove the FIFO buffer. I originally thought that this approach was a good idea, but it slows things down enough to cause errors. Also are you testing this as a direct connection? The reason I ask, is that I did not see a pin to the RF module dedicated to switching its mode from TX to RX and besides you had that module remarked in your OBJ reference.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
if I understood right you are still a newbee to programming.
The complexity of your project has, compared to your experience a HUGE amount of complexity.
You maybe are thinking "no that's not complex I just added some objects"
Yes the number of projects is small compared to what f.e. microsoft word needs.
You just comment "i can not seem to get the code to work".
For me this has two possible reasons:
1) you do know a lot about programming but you are lazy in describing the problem
2) you don't have ANY idea WHERE in the code what might be the bug
if 2) is the case I HIGHLY recommend to reduce the complexity of your project
This means writing a small testprogram that does NOTHING ELSE but calculating CRC-values
- if this is working properly, you can add send and receive a TESTstring
- if this is working properly, you can add the next small part
etc. etc.
This will help you to narrow down the problem
You can go on for days, weeks, months, guessing in the fog, change the code here a bit change the code there a bit
looking at the results and again scratch your head: "why does it do .... ?? it should do ... !!"
A program does ALWAYS what YOU have programmed. If the program does something else than you expected
you don't understand what you have programmed.
The only way to narrow down a problem is to narrow down the code
What do you think the experts here do if they analyse your code ?
The take a PIECE of it and start analysing to understand what this PIECE of code is doing
Then they take the next PIECE and analyse to understand what this PIECE of code is doing
Then these experts start to write small testprograms to analyse in more details what is going on
Beautiful dream that somebody else does all the work for you
So now back to reality
If you take a look at other threads: most of the threads talk about SMALL problems
or there is a situation that somebody has become an expert TOGETHER with somebody else and now BOTH of them
are well knowing the code and can talk about details
To get QUICK help you have to reduce your code to a state that
1) the code can run on any kind of propellerboard WITHOUT additional hardware as long as the problem is not hardware-related
2) the code is reduced to ONE issue like the crc-problem
If you now think "oh - how should I reduce the code to one issue ? I just don't know"
Then your level of understanding programming is far away from that you can cope with a project like this.
Don't get me wrong I'm 100% sure that you can learn it ! The way to learn it is going back to small testprograms
testing ONE thing at ONE time.
best regards
Stefan
Post Edited (StefanL38) : 11/14/2009 6:42:53 AM GMT
with small testprograms it is not nescessary to send them hardware.
Most of the things can be done over the serial connection.
Sending data to an LCD could be emulated this way.
Maybe a software on the PC that EMULATES the serial display
(knowing the commands for set cursor etc.) and displaying it on the PC-screen the same way as
on the LC-Display is enough.
Maybe somebody would like to write a wrapper-object for PropTerminal
that PropTerminal can be used this way ?
If you define some kind of an interface between parts of the software that REALLY use the hardware and another part
that does the rest it will be easy to replace the real hardware by a simulator-method
(Which might be even remotecontroled over a serial connection to change values)
@Hanno: can ViewPort do something like this easily ? Defining knobs and switches that can simulate hardware ?
f.e. using another cog to create a signal that the original cog (wich has a setup as a delta-sigma ADC) sees in the same way
as a real analog voltage ?
best regards
Stefan
Very interesting and ambitious project. Stefan, Brad, and Beau have done a great job of helping you get closer to success. I'm a big fan of "KISS"- keep it simple stupid. Whenever you can, start with something simple that you can quickly succeed at- while still learning something. Then, keep going until you've solved big/complex problems.
Ok, Stefan asked if ViewPort can be used to "replace" hardware. I do this all the time. None of my projects have real switches/knobs/leds (PropScope, DanceBot, IODreamkit). Instead, during development or when I need to diagnose bugs, I connect a serial cable to the Propeller and start up ViewPort. Then, on my nice monitor and with big, labeled controls like dials, sliders, and buttons I control my device. Pretty much all the ~15 tutorials included in ViewPort show this concept. Here's the basic idea:
Declare and use a variable to affect some part of your program- for example, part of an "if" to control whether part of your code is run and to control how often something is run:
To integrate with ViewPort, you must include the "conduit" file which transfers data to/from the PC application at up to 2mbps. You must also tell the object which variables you wish to share with the application. So, your program will look like this:
That's it! Load to your Propeller and start up ViewPort. (See my signature for my website and a review for more information)
ViewPort gives you lots of tools to monitor variable values and even a fully integrated graphical debugger. However, in this case we'll focus on the "ViewPort Overview" panel in the bottom right. You should see 2 channels, v1 and v2- these correspond to the variables you've shared. Click on v1 to configure the name, how it'll be displayed, and how you wish to edit it. Here's where you choose what type of controls you'll use for each variable. Once you've configured everything to your liking you can "copy configuration string" and paste that code into your program.
Good luck! (As Stefan has asked previously- if you do have problems please upload your code and take your time to accurately and precisely describe your problem)
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