In 2b-8 Slave I tried to set up the program and I get an error on Cognew(start12, @stack0): "expected an expression term" The start12 is highlighted , is this a typo and what should be there.
All your requests for help are not helpful. Read your first post in this thread for instance and then put yourself in the shoes of someone far away. How would they know what you are talking about? Now I look at "In 2b-8 Master I tried" and I have absolutely no idea WHAT you are talking about. WHERE is this code and WHAT did you try etc. I understand you probably didn't have another ten seconds to attach the code or provide a link etc but why bother asking in the first place if you don't do it properly? Take your time when asking a question and keep filling in details until even your grandmother can figure out what you are saying, even if she didn't understand it.
What I'm saying is that if someone really wants help, they should take the time to spell it out properly, rather than assuming we can read minds or are willing to go rummaging through posts to fill in the details that could so easily be filed in or linked to when seeking help. My2cents.
What are you saying? That the Parallax serial terminal automatically connects to the two "other" serial pins rather than the serial programming port on P30,P31?
ser.start(25, 24, 0, 9600)
In which case the serial terminal is seeing a floating tx on P30 and therefore the garbage.
So there is no problem at all if you actually to connect the serial terminal to those serial pins you assigned.
When I copied The data from#2b-8Forum Master I copied It word for word And A slight Error Cropped up ; I changed the RX And TX from(21,20) to (11,10 ) and the serial works fine now but I tried the slave (2b-8 forum slave) but I get no readings on the terminal And this was also copied word for word.
What can I say? There is nothing complex about what you are doing, but you must pay attention to the little details such as pin numbers and baud rates and also be methodical with testing it. Here's an example, just make sure it is transmitting by writing an endless loop that does nothing more than print hello world or something. Then connect your terminal and if it isn't so, then it couldn't possibly be this simple bit of code, it must be hardware or something else. I notice that many have been helpful, but found out that they have to do all the thinking without the information and control. Now they aren't quite as willing to "help".
Be methodical, that's what I do, and make sure of all the simple things in a simple way so that any problems may be simple to solve, then there is simply no way that anything can simply go wrong. Simple.
Your PC terminal software is not even running on a Prop so of course it doesn't matter what it's written in and what it's running on. Same too with the Prop. Just get it transmitting first but obviously the Flip has integrated USB serial so you can't directly check other pins using that, you would normally need a separate USB serial dongle. But with P30,31 not being used and floating (if your software is not using it) what you can do is jumper the transmitting pin over to P30 to view it on the PC terminal. That is, since you are only using P30,31 for programming then you can use the serial terminal as a test probe from P30 to whichever pin you are testing. Capisce?
SLAVE P30 floating = SERIAL TEST PROBE connected to a pin that you want to check is transmitting.
P30 feeds the rxd of the USB serial chip that transmits data to the PC.
The slave Flip's USB is being viewed on the PC terminal at the correct baud rate of course.
You have to wire the pins for tx and Rx, I tested the master and slave programs with the two props running before posting them. The slave program purpose is only to display two variables on or off on the slave serial terminal. The slave program has some LCD stuff I used as a serial slave example, this will not affect your test functions. If you send serial ASCII or a number from a C program it should work. I only posted the pair master, slave to show some slow simple serial communication. that seemed to be your main issue serial problems.
Once again, from the top, be methodical. Why ask us the question when everything is in front of you and at your fingertips. To which I/O pins did you direct the serial info to? To which pins are your PC terminal connected to? It will have to be the same ones. The only real problem you have is yourself because you need to be looking and checking every nut and bolt but if you don't know what they do, then you've a problem right there, and you need to understand what you are doing before you go any further. The really really good thing and the really really annoying thing about processors is that they do exactly what you tell them to. So be exact.
what is pst.start(115200). Is this pertaining to the Parallax Serial Terminal and if so doesn't commenting out stop the terminal.And what about the line"serTest:=ser.Getlong. Does commenting out also stop this action. I am only using the serial terminal.
Now wire a 10K resistor from P10 on the master to the 3.3V supply on the master. And a 10K resistor from P11 on the master to the 0V common on the master.
What is that!? If you are not using any LCD stuff, strip it all out, it's just cluttering up everything. And what's with the names? Can't you be more descriptive than saying "start" "start1" "start12". The reason you need good names is so that when you read the code that you don't have to think what start12 is, it should have a name that reflects what it does. That all makes debugging easier. But just as a quick check, I stripped out all the lcd stuff from "start" (which btw is not the real start anyway) and you have a problem with indentation for the loop delay but most importantly it doesn't do anything (after you strip out the lcd stuff). Start12 looks like the main loop but once again the wrong indentation means you will never ever get out of the continual initialization !$#%^##&*!^!. But everywhere I look I just think "this is all wrong" in so many places and ways. It will continually crash and burn.
Just this bit of code alone is all wrong, including indentation (I've chopped out all the commented out code and empty lines for clarity). ser.start should only happen once since it assigns a cog to that function, so not only do you run out of cogs but you expect to also ser.start(31, 30, 0, 9600) which never gets there anyway.
P.S. Just learn simple simple things first, just a few lines of Spin code, get it right, and build up from there. Take a few days "playing" so that you learn and understand the basics.
GIGO = Garbage In - Garbage Out
I just ran your program serial cog test as is, and it works no problem. First wire your props then load your master to prop one, then load your slave to prop two. If the serial doesn't Syn. up, then power down and power up your slave only. You don't need to change anything for a Beta test, the LCD section doesn't matter. I only glitch you might encounter is if the serial doesn't Syn. the first time just power cycle the slave. Leave the master running and the pins connected. Always have the common terminals between the two props connected. Don't forget to load the EEproms when loading the programs F11. Use your button pins 5,6, and 7 on your master to see changes on your slave.
I let these run on my bench for an hour "NO PROBLEMS" just follow instructions. Everything I posted "WORKS AS IS"
Hey bbrien,
I see you are not making any progress. It is horrible to follow, and you must be feeling very dispirited.
Your real requirement is to drive two brushed motors on the telescope using an H bridge in the Control box at directions and speed set by a button push at the Hand box.
You seem to be totally bogged down by the serial protocol and communication between the Prop1 in the Hand box and the Prop1 in the Control box.
The fact that you are using an obsolete H bridge chip in the Control box does not help.
To break out of your rut, perhaps you can use a proven Prop1 system.
If you can afford a DHB-10 H bridge controller from Parallax and place that in the Control box then you can leverage off the Parallax documentation and examples to drive your telescope motors from the Hand box.
Your problem has been solved many, many time before.
To P.Jakacki ; I simply Used what digitalBob sent to me as a test. The master displays the outputs as if they are connected to the motors and I followed your suggestion of probing the s.input pin P21 to the with the Tx pin P30 and the little blue light next to the usb connector of my project board flashes approximately once per second. No serial display on the monitor
To DigitalBob; To power cycle do I use the Reset button or disconnect and reconnect the slave. Will try this again using other instructions later. Thanks
The problem is not in the DualHBridge or the main setup the the Guide camera system works fine the motors function well . The problem lies in the serial transfer of data(signals) from the hand controller. I find it more convenient to use one enable(pwm) and one phase(+,-). I want to keep the slewing in the hand box and the guiding system where they are . The tracking pulse is generated at the end of the guidance code.
@bbrien - well I can't understand how bob manages to get it to "work" because while it may compile, the code itself is just plain wrong, unless of course the version you posted is different so I will have to check that.
Just as an exercise I wrote a very short slave program in Tachyon that did nothing more than read a switch state and send that as a character and no key also as a character, so that the master would always receive a character. But I wrote it in such a way that the slave waits to receive a character first which specifies the LEDs and then it sends the key status back to the master. So the loop is super simple, receive leds, send keys. It is up to the master to send a character to set the LEDs so that it can then receive the key status from the slave. The repeat timing is totally controlled by the master. Super simple.
The master communications is very short too, with no need to full-duplex receive longs etc from the slave and in fact you don't even need full-duplex serial as I just used the equivalent of simple-serial which doesn't need another cog.
I was working off a combined schematic that you had posted earlier but that doesn't seem to match up with any code though. If you update your schematic making sure it is correct, and also label signals and switches and leds, then your code can match the schematic. So a button on the slave marked "N" for instance can be sent as the character "N" and handled by the master as such etc. Easy to follow, easy to debug, although being super simple you won't have much need to.
If you can clean up the schematic and make label the signals etc to make it readable, then you will have a better chance of making it work. It's a difficult task to make something work when you have vague or incorrect specifications.
The last three schematics that you last posted were all the same of just the hand controller. So you also need to check that what you post has been posted correctly too.
I just disconnect the V+ power wire then reconnect it. The slave program was a quick cut and paste from a larger project. That's why it has different names and LCD lines . But that doesn't affect the operation in any way. You can name a PUB any name except reserved command words. I can write PUB easterbunny for a name. So to wrap up run your serial terminal on your slave, It will be blank if the master is not communicating with it. Anybody can write code suggestions, but I test it and verify that it works before I run my mouth about how pretty it looks.
I just disconnect the V+ power wire then reconnect it. The slave program was a quick cut and paste from a larger project. That's why it has different names and LCD lines . But that doesn't affect the operation in any way. You can name a PUB any name except reserved command words. I can write PUB easterbunny for a name. So to wrap up run your serial terminal on your slave, It will be blank if the master is not communicating with it. Anybody can write code suggestions, but I test it and verify that it works before I run my mouth about how pretty it looks.
Bob, if you are leaving all that junk in there and not assigning meaningful names for functions, then you are not "helping". If you want to help someone who is finding it difficult, then clean it up. But was that your code that put ser.start in a repeat loop? There were a lot of other things that weren't right with the code. I will have to go back and check to see if that was what you posted.
P.S. looks like it was your code. I thought bbrien must have mucked it up. The "start" function is only for debug LCD info, of no use to bbrien. The "start12" function is plain wrong.
Repeat
' LCD.Cls
ser.start(21, 20, 0, 9600)
So you want to repeatedly start a new serial cog? But the repeat loop never gets to execute the waitcnt since the waitcnt is indented the same as repeat whereas it needs to be indented within the repeat, as does all the rest of the code which attempts to start another serial cog as well. It's all wrong. You are not helping.
Maybe I'm reading the indentation wrong, it might work with it the same but the other code that follows is outside the repeat indentation,
You cleaned it up but did half the job, EW_Val etc. are not assigned Add the CON, OBJ, VAR so it's ready to roll. I just ran your version without ser.start(31,30,0,9600) in the loop and I get nothing on the terminal, so write an entire project that works and has been functionally tested and get back to me. I'm not here to spoon feed. You can't argue with success my version works. Looks pretty and helpful to me.
Comments
So there is no problem at all if you actually to connect the serial terminal to those serial pins you assigned.
Be methodical, that's what I do, and make sure of all the simple things in a simple way so that any problems may be simple to solve, then there is simply no way that anything can simply go wrong. Simple.
SLAVE P30 floating = SERIAL TEST PROBE connected to a pin that you want to check is transmitting.
P30 feeds the rxd of the USB serial chip that transmits data to the PC.
The slave Flip's USB is being viewed on the PC terminal at the correct baud rate of course.
Just this bit of code alone is all wrong, including indentation (I've chopped out all the commented out code and empty lines for clarity). ser.start should only happen once since it assigns a cog to that function, so not only do you run out of cogs but you expect to also ser.start(31, 30, 0, 9600) which never gets there anyway.
PUB start12 Repeat ser.start(21, 20, 0, 9600) SerTest2:=SerTest2+2 if SerTest2 >99 SerTest:=0 if SerTest >100 reboot ser.Putlong(SerTest2) EW_Val:=ser.Getlong NS_Val:=ser.Getlong waitcnt(clkfreq/10 +cnt) ser.stop ser.start(31, 30, 0, 9600) ser.str(string( " Slave Prop ")) ser.str(string( ",N = ")) ser.Dec(NS_Val) ser.str(string( ",S = ")) ser.Dec(NS_Val) ser.str(string( ",E = ")) ser.Dec(EW_Val) ser.str(string( ",W = ")) ser.Dec(EW_Val) ser.str(string( " Direction ")) if NorthVal==1 ser.Tx(78) else ser.Tx(32) if SouthVal==2 ser.Tx(83) else ser.Tx(32) if EastVal==4 ser.Tx(69) else ser.Tx(32) if WestVal==8 ser.Tx(87) else ser.Tx(32) ser.Tx(13) waitcnt(clkfreq/10 +cnt) ser.stopP.S. Just learn simple simple things first, just a few lines of Spin code, get it right, and build up from there. Take a few days "playing" so that you learn and understand the basics.
GIGO = Garbage In - Garbage Out
I let these run on my bench for an hour "NO PROBLEMS" just follow instructions. Everything I posted "WORKS AS IS"
I see you are not making any progress. It is horrible to follow, and you must be feeling very dispirited.
Your real requirement is to drive two brushed motors on the telescope using an H bridge in the Control box at directions and speed set by a button push at the Hand box.
You seem to be totally bogged down by the serial protocol and communication between the Prop1 in the Hand box and the Prop1 in the Control box.
The fact that you are using an obsolete H bridge chip in the Control box does not help.
To break out of your rut, perhaps you can use a proven Prop1 system.
If you can afford a DHB-10 H bridge controller from Parallax and place that in the Control box then you can leverage off the Parallax documentation and examples to drive your telescope motors from the Hand box.
Your problem has been solved many, many time before.
To DigitalBob; To power cycle do I use the Reset button or disconnect and reconnect the slave. Will try this again using other instructions later. Thanks
Just as an exercise I wrote a very short slave program in Tachyon that did nothing more than read a switch state and send that as a character and no key also as a character, so that the master would always receive a character. But I wrote it in such a way that the slave waits to receive a character first which specifies the LEDs and then it sends the key status back to the master. So the loop is super simple, receive leds, send keys. It is up to the master to send a character to set the LEDs so that it can then receive the key status from the slave. The repeat timing is totally controlled by the master. Super simple.
The master communications is very short too, with no need to full-duplex receive longs etc from the slave and in fact you don't even need full-duplex serial as I just used the equivalent of simple-serial which doesn't need another cog.
I was working off a combined schematic that you had posted earlier but that doesn't seem to match up with any code though. If you update your schematic making sure it is correct, and also label signals and switches and leds, then your code can match the schematic. So a button on the slave marked "N" for instance can be sent as the character "N" and handled by the master as such etc. Easy to follow, easy to debug, although being super simple you won't have much need to.
If you can clean up the schematic and make label the signals etc to make it readable, then you will have a better chance of making it work. It's a difficult task to make something work when you have vague or incorrect specifications.
The last three schematics that you last posted were all the same of just the hand controller. So you also need to check that what you post has been posted correctly too.
Bob, if you are leaving all that junk in there and not assigning meaningful names for functions, then you are not "helping". If you want to help someone who is finding it difficult, then clean it up. But was that your code that put ser.start in a repeat loop? There were a lot of other things that weren't right with the code. I will have to go back and check to see if that was what you posted.
P.S. looks like it was your code. I thought bbrien must have mucked it up. The "start" function is only for debug LCD info, of no use to bbrien. The "start12" function is plain wrong.
Repeat ' LCD.Cls ser.start(21, 20, 0, 9600)So you want to repeatedly start a new serial cog? But the repeat loop never gets to execute the waitcnt since the waitcnt is indented the same as repeat whereas it needs to be indented within the repeat, as does all the rest of the code which attempts to start another serial cog as well. It's all wrong. You are not helping.Maybe I'm reading the indentation wrong, it might work with it the same but the other code that follows is outside the repeat indentation,