rrinkerI'm kind of surprised an EE said no to external pullups, just use the internals, that sounds more like a programmer mentality, the "I know all about circuit design because I learned Arduino" sort of thing.
Can't say one way or the other -- haven't seen him around my little corner of the internet in months. (Hope all's well for him...)
-Dan
Builder of Bowser steam! Railimages Site
I'll have to upload it. I thought it was already on my web site but it's not, that was an ancient version before I finalized anything at all. Even the current full schematic I have is not accurate to what I have working on the bench, it's a version before I added the second relay and heartbeat LED. But it gets the idea across. I may have changed actual pin usage as well. I'm in the midst of redrawing it in EasyEDA so I cna go right to the PCB design - the existing one, I REALLY wanted to like KiCAD because it's free and open source but me and the process it uses just don't get along.
Right now it uses every one of the 20 pins available, unless I go for the surface mount version of the 328 which adds 2 more analog pins. And, well, just not going to happen. Not only is there the issue of soldering SMD, I'd also have to provide ICSP an ICSP header - I already built a handy little programmer with a ZIF socket to program the DIP version.
Another design criteria is that the remote lock inputs are pulled up so that if I power on the layout but do not power on or initialize the CMRI nodes remote controlling the turnouts, the local buttons default to unlocked - so that I cna fire up the layout and run trains by myself and not have to deal with a dispatcher. When the dispatcher is present, the default state for all mainline turnouts would be locked, and a locla crew can only press a button if the DS first unlocks the turnout. Granted this would work with internal pullups or external, although the internals tend to be relatively weak so when there is some distance of cable connecting the two devices, a stronger external pullup may help reliability.
I'm kind of surprised an EE said no to external pullups, just use the internals, that sounds more like a programmer mentality, the "I know all about circuit design because I learned Arduino" sort of thing. That said, my breadboard version using an Arduino Nano is using internal pullups. Once I have the schmatic finalized I want to build one up exactly - standalong micro, pullups, debounce caps, power supply (currently cheating on that as well, running it off my bench supply), and the exact lighted pushbuttons I intend to use on the real thing, before I get a board made.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
rrinkerMy first schematic had no pullups, I was using the internals. WHen I posted it to an EE forum, I more or less got raked over the coals for not having physical pullups.
Funny, I got the same for using externals from an EE. Sounds like there's no hard and fast rule for it.
i suggested and smd because it's small, assuming you wouldn't need one and allows one to be added if needed
have you considered pull-ups and down on the output to be used to ID a board so that one version of software can be used to support different variants of hardware?
could you provide a link to schematic?
greg - Philadelphia & Reading / Reading
Just say no to SMD. With my eyes I'm glad I can still do through hole.
With the ATMega 328, there are two ways to set the input pullup - the right way (set the register - or if using the Arduino libraries instead of direct access to the registers, declare the pin an INPUT_PULLUP) or, through a quirk in the Arduino Library, perform a write to a pin declared as input - it turns on the pullup! Or, it did in some versions of the Arduino libraries. Not really the right way to do things, but it worked.
I already can leave out my resistors and use the internals. Since they are pullups, leaving them off the board won't break anything, unless I then forget to change the code to enable the internal pullup.
My first schematic had no pullups, I was using the internals. WHen I posted it to an EE forum, I more or less got raked over the coals for not having physical pullups.
why not make a 10k smd a stuffing option and take advantage of an internal pull-up?
i'd be very surpised that selection of a pull-up or pull-down is a fuse setting for each GPIO. In some chips, drive current is also programmable. I've worked on systems where external pull-ups and pull-down are used to determine configuration options at start up. The GPIO pull-up/down is programmed after reading the GPIOs first.
Maybe? But it's set with a register in the code for sure. Maybe there's a fuse to override that.
But then you might be stuck if you want to disable internal pullups and use internal. For goofing around and testing things, nothing wrong with internal pullups, but good design practice is to use external ones if you need pullups.
Pretty sure that with the micro in question, it's a control fuse (i.e. can be set outside the code).
Sure, you can use external pullups - it's just more components :)
Bad form. A code mistake could leave you with no pullups. And while the micro in question has onboard pullups, not all do. Physical pullups will always be there.
rrinkeralthought he pullup resistor probbaly would need to stay since those lines are inputs to the micro and floating inputs is bad design
Why not use the onboard pullups on the micro?
I meant keeping the servo controoller itself generic, instead of having one version I use when the turnouts are also under dispatcher control and a different circuit to use where they are only locally controlled. ANd also not wanting to remove the one set of relays which I most likely do not need because I will be doing the wiring modifications to my turnouts before installing them, but if someone else wanted to use this circuit, they might need the two relay apprach = though I suppose if I leave that, I don't need to actually modify the turnouts. It wouldn't be too hard to modify the code so that the frog polaity relay switches midway in the throw, either. Bah, I start out with what I think it the ultimate fits any situation solution and now I have doubts. The thing is, unused parts could be easily left off the board - a jumper replacing the one relay, and the control transistor and blocking diode just left off, I was planning to do such things for the ones used for yards - leave off the connector for the remote control, the debounce caps, the pullup resistors, and the protection resistors. 8 resistors, 4 caps, and an RJ46 connector just not installed, althought he pullup resistor probbaly would need to stay since those lines are inputs to the micro and floating inputs is bad design. But just the same - not a different PCB, it's stillt he same PCB and if I had a spare built for standalone but needed another remote one, all I would have to do is add in the missing components. Someone using plastic frog turnouts with no way to power them could leave off all the relays and associated parts - the transistors, the diodes, and the screw terminals for the power wires. I do like the idea of getting the signal from something physically connected to the turnout, like option 1 - the thing is, even if I simplfy further, like using just a single relay that changes mid-throw instead of the dual relay, I only free up 2 pins, so it buys me exactly nothing - not enough pins to add a 3rd servo to the mix, and I don't know that I would want to. 2 per controller is a perfect match for a double ended siding or a crossover.
That's what I mean by generic - once PCB, one firmware, leave out or install parts as needed for whichever features you wnat to implement.
I think I'll just leave it as-is and not continue to analyze things. I want to get this done and get boards made because I am going to get the basement finished up as soon as it gets warm again (have to rip out the heat to rip out the old walls) and then I am going to start building. I've procrastinated enough, I want to get this built and going while I'm still around to enjoy it.
Yeah, but does it mean the switch board will "only" be a switch board? I mean, you were talking about wanting the things to be generic ...
I am really leaning towards option 1. It's the simplest, and nothing I;ve done so far needs to change.
I'm using the same buttons with LEDs as they used on the Canadian Canyons layout. Monitoring momentary buttons is super easy with a micro, it's in the code I posted a while back - even debounced, so I don't really need to add electronic debouncing to the circuit.
I'd use a combination -- a SPDT switch on the throwbar indicating turnout position (or well, where we think the turnout is) feeding an input on a 23x17 for "actual position" (which you can then compare to an input for "desired position" and throw errors).
I's probably have toggles on the fascia rather than pushbuttons, but that's because I'm not smart when it comes to latching for momentary-contacts (i.e. pushbuttons).
i'm for option one .... it's -relatively- the simplest and although it requires extra wires, it's also the most effective in my opinion ..
Recent discussions made me realize I left one thing out of my turnout controller - feedback of the position. But my current design is out of I/O pins. Did some thinking and looking at options, found a couple of alternatives
1. Use something like the Tam Valley servo bracket (part way down this page: http://tamvalleydepot.com/products/servosaccessories.html ) to mount my servos. This bracket allows for a microswitch as well as the servo. The microswitch could be the feedback (frog polarity is controlled by relays on my controller). I would get just he brackets, I can get SG90 servos for about $2 each, and the exact microswitch referenced is about $1 in small quantities from DigiKey.
2. Add an MCP23008 8 bit port expander to my circuit. Using 2 lines, I2C communications, it would handle the 8 total IO pins needed for the pushbuttons and fascia indicators (2 LEDs and 2 pushbuttons per turnout). The freed up 6 lines. Now I have 2 that can be used for feedback. And 4 left over - not enough to implement another servo setup so that each board controls 3 instead of 2. Cheap chip, under $1. Fascia panel IO gets a bit more complicated, possibly slower response to buttons, but likely not really noticeable.
3. Radical version - use an MCP23017 16-bit expander and configure each board to control FOUR servos. Actually would need 2 of them, which would then use a total of 12 pins to run 4 servos with the panels, relays, remote control, remote lock, and status reporting. Now I have 8 free pins. Where does it end? You cna stack up to EIGHT of the MCP23017s on a single I2C bus, though they can;t really drive servos, so the pin limit would be hit with around 8 servos instead of 16, and the board size would start getting awfully big, Plus my whole pojnt was not to have a few boards to centralize control, but rather have smaller ones distributed near the turnouts being controlled. So - forget I mentioned this one, this goes against half my design goals. But this is what happens when doing deep technical thinking at 1:30AM.
I'm leaning toawrds option 1 - because it leaves the rest of my design intact, and also gives near positive indication - the piano wire between the servo might break, or the throwbar of the turnout might break, and the position would be incorrectly indicated, but if the feedback comes from the micro, the servo could be completely unplugged and the position would be reported as changed. Either IS probbaly sufficient for model purposes, no lives are on the line - a truly accurate system would have to measure contact between the point rails and stock rails - a microswitch on the throwbar would change position even if the point rails broke off the throwbar. So if we're trying to be as absolutely sure as possible - but I am not about to go through the gyrations needed to make that work.
Only downside I see with option 1 is that in addition to the 3 wire servo cable going to the servo, another 3 wire cable would need to come back from the servo to the nearest IO node (my yet to be designed psuedo-CMRI node circuit). Can't get away from the danged wires. Option 2, I could incorporate the feedback in the connection between the servo controller and the IO node that's already there for the remote control and remote lock.
There's an option 4 I've sort of dismissed, which would use the microswitch on the servo mount for frog control, and remove the relays on the controller - that frees up 4 IO pins, of which 2 could be the feedback. Reason for rejecting this has to dow ith modifying the turnouts - an unmodified Electrofrog with the frog powered, and it would seem the new Unifrog as well, needs to switch the frog power at a precise time - if the frog polarity is switched to the reverse position while the normal point rail is still in contact witht he stock rail, a short will occur. That's why I have 4 relays in my circuit, one cuts power before movement starts, the other controls the polarity. Once movement stops, the polarity changes, and then power is applied. Now, I have no intention of using umodified Electrofrogs. Which means I don;t REALLY need 2 relays per turnout, I could get away with just 1 - which alone frees up the 2 extra IO pins I need for feedback. But I was trying to make this a bit more of a universal circuit. Convince me otherwise, and I can use this option, and then I am also free to use any servo mounting system I want without regard to being able to fit a microswitch.
Other problem with any version that just adds the feedback at the controller level is highly technical - the design today has 4 signals that go between the IO controller and the servo controlle,r plus a common ground reference. I was using an RJ45 connector, 4 signals and pairing each twisted pair with a ground. If I cnage this to 6 signal lines - pairing signals is probably not a great idea. Or will it really matter?