Is This Plan Okay? Proto Boards - Master/Slave
idbruce
Posts: 6,197
I am assuming this plan is okay, but I also assume that I may be overlooking the obvious 
I have a master/slave configuration and I want the master to control the power input to the slave. So I was thinking of using a relay on the the master, which would switch the VIN bus from the master, to turn power on or off to the slave VIN bus. I realize that the amperage for both boards would have to be under the ampacity of the VIN bus and I would assume that both power switches would have to be in the No. 2 servo position.
By feeding the VIN bus of the slave in this fashion, would the slave VIN then go through the 5V and 3.3V regulators to provide proper voltages to the board? I would think that it would.
EDIT***
####WARNING######
As indicated by Jon in Post #8, do not hook up a relay as I illustrated. For proper hookup, please refer to Nuts and Volts column #6 - Stamps on Steroids.
I have a master/slave configuration and I want the master to control the power input to the slave. So I was thinking of using a relay on the the master, which would switch the VIN bus from the master, to turn power on or off to the slave VIN bus. I realize that the amperage for both boards would have to be under the ampacity of the VIN bus and I would assume that both power switches would have to be in the No. 2 servo position.
By feeding the VIN bus of the slave in this fashion, would the slave VIN then go through the 5V and 3.3V regulators to provide proper voltages to the board? I would think that it would.
EDIT***
####WARNING######
As indicated by Jon in Post #8, do not hook up a relay as I illustrated. For proper hookup, please refer to Nuts and Volts column #6 - Stamps on Steroids.
473 x 490 - 96K
Comments
If the two boards are physically close, it would be simpler and cheaper to use a P-channel MOSFET to turn the power on for the second board, and a Prop pin could easily drive the MOSFET.
Why P-channel? So the boards can share ground.
http://www.electronics-tutorials.ws/transistor/tran_7.html
http://www.onsemi.com/pub_link/Collateral/AND9093-D.PDF
I believe I have the exact relay I need, but I have to desolder it from a discarded board. However I could be wrong and need to verify.
Before de-soldering, look up the data sheet of the relay so you can see what the coil activation voltage/current are.
I was wrong. That relay will not work, but I have several others, and perhaps a MOSFET or two laying around. I will have to do some digging
I don't understand your point.
To avoid potential glitches between the two boards, due to floating pins.
Eliminate the need for another power supply.
Yea, I agree, I did not put much thought into the illustration. I have been looking over the Nuts and Volts "Stamps on Steroids" column for proper hookup.
But thanks for looking out for me. I appreciate it
http://forums.parallax.com/archive/index.php/t-156486.html
I still don't get your point.
Why does the master need to control the slave at all? Why not just have them both powered from the same source so they power up at the same time? Are you running them from a battery where you really need to conserve juice?
My original thought was straight connections of VSS -> VSS + VIN-.VIN, but then I got to thinking about this thread: http://forums.parallax.com/showthread.php/160825-What-Are-My-Options-Of-Two-Props-Outputting-To-The-Same-Display
I want both Props to be able to print to the same LCD display, but I want to be able to establish a working order. So in other words, I want to be able to set the Prop pin on the master going to the LCD to a LOW state, before there is any possibility of contention, due to pin floatage, between the master and slave pins going to the LCD.
I have series resistors on both lines, but I just don't want any problems. Whether this latest idea is good or not, I really don't know, but apparently not from what you two are indicating.
I think you are far better off leaving the second board powered but if you are worried about shared I/O pins then just put a series resistor in there, say around 1K or even less, it doesn't matter as you may be over-thinking this matter. Both Props will have some floating pins before they have booted anyway and those outputs that drive devices such as mosfets etc should have pulldown/up resistors on them anyway.
Even if you short two Props together they won't be damaged or go up in a puff of smoke even though Hollywood would like you to think that everything has a built-in pyrotechnic display.
EDIT: Why don't you just simply control the reset line of the slave Prop so the master can decide when it's needed.
Thank you for chiming in, especially since you have been part of the original discussion.
I am sure that I am... I just wanted to try and be safe, without asking a billion questions, but it sounds as though I may be be causing more harm than providing protection.
I did not have any 1Ks left, and RS shelves were bare, so I tossed 470s on each line. If you do not think I will have any problems with that, then I can set both of those lines to LOW on boot, and then set them appropriately as needed. That would be my easiest route.
On the other hand, if you think I would be better controlling the reset on the slave, I can do that also.
The exact value of the resistor is unimportant unless of course it has to drive some real load rather than I/O pins, so 470 or 220 etc are fine. Perhaps if you connect up the reset of the slave back to the master you then have the option of holding it in reset if you want or not. Bear in mind that this reset pin is normally driven open-collector so just use a diode in the line if you want something else to reset the slave such as its Prop Plug.
When I have connected Props this way I sometimes devote two I/O from the master to also communicate to the slave's I2C bus ostensibly for I2C communications but more so that the master can reprogram the slave's eeprom which at the least allows default parameters to be changed.
After thinking about this a minute.... Basically I want both Props to run in parallel, so I have no plans for holding it in reset, at least for now anyhow. By the time I could possibly achieve control of the slave reset, I could have established the control that I need. For example, the first instruction for both Props, would be to set the LCD RX pins to low, as follows:
// Master Code int main(void) { low(MASTER_LCD_RX); // remaining code return 0; }// Slave Code int main(void) { low(SLAVE_LCD_RX); // remaining code return 0; }At which point, I should have full control. It is upto this point that I was worried about.
But I don't understand why you need to set this pin low as all you need is a pull-down resistor (assuming the LCD is setup for "RS232" active high) and then when a Prop has to talk to the LCD it asserts the line as an output and floats it afterwards. That way one pin does not load the other as well.
Well, perhaps I don't need to set it to LOW. This is all new to me, trying to control an LCD from two different Props
And perhaps I am worrying too much about pin floatage. My thoughts were to keep the RX lines low, until LCD ownership is transfered. When ownership is transferred, I was thinking of coding similar to the following:
lcd = serial_open(LCD_RX, LCD_RX, 0, 19200); // Keep writing to LCD until ownership is no longer required serial_close(lcd); low(MASTER_LCD_RX);The LCD probably has a pulldown on it but I'm not familiar with the LCD, normally they are logic level serial input active low, so they would need a pullup. Either way just float your transmit line after use rather than keeping it an output, that way there is no contention whatsoever.
Instead of not knowing, I just ran a simple test.
On the Prop BOE, I used IO-0 to simulate the master and IO-4 to simulate the slave, with a 470 ohm series resistor on each, and I ran the following code:
#include "simpletools.h" serial *lcd_master; serial *lcd_slave; #define LCD_OFF 21 // Turn the display off #define LCD_ON_CUR_OFF_NO_BLK 22 // Turn the display on, with cursor off and no blink #define LCD_ON_CUR_OFF_BLK 23 // Turn the display on, with cursor off and character blink #define LCD_ON_CUR_ON_NO_BLK 24 // Turn the display on, with cursor on and no blink (Default) #define LCD_ON_CUR_ON_BLK 25 // Turn the display on, with cursor on and character blink #define LCD_MV_CUR_LN_0_POS_0 128 // Move cursor to line 0, position 0 #define LCD_MV_CUR_LN_1_POS_0 148 // Move cursor to line 1, position 0 #define LCD_MV_CUR_LN_2_POS_0 168 // Move cursor to line 2, position 0 #define LCD_MV_CUR_LN_3_POS_0 188 // Move cursor to line 3, position 0 #define LCD_CLEAR 12 #define LCD_BACK_LT_ON 17 #define LCD_BACK_LT_OFF 18 #define LCD_ALERT_LENGTH 211 // Length - (208-214) #define LCD_ALERT_SCALE 219 // Scale - (215-219) #define LCD_ALERT_NOTE 221 // Note - (220-231) #define LCD_MASTER_RX 0 #define LCD_SLAVE_RX 4 int main(void) { lcd_master = serial_open(LCD_MASTER_RX, LCD_MASTER_RX, 0, 19200); lcd_slave = serial_open(LCD_SLAVE_RX, LCD_SLAVE_RX, 0, 19200); writeChar(lcd_master, LCD_ON_CUR_ON_NO_BLK); writeChar(lcd_master, LCD_BACK_LT_ON); writeChar(lcd_master, LCD_ALERT_LENGTH); writeChar(lcd_master, LCD_ALERT_SCALE); writeChar(lcd_master, LCD_CLEAR); pause(5); dprint(lcd_master, "abcdefghijklmnopqrst"); writeChar(lcd_master, LCD_MV_CUR_LN_1_POS_0); dprint(lcd_master, "abcdefghijklmnopqrst"); writeChar(lcd_master, LCD_MV_CUR_LN_2_POS_0); dprint(lcd_master, "abcdefghijklmnopqrst"); writeChar(lcd_master, LCD_MV_CUR_LN_3_POS_0); dprint(lcd_master, "abcdefghijklmnopqrst"); writeChar(lcd_master, LCD_ALERT_NOTE); waitcnt(CNT + CLKFREQ * 5); /////////////////////////////////////////////// writeChar(lcd_slave, LCD_CLEAR); pause(5); dprint(lcd_slave, "01234567890123456789"); writeChar(lcd_slave, LCD_MV_CUR_LN_1_POS_0); dprint(lcd_slave, "01234567890123456789"); writeChar(lcd_slave, LCD_MV_CUR_LN_2_POS_0); dprint(lcd_slave, "01234567890123456789"); writeChar(lcd_slave, LCD_MV_CUR_LN_3_POS_0); dprint(lcd_master, "01234567890123456789"); writeChar(lcd_slave, LCD_ALERT_NOTE); waitcnt(CNT + CLKFREQ * 5); /////////////////////////////////////////////// writeChar(lcd_master, LCD_CLEAR); pause(5); dprint(lcd_master, "abcdefghijklmnopqrst"); writeChar(lcd_master, LCD_MV_CUR_LN_1_POS_0); dprint(lcd_master, "abcdefghijklmnopqrst"); writeChar(lcd_master, LCD_MV_CUR_LN_2_POS_0); dprint(lcd_master, "abcdefghijklmnopqrst"); writeChar(lcd_master, LCD_MV_CUR_LN_3_POS_0); dprint(lcd_master, "abcdefghijklmnopqrst"); writeChar(lcd_master, LCD_ALERT_NOTE); waitcnt(CNT + CLKFREQ * 5); /////////////////////////////////////////////// writeChar(lcd_slave, LCD_CLEAR); pause(5); dprint(lcd_slave, "01234567890123456789"); writeChar(lcd_slave, LCD_MV_CUR_LN_1_POS_0); dprint(lcd_slave, "01234567890123456789"); writeChar(lcd_slave, LCD_MV_CUR_LN_2_POS_0); dprint(lcd_slave, "01234567890123456789"); writeChar(lcd_slave, LCD_MV_CUR_LN_3_POS_0); dprint(lcd_master, "01234567890123456789"); writeChar(lcd_slave, LCD_ALERT_NOTE); waitcnt(CNT + CLKFREQ * 5); return 0; }And it worked perfectly with no problems.
I should have just tried this a long time ago instead of wasting other peoples time. My apologies to you and everyone else who spent their time on these discussions, but the discussions helped get me to this point.
Thank you very much Peter
Now you know why I love to interact with the Prop using Tachyon, plus that test code would have been a breeze:
But the trouble with having series resistors and not floating the I/O is that these resistors act as a voltage divider so that while one remains high (inactive) and the other low then the lowest voltage that the LCD will see is 1.65V which is not recommend. Either float your lines afterwards or just couple the I/O via diodes but make sure the LCD has a pullup if it doesn't have one already.
Well now.... I could have shortened my code by eliminating all the defines and adding several "for" loops, but it would not have been nearly so succinct. However, my test code was all cut and paste. Took me just a couple minutes to slop it together
I must say that Tachyon gets straight to the business end of things.
Ahhh..... The caveat. I certainly overlooked the voltage divider aspect of this setup and I now understand the reason why kwinn had a pullup in his schematic, although I do need to relearn the theory of pull ups and pull downs.
How would I do that, with serial_open and serial_close?
Parallax has not posted a schematic of the #27979 Serial LCD, and even if they had, I would never be certain, even with it looking straight at me, because I need to acquire more skills in electrical theory and layout.
I am fairly certain that kwinn had this all figured out when he posted his schematic, located here: http://forums.parallax.com/attachment.php?attachmentid=114057&d=1430740998
In his schematic, he used 100 ohms for the series resistors and 2K for the pull up. Now that I have the 470s soldered in, I am uncertain of the value for the pull up.
I am really not sure what to do at this point.
A 2K pullup is still fine although a higher value would be better. The actual value is not that critical but I should have explained the idea a bit better. The two hundred ohm resistors are there only to protect the pins from over current damage in case both were outputs and one was high and the other low.
The 2K resistor is there to pull the line high when both pins are inputs. Sending data is done by outputting a low to the pin and then switching it between being an output for low and an input for high. This is similar to how a chip with open collector output works, and allows both props to check if the connection is free before starting to send data
Of course it can also be used by having the pins as outputs and setting it high or low as long as the pin is set to an input after all the data is sent.
No worries, 100 ohms is a little on the low side for no good reason, it's only a slow 19200 baud transmit output after all. If your pullup is a good 5 times higher than your drive resistor then the ratio is 1/(1+5) which means the Prop will be able to pull the LCD RXD line down to 1/6 of V+. It's unlikely that the LCD needs a 5V input signal since it was happy with half of that in your tests which is in keeping with the SX chip's TTL compatible inputs I believe. Anyway you guessed it and you can use a pullup of 3K3 or more even though 2K is probably still fine.
BTW, the same test code but no loops
Defines and constants are fine if you use them more than once but long hyphenated names just adds clutter.
EDIT: To float an output that is running from another cog you may have to close the driver which should release that pin otherwise it's simply a matter of changing its direction back to input. If you don't want the hassle of floating these lines then you could just replace the 470R resistors with diodes.
Thank you very much for the explanation.
The truth is... I should know this stuff, but I appreciate your patience and the patience of others, for tolerating my ignorance
@Peter
Now you are just showing off
As for the new schematic.... I like the idea of using diodes and eliminating the worry of floating pins. I have 1N914s and 1N4001s on hand, would these be acceptable?
1N914 signal diode (=1N4148) or 1N4001 rectifier diode? Either of these will work but a signal diode is better suited for these of course.
Me showing off?
The point of the code was just "showing off" how simple and readable it is but the main thing is that there are so many things you can just tackle on the spot rather than waiting for an approved "formula" that might work.
Interaction vs inaction, the first gives you immediate results, the latter is frustratingly slow.
As always, you have been most helpful, and thank you for sticking it through to the end with me. Once I get those 470s swapped out, I can get back to loooonnnggg hand coding
Do you do all your programming in Tachyon? Or are there some things that you must do in Spin, C, or BASIC?
No worries, I appreciate the excellent and practical work you do and the input you give to this forum.
Like many of us when we started out with the Prop we used Spin and I was really happy with that too, just to see simple source files compile and download in a few seconds. With Spin there were no libraries that you had to learn or put up with, you had "objects" which you could just modify as needed. Although it wasn't interactive it was interactive enough at the time but the thing that really killed it for me was the fact that Spin itself wasn't very fast and to use PASM you had to load that into another cog, even if it were only a tiny little snippet.
I needed a "language" that I could write real turnkey commercial applications that would run from unenhanced Propellers as it didn't make any sense to have complicated memory expansion schemes since the Prop already had limited I/O and ARM chips were just begging to be used. Basic was fine for little things but fiddly and too slow although Bean's Basic compiled to PASM but that reaches a memory limit far too soon. C was still being developed but I know that the Prop memory and architecture was too limited to run this well plus I really wanted control of the compiled code rather than scratch my head over a mystery binary blob.
Having used and written Forth before for other micros I bit the bullet and wrote Tachyon for the Prop which was in part possible because of Brad C's excellent BST compiler which allowed me to see the compiled listing so that I could go back and manipulate the source as necessary to tune the memory map. Of course I wasn't really "compiling" in the true sense as it was all PASM or byte structures but adapting Forth to suit the compiler and the Propeller resulted in Tachyon being born as the aim was to produce a very fast and compact Forth from an easy to manage single source document.
Since it's fast, it's interactive, it's compact, and easy to extend or tune the language to suit, why wouldn't I use it!?
Been reading about G-Code being a natural sub-set of FORTH, very straight forward to implement. Can't help to think a nice delta x-y routine [RUNMOD] coupled with TACHYON's file system, serial, telnet etc and some of those puppy motor controllers would make a nice little FORTH based CNC/3D printer core in one prop. And IDB I follow your threads.
Thank you for such a nice compliment. That means a lot to me, coming from a true professional.
I always wanted to learn PASM, but never set the time aside, and now that I am into the C scene, I doubt that I ever will. Anyhow, I never knew that about PASM. I can see where that would be a big turn off to the language.
That is all very interesting and quite an acheivement. Do you have any idea how many people are actively using Tachyon at this point?