The classic "I only need a little help to fly the plane, I've already gotten rid of those silly things sticking out each side because they were too long" mentality. Shirley, you're not serious.
Guy's I've tested your work and I don't have any problems, everything looks good. The OP needs some training on the basics, and maybe Windows 101. Is what it is.
I don't think he wants it working otherwise he would acknowledge us and do as we say and also accept that the problem is not hardware or software, the problem is elsewhere. He is quite good though at making something that works, not work (not in a happy way though)
Everything aside you never did tell me about the10MHz crystal and what to do about the difference in crystals I will retry the units again tomorrow using a baud of 115200. also about the pcf8574 unit.
Everything aside you never did tell me about the10MHz crystal and what to do about the difference in crystals I will retry the units again tomorrow using a baud of 115200. also about the pcf8574 unit.
I said it will work and bob says it does work, but in general I notice that you always seem reluctant to try stuff and rather poke around under the hood to find a "problem". Many of us have already said that there is no real reason why you shouldn't have had it working a long time ago already. When the recipe says "add eggs" you just add eggs, but you have to crack them first and they don't tell you how to crack them either, you should know that already.
bbrien, the attached zipfile contains your C program converted to Spin using cspin. The main routine is in scope1master.spin. I created the files simpletools.spin and fdserial.spin to provide the routines that you use from the simple library. The remaining files are from the CLIB object, which provide C-like routines written in Spin. Those files are called clib.spin, cserial.spin, cmalloc.spin and cfloatstr.spin.
The debug terminal is set for 115200 baud. scope1master.spin assumes a 5 MHz crystal, but you can change this to match your crystal frequency.
I guess the Chrome browser did not like your files but explorer edge allowed your files to be used. I will start with the master and we'll go from there. I didn't it would loook so much like the original. Thanks
From my perspective Spin is just a subset of C++, just with a different syntax and without a library. By providing a C-like library it's fairly easy to convert C code to Spin. You will need all of the files to get it to compile. Let me know if you run into any problems.
Can other people try downloading the zip file I posted. I can download it with either Edge or Chrome. However, I can't download the zip file in the SpinEdit thread with Chrome, but I can with Edge. I wonder if it depends on how the zip file is created. I used the Windows file manager to create my zip file.
Dave I downloaded it no problem. It did open my proptool2.2, but no problem, saving, copying etc. I have Win7, IE11. And if I just click on the spin post it opens up my proptool 2.2 ever since I upgraded to alpha. Again no problem to save to the library, or if anyone can't figure that out just save it to your My documents.
Put all the files except Scope one in the p.t.library and loaded the scope1 in my demos lib. and opened a ide the four leds work but no fdserial read out on the monitor. I double checked the original version in simple IDE and the monitor works. i'll take a picture as soon as I can and send it.
Your original C code never called the sendSerialData routine, so you must have changed the code to get that output. At least you are getting the prints out to the standard output.
The calls to fdserial are sending raw binary numbers to pin one. Is that what you want, or did you want ASCII characters? How are you receiving the data from pin 1, and how do you display it?
Can other people try downloading the zip file I posted. I can download it with either Edge or Chrome. However, I can't download the zip file in the SpinEdit thread with Chrome, but I can with Edge. I wonder if it depends on how the zip file is created. I used the Windows file manager to create my zip file.
Hi Dave
I have been able to download both ZIP and your individual Spin files fine, now, using regular Chrome on Windows.
However earlier in the day Chrome was issuing warnings on the same kind of files on this same site. I took screenshots and sent them on to Jeff and Jeff forwarded to Publison too I think.
So looks like something has recently relaxed (which is good news, at least for now).
I then added a call to recvSerialData immediately after the call to sendSerialData, and changed "rx = 0" to "rx = 1". By making the rx and tx pins the same I can read back the serial data that is being transmitted on pin 1. When I run this I get the same values printed for both transmit and receive.
One note of caution on your implementation. Since your serial receiver is normally on a different device, you might miss a byte on the receive side, and be out of sync with the transmitter side. You may want to send a fifth byte that is a synchronization code, so that you can ensure that the bytes are received in the correct order. The synchronization code needs to be a value that you wouldn't normally see in the rest of the data. Maybe a value of $aa, or something like that.
Another issue is that the receiver will hang waiting for a byte if the transmitter isn't sending. To avoid this, you could use rxtime1(handle, ms) to set a time limit on the number of milli-seconds it will wait to receive a byte. If the time expires it will return a value of -1.
There's no reason you can't send numbers between 0 to 500. You just have to send two bytes per value instead of one. You could even just use ASCII characters so the data stream could be viewed on a monitor. You could send 2 bytes using the characters "A" to "W". That would give you 23*23 = 529 possible values. You could use the letter "X" as the synchronization value. Or to eliminate multiplications and divisions you could use the characters " " to "_", which would give you 32*32 = 1024 values, and use some other character such as "~" for the sync byte. I could write you a couple of routines for sending and receiving data if you want.
Once I get some viable readout I will add to the routine. What I am thinking about is using a second cog to receive the data and when there is data I want to pause the main cog so I can use the output pins, other wise the main cog will be using the ewpulse pin to transmit continuously.
cspin_initialize is automatically generated by cspin in case there is some initialization that needs to be done. In your case you don't need it, and you can delete it. You would also need to delete the call to cspin_initialize in the start method. The start method calls c.start, and then calls main.
I don't understand why you are using FullDuplexSerial. The code I posted already provide this functionality. I'll rewrite you're latest code to do what I think you are trying to do. It may be an hour or so before I can get to it.
bbrien, I looked at your new code, and one of the problems is that you got rid of the fdserial object. That is what's causing the compile error. Another problem is that the file descriptor, fd, is set up to point to the serial struct. Also, the fds.start that you are calling is using pins 31 and 30, which are already used by clib's standard output. And do you really need to use 9600 baud?
I don't think there's any reason to use a separate cog for the sendSerialData/debug routine. Just call it from the cog 0. The serial drivers are already running in their own cogs, and they are using transmit and receive buffers of 64 bytes. Why are you trying to change to FullDuplexSerial and FullDuplexSerialPlus. Just use the serial driver provided by clib. This is located in cserial.spin if you want to look at it.
Tell me exactly what you want to do, and I'll help you get there.
bbrien, I think the clib routines may have been confusing you. Here is a version that uses two instances of the FullDuplexSerial object, and no other objects. The "debug" object drives the monitor screen, and the "control" object drives the controller. I added a recvSerialData routine, and set rx to pin 1 so I could test with one Propeller. You can change rx back to 0 for when connected to another Propeller.
Ok, on the slave program those are the directional indications. If you pressed North on your master prop, it would send the value to the slave prop and it would show up as N= 1 , if you released the button it returns to N=0. I think I only programmed two values, so if you pressed north it might show N=1 and S=1. And if you press east it might show E=1 and W=1. On the slave prop. I think I like Chris Gaddi's serial better by using two serial Objects, rather than my stop -start serial. Either way mine still works. And finally if your two prop's are not wired correctly for serial, the slave will remain at zero. You seem to have an issue understanding and getting serial to work. I start by sending a constant value from one prop to another like 555 or 999, just to see if it reads on the slave prop. Don't for forget your pull resistor's and it's Tx to Rx. So all you need is one wire Tx to Rx and a ground common to connect two props.
I set up your new master and the monitor displays the 8 groups of values. in value 1 and three, the current values indicated by the 4 leds are dispayed. Value1 = 250 and value3 = 200 but value 2 or 4 only show 0's.
Comments
I don't think he wants it working otherwise he would acknowledge us and do as we say and also accept that the problem is not hardware or software, the problem is elsewhere. He is quite good though at making something that works, not work
I said it will work and bob says it does work, but in general I notice that you always seem reluctant to try stuff and rather poke around under the hood to find a "problem". Many of us have already said that there is no real reason why you shouldn't have had it working a long time ago already. When the recipe says "add eggs" you just add eggs, but you have to crack them first and they don't tell you how to crack them either, you should know that already.
The debug terminal is set for 115200 baud. scope1master.spin assumes a 5 MHz crystal, but you can change this to match your crystal frequency.
Oh #$&@.
I think this bounty program is causing far more grief than without it. I mean every snake hole is being served up to the crooks on a plate.
The calls to fdserial are sending raw binary numbers to pin one. Is that what you want, or did you want ASCII characters? How are you receiving the data from pin 1, and how do you display it?
Hi Dave
I have been able to download both ZIP and your individual Spin files fine, now, using regular Chrome on Windows.
However earlier in the day Chrome was issuing warnings on the same kind of files on this same site. I took screenshots and sent them on to Jeff and Jeff forwarded to Publison too I think.
So looks like something has recently relaxed (which is good news, at least for now).
OBJ ser : "cserial" PUB recvSerialData | val1, val2, val3, val4 val1 := ser.rx1(fd) val2 := ser.rx1(fd) val3 := ser.rx1(fd) val4 := ser.rx1(fd) c.printf4(string("recvd1: %d, recvd2: %d, recvd3: %d, recvd4: %d\n\n"), val1, val2, val3, val4)I then added a call to recvSerialData immediately after the call to sendSerialData, and changed "rx = 0" to "rx = 1". By making the rx and tx pins the same I can read back the serial data that is being transmitted on pin 1. When I run this I get the same values printed for both transmit and receive.One note of caution on your implementation. Since your serial receiver is normally on a different device, you might miss a byte on the receive side, and be out of sync with the transmitter side. You may want to send a fifth byte that is a synchronization code, so that you can ensure that the bytes are received in the correct order. The synchronization code needs to be a value that you wouldn't normally see in the rest of the data. Maybe a value of $aa, or something like that.
Another issue is that the receiver will hang waiting for a byte if the transmitter isn't sending. To avoid this, you could use rxtime1(handle, ms) to set a time limit on the number of milli-seconds it will wait to receive a byte. If the time expires it will return a value of -1.
I don't understand why you are using FullDuplexSerial. The code I posted already provide this functionality. I'll rewrite you're latest code to do what I think you are trying to do. It may be an hour or so before I can get to it.
I don't think there's any reason to use a separate cog for the sendSerialData/debug routine. Just call it from the cog 0. The serial drivers are already running in their own cogs, and they are using transmit and receive buffers of 64 bytes. Why are you trying to change to FullDuplexSerial and FullDuplexSerialPlus. Just use the serial driver provided by clib. This is located in cserial.spin if you want to look at it.
Tell me exactly what you want to do, and I'll help you get there.