Best way to use pins 28..31?
W9GFO
Posts: 4,010
I'm working on something that needs as many pins as possible. I understand that pins 28..31 can be used after boot, and have done so before, but I am wondering if there are some uses to avoid on those pins since the eeprom is connected.
I've been thinking about using pins 28..31 for d0-d3 for a 4 bit LCD. Is there any reason not to? Next up would be to use them for button inputs.
Rich H
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The Servo Boss, a 12 channel servo tester kit from Gadget Gangster.
I've been thinking about using pins 28..31 for d0-d3 for a 4 bit LCD. Is there any reason not to? Next up would be to use them for button inputs.
Rich H
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The Servo Boss, a 12 channel servo tester kit from Gadget Gangster.
Comments
I'd come up with another plan, if I were you.
-Phil
Could a button press on 28 or 29 corrupt the eeprom?
Rich H
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The Servo Boss, a 12 channel servo tester kit from Gadget Gangster.
Yes. (In fact I pull these pins up in all my own designs anyway.)
-Phil
My SCL line even gets connected to a status LED tied to 3.3 or 5V as it is very useful as a general status indicator and also provides status while the Prop is programmed. The SDA line I leave untouched.
Sometimes I turn the programming port into my target application serial port either as USB, TTL, or RS-232, even RS-422 as the port is still available for programming.
However I would avoid compromising your programming and debugging channel on P30,P31. You could use the TX as a TX line or a "non-sensitive" output. If you really really must use these two lines for other things then be prepared to program the eeprom directly which BTW you can do in slave fashion using another Propeller as the "loader" and PC programming interface while holding the target Prop in reset. Do not have any I/O connected that would drive these lines.
Please consider using a little I2C chip or a cheap micro even for extra non-critical I/O such as driving LCDs, LEDs, etc.
*Peter*
P.S. Give us a list of your I/O requirements and I'm sure one of us at least could come up with a viable plan.
you could somehow disconnect it from gnd and then use the pins
safely?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Where am I? Where am I going? Why am I in a handbasket?"
The list is not yet set but here ares some things I'd like to include;
Minimum 4 servo outputs, prefer six or more.
ADC
4 proximity sensors
4 bit LCD
5 way joystick
shift register
2 H bridges
2 encoders
tv out
GPS
compass
SD card
Plus a couple pins set aside for future use.
I guess several of these can be combined - requiring only an additional CS. Haven't done that before.
Rich H
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The Servo Boss, a 12 channel servo tester kit from Gadget Gangster.
On Holly's idea: someone once suggested using a small PIC or other uC in a boot manager role if that's the only purpose of the EEPROM, and shut down the boot function once used so I2C becomes totally inactive ... read-once ignore many [noparse]:)[/noparse].
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
Ended up doing it like the Hydra but I use a little micro to sense when a card is pulled or entered to generate a reset so no need to push the reset button.
I came up with at least 36 I/O required with quite some optimization so you need expansion ports. If you would even consider using a micro to disable the eeprom then why not put it to better use and leave the eeprom alone. A simple and cheap micro such as the PIC16F690 in a 20-pin pack will handle the LCD, JOYSTICK, PROX SENSORS, and other devices and you could connect this to the I2C bus of the Prop. Of course you would need a little software on the PIC but it's all simple I/O and a slave I2C routine which I can help you with.
I have also used Silabs C8051F334s as I2C slaves and have looked at the MC9S08SH and both are also very good peripheral micros. I even have code for in-circuit programming of the Silabs parts using just one dedicated pin from the Prop.
Perhaps with a little more detail on some of the I/O this can be refined further.
*Peter*
Of course there are the many standard I2C port expansion chips to choose from.
Post Edited (Peter Jakacki) : 9/14/2009 12:55:35 AM GMT
a touch screen controller, digital potentiometer and a couple 16 bit I/O Port chips on the I2C
bus and there is no interaction with the EEprom. All of the chips have different I2C addresses.
Best Regards,
Russ
And to those that have replied to Rich's question, thanks for the wonderful comments so far. You folks are great! Although I can only understand about 75% of the response material so far (and don't exactly know what to ask to clarify the other part), this discussion has really begun to shed some light on the matter.
Shifting gears a tad, I wonder if anyone has any opinions on how the Prop II might handle such connections. I realize it's probably a bit late for such a discussion, but I kind of wish we didn't have to worry about 2 or 4 I/O pins of the Prop II being somewhat "hamstrung" in this fashion. Sure, 64 I/O pins is twice as many as 32, but, I'm greedy, and have plans for them. More, more, I say. Enough of this "less-is-more" mentality (okay, just kidding).
I recall that Mike Green mentioned that the boot procedure for the Prop II hadn't yet been publicly detailed, but--if memory serves--he speculated that the Prop II might be able to boot from, for example, an SD/MMC-Card. I think that would make a lot of sense. Among other things, that set-up would allow someone to change their board's programming (for a robot, etc.) in the field just by swapping out the memory card. Moreover, it would allow someone with a production product (such as a consumer-electronics product) to allow purchasers to update or alter programming without requiring connection to a PC, provided the purchaser had a memory card with alternative software (which could either be shipped to them or, yes, downloaded via a PC, lol). In fact, different cards could bring up the same system in different ways (or with different data). From comments made by Chip, it sounds like there might also be a possibility to do some USB magic, as well, so apparently one could program a memory card or an EEPROM in the system that way. But not requiring any PC-connection via using memory cards could be an advantage for consumers of a Prop-based products, or so it seems to this newbie. I think consumer products based on the Prop II will be more of a possibility with the new chip, so the design-philosophy has to change a little bit. There will be more of a tendancy to design production products for other people (although that does exist now to some degree).
Anyway, Chip has stated that a 100-pin package is likely for the Prop II, with 64 of them being for I/O. I believe many if not most (or all) of the remaining 36 pins are committed, many of them for additional power and ground pins (perhaps in association with every 8 I/O pins, but I don't specifically recall, or maybe it wasn't completely detailed). But, and this is just speculative, if a few pins are still available that could be used to directly dedicate to boot-up connectivity, how do you folks think that would fly? For example, do you think it would make the Prop II more or less "orthogonal" in terms of hardware and programming? I think it could be argued either way. I guess for this to even be a possibility, there'd have to be additional instructions added to the instruction set (shoved in somehow, probably like is being done for the new instructions for the Prop II) and/or some additional circuitry in the chip that perhaps wouldn't be replicated 8X like most other things (go easy on me here, I'm still a newbie). Hey, we don't need 8 crystals, thank goodness!
However, maybe some Prop-heads would object (at being called "Prop-heads) that this design would kind of violate the Propeller's overall design philosophy and would make it more like run-of-the-mill or standard MCUs that have a lot of dedicated hardware built in (SD/MMC, USB, I2C, LCD controllers and so on). But I'm not talking about lots of other connectivity, just the essential boot-up stuff (and maybe something like I2C or dedicated USB (which might overlap with boot-up circuitry)). However, I'm not sure how, for example, USB licensing obligations would affect/impact any folks making Prop II products for sale. But for memory cards, if I understand correctly, we can avoid SD licensing by sticking to MMC interfacing/programming. I think Chip understandably has an aversion to handcuffing us with IP licensing requirements, at least as much is as possible. Anyway, back to my original tangent (which is hopefully somewhat related to this thread), not having to worry about some I/O pins being "special" could be nice from both programming and hardware standpoints. Just curious about what others think.
No doubt, Parallax has all of this under control, with good design decisions being made that are consistent with their philosophy and expected market. But, as mentioned above, the range of applications possible under the Prop II is going to expand, and the derived products will be somewhat different and more varied. Users often amaze the creators of products with what they end up doing with them, going way beyond expectations. For example, the creators of what now is Adobe Flash had no idea how creative users would be with it and to what level they would take it. In the same way, even Parallax can't fully know what kind of applications will become possible with the new chip (or even with the current one), though they certainly have at least a general idea. As such, any decisions made with respect to a particular design philosophy must also bear that in mind, and try to be as "open" as possible, so as to not unnecessarilly restrict possibilities. For example, there's probably a greater percentage of non-robotic designs for the current Prop than there are robotic ones, although the latter might be among the largest if not the largest as a specific category. Of course, Robotic accessories (sensors and what not) are a big part of Parallax's strategy and passion, but I think they must realize that the next chip will take them into new areas.
Anyway, as mentioned by a Parallax representative recently, it sounds like we're due for an update on the final (or near-final) functionality about mid-November.
Post Edited (JRetSapDoog) : 9/14/2009 2:19:52 AM GMT
Now, Peter has suggested some possibilities, which we have partially discussed on other threads. There are expander ICs that could be used on pins 28/29 without problems and this is probably the best/easiest way to go. The only issues with another micro is that you have another programming language to use, and another programming method to use.
Hope this helps
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I don't have that particular chip but I have several other PICs (like the PIC16F676) along with the PICKit 1 starter kit and the ICD2 kit. Never used any of them. I had been debating passing it along to someone that might make use of it but kept thinking that I might one day need it. Looks like that day is here.
I like that idea. I appreciate the help.
Rich H
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The Servo Boss, a 12 channel servo tester kit from Gadget Gangster.
However it seems logical that whichever chip you use that you communicate to it via the I2C lines but not necessarily I2C protocol. For the bit-banged chips it makes more sense to use an asynch single wire protocol that would use the SDA line and basically send a wake-up character ($00) so that the PIC would then break-off as soon as it could from other operations and receive a command packet, maybe only 2 or 3 characters. You can use the interrupt here or just sit and poll the serial line as lcds, leds, and switches do not need constant attention. If the EEPROM is being accessed then you will see garbage so a simple sequence and character validity check is all that is needed to co-exist on the I2C.
You don't have to stop at one chip either as the SSOP20 is a very small package and sometimes it becomes practical to place them where they are needed so as to simplify the pcb routing. For software development I use PIKLAB on Ubuntu rather than the cumbersome MPLAB.
*Peter*
I am sure no one has ever tested this (nor me), but here is the idea·
- During boot the prop is using the RCfast internal oscillator so the XO shouldn't be driven
- Wire a set/reset flip-flop to the prop: set to XO, reset to reset line
- Once the prop has booted and the user's program start the crystal oscillator the XO togles the flip-flop. An external reset will bring it into default position.
- Use the Q and /Q flip-flop's outputs to /WP the eeprom, power a GPS (or gate its tx line) on P30..31 ...
- If the user's prog starts in RCfast mode can do anything with a boot-up-hardware configuration, then enable the oscillator and do the rest with the post-boot-hardware
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates)
See the attached image. It is a figure that is in the book called Robot Programmers Bonanza.
It describes how to use the Parallel port on the PC to create 4x8 Input ports and 4x8 Output ports
The parallel port has 8 I/O lines and 4 control lines.
So with 12 lines you can create 32 Input and 32 Output lines.
The concept is called multiplexing and Buffering (with High Z).
The image is a schematic that shows one input and one output but the extension to 4 and 4
is the just the same just repeat the connections as shown for the one 74273 3 more times and
likewise for the 74244 and connect their activators to the Yn lines from the 74138.
Also instead of 8 I/O and 4 control lines you can use less and also if you just want to
multiplex output or just input you can adapt the schematic.
But the idea is that you share I/O pins among multiple devices and you address which ones
are targeted at the time you output/latch the data.
Regards
Samuel
Post Edited (SamMishal) : 9/14/2009 8:12:55 AM GMT
This is fairly standard fare for the 70's and 80's as many of these chips were designed for traditional data buses. But they all require a lot of lines to drive them, in this case 12 lines. So what ends up happening is that you lose a lot of special functionality (counters etc) for little gain. The approach these days is to use serial devices that only require a few lines (2 lines in the case of I2C) that allows scores of ports to be added without any extra penalty. Especially is this the case when a cheap micro is used as a serial expansion port, in fact the micros usually work out cheaper than the dedicated chips. In the case that a micro is used the local peripheral software can handle additional functions such as A/D and encoding etc independently of the host cpu.
Think of it like this, a mouse encods X and Y and button presses, and all the computer has to do is read the processed data at it's leisure. Now imagine if computer mice had great big ribbon cables instead connected to the computer and the PC struggled to keep up with it in real-time, it would be the absolute pits. Serial with smart peripherals makes sense and the peripheral software can very clearly be defined and once set can be "forgotten".
Given the price of the Prop chip there is nothing really stopping it being used as a smart peripheral either, and it is something that I have done with the Prop in the past. There was this high-speed 12-channel tablet counter that I designed a while ago that used one main Prop and three others as smart peripherals.
*Peter*
Bob
and that brings you back to the 21st century (well late 20th)....but if you do not know about how the
original LOGIC worked you would not be able to do neither the VHDL nor LOGIC for the FPGA.
Using a microcontroller is a good solution .....BUT....why is everyone suggesting a PIC or other
WHY NOT use the Propeller....another propeller would be a better solution.
However.....I think that using 12 pins to get 32+32 is not such a bad thing.....especially if you use
an FPGA to do it since it would be one chip instead of 9.
I just thought since others were giving all sorts of options....this is yet one more that
may have been forgotten by the "yunguns"....
Regards
Samuel
P.S. I see from the posting above that there are still olduns around....
This is a GREAT observation for those who don't want I2C after boot ... as long as external mode is being used for the rest of the program. I've seen it hundreds of times on a scope, but it never struck me this way [noparse]:)[/noparse] A FET switch could be used to route the signals appropriately.
If you want the I2C of course by all means use it. If you don't want it there are ways out of it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
pins from the 4 bit parallel one?
Again sorry if I missed something above!
Ken
····focus.ti.com/docs/prod/folders/print/pcf8574a.html
-Phil
Bob, have you used decoder chips before? These outputs aren't latched and you only get a 1 of 8, not 8 of 8 outputs meaning that only 1 output can be active at a time which is useless for I/O port work. If you had 8 leds and only ever wanted one lit then the old decoder chip will work fine but that scenario is very unlikely. Typically these chips were used to select multiple chips hung off the data bus with only one chip ever selected at a time. You might be able to provide 7 chip selects from 3 inputs (one state for inactive or else you need an extra input) but again that's unlikely too. It's very rare that you would use any of these old chips in modern circuits and although it is "possible" to use them so it is also possible to use a vacuum tube or bring back relay logic I say, but it's just not logical.
Now this morning (my time)
Serial lcds are fine as there are various methods. I have done them with PCF8574s in the distant past, with micros past and present, with shift registers, etc. If you are requiring other I/O as well it seems logical to combine the effort into one solution though.
@dMajo - great idea, I wish I thought of it [noparse]:)[/noparse] I think that the smallest flip-flop you can get is in a 14 or 16 pin pack so you don't actually save much room. The dedicated slave micro approach still allows you to disable the eeprom anyway, just assert the write protect line. Personally though I use the eeprom to backup variables that are used as constant by the application.
*Peter*
You are right... Awhile back, I used·these decoders just to blink leds and operate one thing at a time.· I also used them to toggle flip flops as well (kind of a latch).· Of course, this was probably more complicated than what is was worth.· If you want to run more than one thing at a time, these "old" ic's are NOT what you need.· I know that you can get versions that "latch" the input, but once again, that is useless when you want to do more than one thing at a time.· Anyway, thanks for setting me straight.· Have a good one.
Bob