normally the bitvalue 1 is represented electrically by +3.3V in a 3.3V device or by +5V in a 5V device etc.
in general terms bitvalue 1 is represented by +Vdd
bitvalue 0 is represented electrically by 0.0V
normal: 1=3.3V 0=0.0V
inverted means: 1=0.0V 0=3.3V
depending on the ELECTRONIC components and the ELECTRONIC circuit the signals are sometimes inverted sometimes not
If you would like to understand this in ALL details you would have to modify the HARDWARE too.
I want to write something to your way to learn about programming
You described it with a picture finding the square root of a number by picking different numbers and multiply them.
For mathematics this way is very INEFFECTIVE. Imagine you want to find squareroot(11) and start with 0,001 then maybe trying 145,8886
going on with 0,7654 ad then 1,67 oh result is much closer than befor okay let*s try 1,68
For analysing programs that is very INEFFECTIVE too.
You will drive up the learning curve MUCH faster if you start with a working example and then modify this example-code at ONE place
and analyse the change. As soon as you change TWO things at the same time you are already LOST. Because you can not conclude anymore what made the
change in the result. Modify A or modify B????
You always attach pictures of your code. This means additional work for me to type all codelines. This is work that can be easily avoided if you provide your code as attachment to a posting.
Here I want to make a VERY CLEAR statement: I will only go on helping here if you attach your COMPLETE code as an archive created with the propellertool!
I attach a picture that shows what you have to do to archive your code with the propeller-tool
Your sample-code is put together quick and dirty without understanding the details. It's Ok to do such a try.
If you want I can post a working example for you that you have a starting point. Therefore you have to describe in normal
words what you would like to analyse next.
This that kind of a problem like with chicken and egg. What was the first where can I start to examine it with the chicken? hm then I don't understand the how the chicken comes out of the egg
if I start with egg hm i don't understand how does the chicken create the egg?
It doesn't matter where you start. You just have to make a decision start with the egg OR start with the chicken.
In case of learning SPIN this means: start with learning how serial bit streams work then you have to build up an UART out of discrete transistors (and maybe go back on how work transistors to first understand that)
or start with how basic spin-commands work and use a working serial connection for analysing the SPIN-commands
WITHOUT asking how does the serial transmission work.
best regards
Stefan
Post Edited (StefanL38) : 1/25/2010 4:44:42 PM GMT
Come on now Stefan. Your post wreaks of condescension as well as contradiction. If you go back and read all of your posts to Chris on this same thread,
you will find that I took every piece of your advice. I have started as simple as I know how in trying to learn the serial process. It's beginning to become
evident to me that the serial process must be complicated enough that very few people are commenting and no one wants to give any specific answers.
You've expressed to me how my posts have caused additional work for you, yet your post explaining this to me is 30 lines long without actually conveying
anything concerning my question of "What does ' inverted := baud < 0' actually do?". If you do not wish to post, then stop. It's that simple. I did not come
on here to be a thorn in anyone's side. I came here to maximize my knowledge in manipulating the Prop so that I can go on to develop some practical uses.
It's not as if the SPIN language has been out for so long that everyone should know it. I have worked through the What is a Microcontroller, Robotics with the
Boe-Bot, and Propeller Ed: Fundamentals books. I have read through most of the Propeller Manual. I have read through at least a hundred forum threads. I
am doing my homework.
You once posted something about being a teacher and you had specific requirements in doing so. That's fine with me. I have to ask though; why don't you
remember being the student? You never took home a math assignment of 30 problems or so from the book that the teacher had gone over the material
in class and yet, when you start working the problems you run into some trouble? So, you look back on the chapter and review some of the example
problems and still do not understand it because a few of the assigned problems are more complex than anything covered. It leaves you having to go
back to the teacher and ask how to do it. Is that reason enough for the teacher to chastise you?
I posted my code example as a picture because in my mind it was five lines of information that I believed was probably so simple to someone in the know
that they could just have a quick look and tell me what I was doing wrong. Instead, I get a 20 minute dissertation on how bad my posting skills are lacking
and how I need to go back to not ask such difficult question. Go figure...
If you don't wish to continue helping, then please don't.
Sincerely,
Raymond
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ It's not the size of the dog in the fight, but the size of the fight in the dog.
For anyone still interested in assisting (even my good friend Stefan) I have taken the Simple_Serial program, deleted all the existing comments and
inserted my own comments on what I know or don't know about each specific line item and any questions I had. It's fairly long and I don't expect anyone
to sit for any extended length of time to go over it all, but I would greatly appreciate any assistance at all. Even if it comes back to me one line
item at a time.
I have included the SPIN file as well as the archived file for those that are interested.
Thank all....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ It's not the size of the dog in the fight, but the size of the fight in the dog.
I had a quiet moment at work so I spent some time reading through this entire thread. I appreciate both the frustration of the people asking questions and also those answering them (Stefan, I hope you still have some hair left).
Radio is complicated. Learning Spin from the beginning is complicated. Getting two devices to talk to each other is complicated.
Having said that, I've written tutorials on getting picaxes to talk to PCs, and I'm one of a few people who can take a .jpg image and send it from a PC to a propeller and then send it from that propeller to another propeller wirelessly.
I very much understand the anguish of those who just want to send one byte of data between a prop and a basic stamp.
Radio modules are all different. Some are -93db. Some are -123db. My decibel maths might be a bit rusty, but I think that is a 1000 difference in sensitivity and yet you wouldn't pick that from the numbers. Sometimes you can't even find out the sensitivity. In practice, what this means is sometimes the data is only just getting there, and you move one thing on your bench and it doesn't get there, and then you spend 4 hours rewriting your perfectly good code because it now doesn't work.
Spin is complicated. There are some very good questions in eiplanner's attachment above. I wish I could answer them but I can't. But I hope someone here can (I'd find the answers helpful too).
I've solved the radio link problem by breaking things down into manageable bits.
1) Use RF modules where the data in = the data out. Some do this, some don't. But some, very frustratingly, say they do but they do not. RF modules are not a piece of wire. Put a high in one end and a high does not appear the other end. (the exception would be the bell modem code in the obex, which is absolutely brilliant).
2) I have many modules that I call 'raw RF' modules. Feed in a square wave in one end of 1khz and a square wave of 1khz comes out the other end. Feed in a high and it does not. Feed in a sine wave and a square wave comes out the other end. These are great for RS232 IF you add a preamble such "UUUUU" and you have a checksum at the end. These modules seem easy but my problem with most of them is that, quite simply, they are deaf.
3) I have been using transceiver modules from Hope and Yishi and Sure and these have onboard micros and RS232 data in truly does equal data out. Also they have buffers and they tend to be a lot more sensitive. I finally settled on the Yishi ones because they have the biggest buffer.
4) Use standard voltage levels. 5V TTL is fine till you have to interface to 3V. Is it resting high or low? Can you short the pin? Can you connect outputs to outputs and not damage things. This is why I like RS232, so I end up using lots of max232 chips, even when a signal goes 3V=>max232=>max232=>5V that at least in the middle the RS232 levels are standard and will connect to any other RS232 device. Becuase...
5) The first device you need to connect to is something to help debug it when it doesn't work. So, now you need standard plugs. There are many standards but I chose the D9 plug because it is cheap. Use just 3 wires (Tx, Rx, Gnd). Make male plugs always output on pin 3 and females always on pin 2, and then everything will always connect to everything else. Make a few crossover cables eg a female to female that swaps pins 2 and 3.
6) Put D9 plugs on all radio modules. If they don't have RS232 levels, then add a max232.
7) Start with wired connections. Use RS232 cables. Sniff the data with a splitter that goes to a PC and a terminal program. Only replace the wire with a wireless conenction when it is proved to work with wires.
8) Pick a comms standard. You can write your own little protocol with a wakeup preamble and a checksum. Or use a file transfer protocol like xmodem (which was designed to handle noisy phone lines).
9) Have multiple ways of debugging things. I can send data to a small LCD display, a VGA display and a serial terminal. Sometimes I've had to use one to debug code for the other. This means you can test what is going on (eg how do you debug serial code that is supposed to be sending data back to your PC when the very object you are debugging is the serial driver object?).
10) Start with something that already works and pull it to bits and modify it, one line of code and one component at a time. Test and retest. Go back if necessary. This is much easier than starting from scratch.
I know this doesn't answer all the specific questions, but hopefully helps someone avoid accumulating a shed full of partially working wireless modules like I have.
I'm still not able to get any kind of readable results out of the calls to FullDuplexSerialPlus.
I've posted my code and a picture of the result.
I am trying to see what the program assigns to the 'inverted' variable because later on in the process
it get's AND'ed with a pin variable and I was wanting to be able to calculate the result by assigning the
parameters a known value and then following those parameters through the program so I can see
how things worked mathematically.
I wonder if someone else running this program gets the same results that I am getting?
Thanks Again...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ It's not the size of the dog in the fight, but the size of the fight in the dog.
Thank you Dr_Acula for the well thought out information. I will no doubt keep coming back to review it often as I forge ahead.
The least amount of sliding glass doors I can smash into, the better.
I haven't even got to the point where I have tested the transceivers. I am currently trying to gain some knowledge into how
it is all supposed to work programming wise. I figured if I took a working model and deciphered it, I could accomplish two things:
1. Learn more about the workings of serial communication.
2. Learn more about SPIN programming.
So far, even though it's not outwardly evident, I have learned a great deal. Through those that have commented on this thread
and through reading and studying all the materials I can come across. I feel I am getting pretty familiar with the serial process
and how it's supposed to work. I just need to equate that into SPIN programming. Which, I am beginning to see a little light at
the end of the tunnel.
Or is that just a mirage?
Thanks again for your input...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ It's not the size of the dog in the fight, but the size of the fight in the dog.
Here are the commented files. Personally, I think you're going about this whole learning process in a poorly productive way. Look at the "What's a Microcontroller?" tutorial. It builds a set of concepts and the understanding that goes with them one step at a time with focused examples and experiments at every step. The Propeller Education Kit Labs goes through something similar for the Propeller. It's obvious from your comments and questions that you're missing the understanding of some basic programming concepts and trying to understand some moderately sophisticated examples that were not intended for teaching purpose. Please start with the basics. I guarantee that you will repeatedly trip over the lack of understanding of things like basic arithmetic and number systems. For hardware, you need to understand basic electricity concepts, Ohm's Law, Kirchoff's Laws, and probably some other basic stuff. Use the Wikipedia and follow the links that they provide to more detailed information.
OK Mike, if I haven't lost you yet, I have just got done reading through your comments in the Practice_Simple_Serial file. I wanna say
thank you very much again for all the time you spent to help me. Big thanks. It's the most information I have received yet.
Prior to this, I did spend some time on Wiki looking up negative binary. What I found was that there are a few different methods of
calculating negative binary numbers (Sign & Magnitude, One's Compliment, Two's Compliment, Excess-N, Base-2). I didn't spend a
lot of time trying to memorize the different methods because I wanted to ask someone here which method the Propeller uses.
Now, you've cleared that up for me so I will become familiar with two's compliment. By the way, if ever you run across another person
that wants to learn the ins and outs of serial communications like me, send them to look up UART in the Wiki. It has a very easy to follow
description of the whole process as well as many linking articles. I have Stefan to thank for that one.
When it comes to this instruction: rxByte := ina[noparse][[/noparse]sin] << 7 | rxByte >> 1 You have no idea how many times I worked it out. I even made
a self-calculating excel spreadsheet, which I will attach for your review, to show me the result of these operators. The outcome of which
solely depends on the number of bit the propeller is using in these calculations. The loop only runs 8 times. If I understand that correctly
it will receive 8 bits. This is where my question stemmed from. If the processor only uses these 8 bits then this calculation will always
result in 11111111 no mater what the received 8 bits were. If this calculation takes these 8 bits and places them into a 32 bit memory
location and then performs the operations it will be a completely different result. And even on top of that, does it place these 8 bits in
the LSB or MSB? Two completely different results. That's where I was coming from with those questions.
In the Practice file that you commented on, you stated that every variable value is stored in a 32 bit stack. I am now assuming this is
the case with rxByte. So now I have to ask, when a condition variable like the 'inverted' variable in the program is found to be true,
is the actual stored value 00000000000000000000000000000000 or 11111111111111111111111111111111?
Several hours after I first posted that program with all of my comments inside, is when I found the UART article and am now more familiar
with the signaling that I had question on. Tough sometimes to locate all the right study materials in the right order. I've read through many
many Wiki articles and associated links, prior to this morning when I got that suggestion from Stefan, without running across it myself.
Thank you very much Mike for all the time you have given me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ It's not the size of the dog in the fight, but the size of the fight in the dog.
Sorry, forgot to attach my excel file to show you that I did perform the work.
Thanks Again!
Well, it doesn't allow me to upload my excel file so I turned it into a txt file that is tab delimited.
Not sure if it will open properly or not. When I saved it this way, it told me that many formulas
may not follow the document. I would think you should still be able to see the file but it
might not perform its functions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ and so, the journey continues..........
Post Edited (eiplanner) : 2/10/2010 2:28:38 PM GMT
i have read through the thread from start to finish, i wanted to applagize to everyone if i have caused any trouble or loss of hair . I have reworked the way in wich i hammer my problems out since my last post i have read propeller books and tutorials over and over. I am very upset with myself i still dont understand how to send a string through my RF units.But i understand what you guys are looking for in explaining my problems, so i will have screnshots and zip files on my next post.
Hello everyone i have a few questions i have found a way i can send text from my rf modules but it always gives a value of 28. i posted my code and a terminal screenshot
in the rar that was posted above in my earlyer comment is there any exmpales in the manual that can help me send a string using simple serial i see how is sends a number but an array of strings sgould work the same way correct.
I'm new to the forum and this post, I have been reading this post and I am using your Transceiver TX Demo object with the subroutine RF Transceiver object and·2nd subroutines·Full Duplex·Serial and CRC_polynomial_oneshot objects. Below you say that in the RF Transciver object, "you·load the buffer with what you what to send and give a command to send."·I have·looked in the PE Education lab book, the Propeller Manual, and the Programming and Customizing the Multicore Propeller Microcontroller book.·But I still need your help understanding where the buffer is·in your RF Transceiver object.
If you could respond as soon as possible, I would be very greatful.
Thank you for your time,
MichelleS.
Beau Schwabe (Parallax) said...
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.
Sorry for the late response, I have been having computer troubles and 'cleaning' my system.
In answer to your question, the buffer is located within the RF_Transceiver object towards the bottom in the DAT section.
What may appear to be a label called TX_Address is actually the address location of the TX buffer. [noparse][[/noparse]see the DAT section in the Propeller Manual] In this section, the TX_Address is defined as a symbol. The DATA that follows is aligned as a BYTE... I could have used the optional 'size' but I went with a visual BLOCK of reserved data memory.
The way it's used in this application as far as the other PUB's are concerned, TX_Address ,acts like the buffer itself with an offset index value to load a specific location with.
Example:
TX_Address[noparse][[/noparse]9] := 200
This would place a value of 200 in the 10th position in the buffer (remember 0 counts as a valid placeholder)
Next to this label in the DAT section you will notice several byte placeholders. THIS is where the data actually lives when you place it there using the PutTX command.
If you wanted to place a string in the buffer you would need to add a PUB command that provides the String address. [noparse][[/noparse]see the String function in the Propeller manual] Also you would need to know the String size. [noparse][[/noparse]see STRSIZE in the Propeller manual]
Together with the string address and string size referring to the example above a BYTEMOVE can be used to move a string into the TX_Address before sending the data packet. [noparse][[/noparse]see BYTEMOVE in the propeller manual]
To Beau Schwabe (anyone who may be able to help) ·,
Thank you very much for response to my post.
In your previous post, you say "If you wanted to place a string in the buffer you would need to add a PUB command that provides the String address. [noparse][[/noparse]see the String function in the Propeller manual] Also you would need to know the String size. [noparse][[/noparse]see STRSIZE in the Propeller manual]
Together with the string address and string size referring to the example above a BYTEMOVE can be used to move a string into the TX_Address before sending the data packet. [noparse][[/noparse]see BYTEMOVE in the propeller manual]
something like...
BYTEMOVE(TX_Address, {String Address}, {String Size})".· I am not sure if I put the string in the right place. Was I supposed to put the string in the RF_Transceiver object? Or am I suppose to create a new object for the string and put PUB command in the RF_Transceiver object to tell it where the string is. I’m trying to send the words “Hello_World” in the buffer. My modified RF_Transceiver object will compile, but the words do not show up in the Parallax Serial Terminal on the other end. My modified RF_Transceiver object is attached below.
Comments
normally the bitvalue 1 is represented electrically by +3.3V in a 3.3V device or by +5V in a 5V device etc.
in general terms bitvalue 1 is represented by +Vdd
bitvalue 0 is represented electrically by 0.0V
normal: 1=3.3V 0=0.0V
inverted means: 1=0.0V 0=3.3V
depending on the ELECTRONIC components and the ELECTRONIC circuit the signals are sometimes inverted sometimes not
If you would like to understand this in ALL details you would have to modify the HARDWARE too.
I want to write something to your way to learn about programming
You described it with a picture finding the square root of a number by picking different numbers and multiply them.
For mathematics this way is very INEFFECTIVE. Imagine you want to find squareroot(11) and start with 0,001 then maybe trying 145,8886
going on with 0,7654 ad then 1,67 oh result is much closer than befor okay let*s try 1,68
For analysing programs that is very INEFFECTIVE too.
You will drive up the learning curve MUCH faster if you start with a working example and then modify this example-code at ONE place
and analyse the change. As soon as you change TWO things at the same time you are already LOST. Because you can not conclude anymore what made the
change in the result. Modify A or modify B????
You always attach pictures of your code. This means additional work for me to type all codelines. This is work that can be easily avoided if you provide your code as attachment to a posting.
Here I want to make a VERY CLEAR statement: I will only go on helping here if you attach your COMPLETE code as an archive created with the propellertool!
I attach a picture that shows what you have to do to archive your code with the propeller-tool
Your sample-code is put together quick and dirty without understanding the details. It's Ok to do such a try.
If you want I can post a working example for you that you have a starting point. Therefore you have to describe in normal
words what you would like to analyse next.
This that kind of a problem like with chicken and egg. What was the first where can I start to examine it with the chicken? hm then I don't understand the how the chicken comes out of the egg
if I start with egg hm i don't understand how does the chicken create the egg?
It doesn't matter where you start. You just have to make a decision start with the egg OR start with the chicken.
In case of learning SPIN this means: start with learning how serial bit streams work then you have to build up an UART out of discrete transistors (and maybe go back on how work transistors to first understand that)
or start with how basic spin-commands work and use a working serial connection for analysing the SPIN-commands
WITHOUT asking how does the serial transmission work.
best regards
Stefan
Post Edited (StefanL38) : 1/25/2010 4:44:42 PM GMT
you will find that I took every piece of your advice. I have started as simple as I know how in trying to learn the serial process. It's beginning to become
evident to me that the serial process must be complicated enough that very few people are commenting and no one wants to give any specific answers.
You've expressed to me how my posts have caused additional work for you, yet your post explaining this to me is 30 lines long without actually conveying
anything concerning my question of "What does ' inverted := baud < 0' actually do?". If you do not wish to post, then stop. It's that simple. I did not come
on here to be a thorn in anyone's side. I came here to maximize my knowledge in manipulating the Prop so that I can go on to develop some practical uses.
It's not as if the SPIN language has been out for so long that everyone should know it. I have worked through the What is a Microcontroller, Robotics with the
Boe-Bot, and Propeller Ed: Fundamentals books. I have read through most of the Propeller Manual. I have read through at least a hundred forum threads. I
am doing my homework.
You once posted something about being a teacher and you had specific requirements in doing so. That's fine with me. I have to ask though; why don't you
remember being the student? You never took home a math assignment of 30 problems or so from the book that the teacher had gone over the material
in class and yet, when you start working the problems you run into some trouble? So, you look back on the chapter and review some of the example
problems and still do not understand it because a few of the assigned problems are more complex than anything covered. It leaves you having to go
back to the teacher and ask how to do it. Is that reason enough for the teacher to chastise you?
I posted my code example as a picture because in my mind it was five lines of information that I believed was probably so simple to someone in the know
that they could just have a quick look and tell me what I was doing wrong. Instead, I get a 20 minute dissertation on how bad my posting skills are lacking
and how I need to go back to not ask such difficult question. Go figure...
If you don't wish to continue helping, then please don't.
Sincerely,
Raymond
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It's not the size of the dog in the fight, but the size of the fight in the dog.
inserted my own comments on what I know or don't know about each specific line item and any questions I had. It's fairly long and I don't expect anyone
to sit for any extended length of time to go over it all, but I would greatly appreciate any assistance at all. Even if it comes back to me one line
item at a time.
I have included the SPIN file as well as the archived file for those that are interested.
Thank all....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It's not the size of the dog in the fight, but the size of the fight in the dog.
if Tester Debug.str(string("true ")) else Debug.str(string("false "))If you really want to see the numeric value, then
Debug.dec(Tester)
I'll have a look at your serial code later this evening and comment on it
Post Edited (Mike Green) : 1/26/2010 1:23:24 AM GMT
Radio is complicated. Learning Spin from the beginning is complicated. Getting two devices to talk to each other is complicated.
Having said that, I've written tutorials on getting picaxes to talk to PCs, and I'm one of a few people who can take a .jpg image and send it from a PC to a propeller and then send it from that propeller to another propeller wirelessly.
I very much understand the anguish of those who just want to send one byte of data between a prop and a basic stamp.
Radio modules are all different. Some are -93db. Some are -123db. My decibel maths might be a bit rusty, but I think that is a 1000 difference in sensitivity and yet you wouldn't pick that from the numbers. Sometimes you can't even find out the sensitivity. In practice, what this means is sometimes the data is only just getting there, and you move one thing on your bench and it doesn't get there, and then you spend 4 hours rewriting your perfectly good code because it now doesn't work.
Spin is complicated. There are some very good questions in eiplanner's attachment above. I wish I could answer them but I can't. But I hope someone here can (I'd find the answers helpful too).
I've solved the radio link problem by breaking things down into manageable bits.
1) Use RF modules where the data in = the data out. Some do this, some don't. But some, very frustratingly, say they do but they do not. RF modules are not a piece of wire. Put a high in one end and a high does not appear the other end. (the exception would be the bell modem code in the obex, which is absolutely brilliant).
2) I have many modules that I call 'raw RF' modules. Feed in a square wave in one end of 1khz and a square wave of 1khz comes out the other end. Feed in a high and it does not. Feed in a sine wave and a square wave comes out the other end. These are great for RS232 IF you add a preamble such "UUUUU" and you have a checksum at the end. These modules seem easy but my problem with most of them is that, quite simply, they are deaf.
3) I have been using transceiver modules from Hope and Yishi and Sure and these have onboard micros and RS232 data in truly does equal data out. Also they have buffers and they tend to be a lot more sensitive. I finally settled on the Yishi ones because they have the biggest buffer.
4) Use standard voltage levels. 5V TTL is fine till you have to interface to 3V. Is it resting high or low? Can you short the pin? Can you connect outputs to outputs and not damage things. This is why I like RS232, so I end up using lots of max232 chips, even when a signal goes 3V=>max232=>max232=>5V that at least in the middle the RS232 levels are standard and will connect to any other RS232 device. Becuase...
5) The first device you need to connect to is something to help debug it when it doesn't work. So, now you need standard plugs. There are many standards but I chose the D9 plug because it is cheap. Use just 3 wires (Tx, Rx, Gnd). Make male plugs always output on pin 3 and females always on pin 2, and then everything will always connect to everything else. Make a few crossover cables eg a female to female that swaps pins 2 and 3.
6) Put D9 plugs on all radio modules. If they don't have RS232 levels, then add a max232.
7) Start with wired connections. Use RS232 cables. Sniff the data with a splitter that goes to a PC and a terminal program. Only replace the wire with a wireless conenction when it is proved to work with wires.
8) Pick a comms standard. You can write your own little protocol with a wakeup preamble and a checksum. Or use a file transfer protocol like xmodem (which was designed to handle noisy phone lines).
9) Have multiple ways of debugging things. I can send data to a small LCD display, a VGA display and a serial terminal. Sometimes I've had to use one to debug code for the other. This means you can test what is going on (eg how do you debug serial code that is supposed to be sending data back to your PC when the very object you are debugging is the serial driver object?).
10) Start with something that already works and pull it to bits and modify it, one line of code and one component at a time. Test and retest. Go back if necessary. This is much easier than starting from scratch.
I know this doesn't answer all the specific questions, but hopefully helps someone avoid accumulating a shed full of partially working wireless modules like I have.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I'm still not able to get any kind of readable results out of the calls to FullDuplexSerialPlus.
I've posted my code and a picture of the result.
I am trying to see what the program assigns to the 'inverted' variable because later on in the process
it get's AND'ed with a pin variable and I was wanting to be able to calculate the result by assigning the
parameters a known value and then following those parameters through the program so I can see
how things worked mathematically.
I wonder if someone else running this program gets the same results that I am getting?
Thanks Again...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It's not the size of the dog in the fight, but the size of the fight in the dog.
The least amount of sliding glass doors I can smash into, the better.
I haven't even got to the point where I have tested the transceivers. I am currently trying to gain some knowledge into how
it is all supposed to work programming wise. I figured if I took a working model and deciphered it, I could accomplish two things:
1. Learn more about the workings of serial communication.
2. Learn more about SPIN programming.
So far, even though it's not outwardly evident, I have learned a great deal. Through those that have commented on this thread
and through reading and studying all the materials I can come across. I feel I am getting pretty familiar with the serial process
and how it's supposed to work. I just need to equate that into SPIN programming. Which, I am beginning to see a little light at
the end of the tunnel.
Or is that just a mirage?
Thanks again for your input...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It's not the size of the dog in the fight, but the size of the fight in the dog.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
and so, the journey continues..........
Post Edited (eiplanner) : 2/10/2010 2:30:58 PM GMT
thank you very much again for all the time you spent to help me. Big thanks. It's the most information I have received yet.
Prior to this, I did spend some time on Wiki looking up negative binary. What I found was that there are a few different methods of
calculating negative binary numbers (Sign & Magnitude, One's Compliment, Two's Compliment, Excess-N, Base-2). I didn't spend a
lot of time trying to memorize the different methods because I wanted to ask someone here which method the Propeller uses.
Now, you've cleared that up for me so I will become familiar with two's compliment. By the way, if ever you run across another person
that wants to learn the ins and outs of serial communications like me, send them to look up UART in the Wiki. It has a very easy to follow
description of the whole process as well as many linking articles. I have Stefan to thank for that one.
When it comes to this instruction: rxByte := ina[noparse][[/noparse]sin] << 7 | rxByte >> 1 You have no idea how many times I worked it out. I even made
a self-calculating excel spreadsheet, which I will attach for your review, to show me the result of these operators. The outcome of which
solely depends on the number of bit the propeller is using in these calculations. The loop only runs 8 times. If I understand that correctly
it will receive 8 bits. This is where my question stemmed from. If the processor only uses these 8 bits then this calculation will always
result in 11111111 no mater what the received 8 bits were. If this calculation takes these 8 bits and places them into a 32 bit memory
location and then performs the operations it will be a completely different result. And even on top of that, does it place these 8 bits in
the LSB or MSB? Two completely different results. That's where I was coming from with those questions.
In the Practice file that you commented on, you stated that every variable value is stored in a 32 bit stack. I am now assuming this is
the case with rxByte. So now I have to ask, when a condition variable like the 'inverted' variable in the program is found to be true,
is the actual stored value 00000000000000000000000000000000 or 11111111111111111111111111111111?
Several hours after I first posted that program with all of my comments inside, is when I found the UART article and am now more familiar
with the signaling that I had question on. Tough sometimes to locate all the right study materials in the right order. I've read through many
many Wiki articles and associated links, prior to this morning when I got that suggestion from Stefan, without running across it myself.
Thank you very much Mike for all the time you have given me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It's not the size of the dog in the fight, but the size of the fight in the dog.
Thanks Again!
Well, it doesn't allow me to upload my excel file so I turned it into a txt file that is tab delimited.
Not sure if it will open properly or not. When I saved it this way, it told me that many formulas
may not follow the document. I would think you should still be able to see the file but it
might not perform its functions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
and so, the journey continues..........
Post Edited (eiplanner) : 2/10/2010 2:28:38 PM GMT
i have read through the thread from start to finish, i wanted to applagize to everyone if i have caused any trouble or loss of hair
Post Edited (chris jones) : 3/3/2010 1:37:51 PM GMT
I'm new to the forum and this post, I have been reading this post and I am using your Transceiver TX Demo object with the subroutine RF Transceiver object and·2nd subroutines·Full Duplex·Serial and CRC_polynomial_oneshot objects. Below you say that in the RF Transciver object, "you·load the buffer with what you what to send and give a command to send."·I have·looked in the PE Education lab book, the Propeller Manual, and the Programming and Customizing the Multicore Propeller Microcontroller book.·But I still need your help understanding where the buffer is·in your RF Transceiver object.
If you could respond as soon as possible, I would be very greatful.
Thank you for your time,
MichelleS.
can anyone give m4e any hints on how i will send a string of data instead of the numbers that the code currently sends?
Sorry for the late response, I have been having computer troubles and 'cleaning' my system.
In answer to your question, the buffer is located within the RF_Transceiver object towards the bottom in the DAT section.
What may appear to be a label called TX_Address is actually the address location of the TX buffer. [noparse][[/noparse]see the DAT section in the Propeller Manual] In this section, the TX_Address is defined as a symbol. The DATA that follows is aligned as a BYTE... I could have used the optional 'size' but I went with a visual BLOCK of reserved data memory.
The way it's used in this application as far as the other PUB's are concerned, TX_Address ,acts like the buffer itself with an offset index value to load a specific location with.
Example:
TX_Address[noparse][[/noparse]9] := 200
This would place a value of 200 in the 10th position in the buffer (remember 0 counts as a valid placeholder)
Next to this label in the DAT section you will notice several byte placeholders. THIS is where the data actually lives when you place it there using the PutTX command.
If you wanted to place a string in the buffer you would need to add a PUB command that provides the String address. [noparse][[/noparse]see the String function in the Propeller manual] Also you would need to know the String size. [noparse][[/noparse]see STRSIZE in the Propeller manual]
Together with the string address and string size referring to the example above a BYTEMOVE can be used to move a string into the TX_Address before sending the data packet. [noparse][[/noparse]see BYTEMOVE in the propeller manual]
something like...
BYTEMOVE(TX_Address, {String Address}, {String Size})
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Again, sorry for the late response, I have been having computer troubles and 'cleaning' my system.
If you are using the CRC version, then the reply above to Michelle S. should point you in the right direction.
If on the other hand you are using a raw transmission. i.e. the non CRC method, then instead of using
RFTransmit.tx(i) in a repeat loop, use the RFTransmit.str(String("Your String Here")) instead.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Thank you very much for response to my post.
In your previous post, you say "If you wanted to place a string in the buffer you would need to add a PUB command that provides the String address. [noparse][[/noparse]see the String function in the Propeller manual] Also you would need to know the String size. [noparse][[/noparse]see STRSIZE in the Propeller manual]
Together with the string address and string size referring to the example above a BYTEMOVE can be used to move a string into the TX_Address before sending the data packet. [noparse][[/noparse]see BYTEMOVE in the propeller manual]
something like...
BYTEMOVE(TX_Address, {String Address}, {String Size})".· I am not sure if I put the string in the right place. Was I supposed to put the string in the RF_Transceiver object? Or am I suppose to create a new object for the string and put PUB command in the RF_Transceiver object to tell it where the string is. I’m trying to send the words “Hello_World” in the buffer. My modified RF_Transceiver object will compile, but the words do not show up in the Parallax Serial Terminal on the other end. My modified RF_Transceiver object is attached below.
Thank you very much for your time and help.
MichelleS.
Try this updated version to handle strings ...
http://forums.parallax.com/showthread.php?p=896816
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.