Using eeprom pins for a keyboard?
Dr_Acula
Posts: 5,484
I am wondering if the two eeprom pins 28 and 29 could be used for a keyboard? On many boards these two pins are not used for anything else once the board has booted. Meanwhile a keyboard uses two other pins. Sharing them would save two pins.
I have been pondering some options. My gut feeling is you can't just share the lines. But maybe you can. The eeprom does not have a disable pin, but if it could be disable after startup maybe the keyboard could share the lines. Or maybe a 4066 could be used to switch between the two - perhaps with an RC network with a time constant of a few seconds and connected to the reset pin, so that it connects the eeprom for two seconds after a reset. Or perhaps a more formal switchover - use a MCP23008 on the I2C bus and send out a message to disable the eeprom somehow.
There must be some other cunning solutions out there.
Any help would be most appreciated!
I have been pondering some options. My gut feeling is you can't just share the lines. But maybe you can. The eeprom does not have a disable pin, but if it could be disable after startup maybe the keyboard could share the lines. Or maybe a 4066 could be used to switch between the two - perhaps with an RC network with a time constant of a few seconds and connected to the reset pin, so that it connects the eeprom for two seconds after a reset. Or perhaps a more formal switchover - use a MCP23008 on the I2C bus and send out a message to disable the eeprom somehow.
There must be some other cunning solutions out there.
Any help would be most appreciated!
Comments
I'm sure there is a better solution than using a 4066 to "A-B" between eeprom and keyboard (or something else?) and controlling this with an MCP23008. This is the best I've been able to come up with so it would be interesting to hear what others have to suggest!
This would allow the eeprom and keyboard to run on the same pins.
I can see this is possible with 1 transistor and a RC latch circuit. No further prop pins would be needed to turn on the transistor.
I'm not really that familiar with the protocol, but if the keyboard outputs both clock and data it could be as simple as a couple of ~10k series resistors. During boot the prop can talk to eeprom without fear of anything the keyboard does over-driving that data exchange. After boot you put P28 and P29 into 'listen' mode to listen for keystrokes
The fly in the ointment may be whether the data stream from the keyboard can corrupt some memory locations of the eeprom. If only a few locations are affected these locations could be deliberately 'defined' as part of the program source. Swapping clock and data lines may help minimize any potential damage. .
Inadvertently clocking in a valid i2c start bit and device id to the eeprom seems highly unlikely to me, but don't want to take the chance. My interest in the pins is for Midi in and out. I've been able to do just one using the data line, but doing both seems risky to me. I'm looking for a simple solution to this problem...
There are several solutions proposed that could work for connecting a keyboard to the eeprom pins.
I will draw a schematic for the 4066/MCP solution using the 6-pin i2c connector on the Touchburger a bit later. I'll probably wire it up shortly after since I've got gen1 of Touchburger mounted in my rack-mount chassis, waiting for power and Midi. Probably overkill for a keyboard, but bare minimum for midi IMO.
Given it might not be just a keyboard, maybe we can expand it to a generic solution that uses these pins for other things? - eg a serial port, mouse port and midi port (midi is essentially a serial port). I wonder about a MCP23008 and a 4052 (dual 1 to 4 multiplexer). If the MCP23008 starts up in a known state (I would expect with pins as inputs) then pullups on those pins would mean the eeprom would always be selected at startup. Prop reset to the MCP23008 reset. I'm moving more to the MCP23008 solution because you don't give up the I2C bus - you can still use it by reconnecting back to the eeprom first.
Dunno much about current I/O expanders like the MCP23008.
Sounds like you have a handle on it.
Being able to reconnect to the EEPROM sounds like a good thing, but
for how long? What happens to the keyboard while the EEPROM is on deck?
How would you KNOW what state it's in without using yet another pin?
But maybe the 4052 could be used along with Bits' RC transistor trick as the (single) address bit??? Tie the other address bit hi/lo as best fits.
That would give you a time period that the EEPROM is passed through and then the keyboard would appear as if my magic. But no going back.
Back to the MCP23008, is there somewhere else in this system that it could be better used to make up pins without involving the EEPROM? (yeah, knowing Dr A I think that translates to a lot of redesign
Here's the scenario: The Touchburger *propeller-based touchscreen platform* uses ALL pins. It's safe to say, while there ARE pins available for use, they will ALMOST ALWAYS be busy doing other stuff. This means we need another way to access propeller pins EXCLUSIVELY... Hence the problem...
Now it's fairly safe to say the ONLY time the eeprom will be used is to "cold-boot" the propeller. A running system could "request" a cold boot, but this will be fairly rare. Now, to "rescue" those pins we need to assume the propeller ONLY needs the eeprom to boot, or to PROGRAM the the eeprom from the PC. This means we need the reset signal from the PropPlug *OR MAX3232* to reset the bus. Programming is easy given the MCP has a /reset in... To me this means as long as the eeprom is the DEFAULT STARTUP device selected, there should be no problems. Power the system on and the eeprom is selected until the program is ALREADY running and REQUESTS access to the bus. Once the system is running, if we need an internal reset, the propeller "requests" the eeprom, then resets. Yes it's an extra step, but shouldn't matter?
Now to answer your questions CAVELAMB:
1: Q: What happens to the keyboard while the EEPROM is on deck?
A: The keyboard data gets "thrown away." Should be okay since the only time the eeprom is used is to load the program into the prop, where it is run internally.
2: Q: How would you KNOW what state it's in without using yet another pin?
A: You WOULDN'T. You must assume that upon cold boot it will be in eeprom mode, and after "initialization" it will live in keyboard mode. *We could have MANY different "modes" but it seems simplest to assume only 2. *
3: Q: ...is there somewhere else in this system that it could be better used to make up pins without involving the EEPROM?
A: NO!!! well, okay MAYBE there's a way to "stuff" it onto other pins, but for the most part we can ASSUME they will almost ALWAYS be busy doing other stuff. This is the problem for me and midi-in. If the propeller is updating the display, then it's possible notes from the midi-in could get lost. *As Doc said, midi is Asyn Serial, so really these signals could be ANYTHING that's time *and mission* critical.
Now here's the "bonus" with the MCP based solution... If you're not expecting the keyboard to be used, and the system is already running, the MCP can be used to detect a specific pin state, or a change in state, based on register settings. I'm not sure about the 4052 yet (still need to comb the datasheet for ideas) but I THINK it will only take one pin on the MCP to control the multiplexer. That leaves 7 pins free for input/output, if not using the keyboard. Chain multiple MCPs for more pins *can't remember the max but I think its 8?* I can think of SEVERAL places this could come in handy. Maybe we could use 2 pins and have eeprom, keyboard, midi, AND something else? I'll check the DS shortly...
The MCP will POR with pins as inputs, so all we need is a couple resistors to properly set the power-on state to eeprom... Seems like some interesting possibilities...
If so, is it safer to go back to an R/C network for startup and either a 4052 or 4066, and no MCP23008? At least with an RC network there is no chance of it misbehaving - it is eeprom for the first 2 seconds only.
I wonder if a cold lager will help me think about this more clearly...
Dunno about the thinking clearly part, but it might make the pounding headache go away for a while..
And this ought to bring it back...
With the RC solution (which I thought was a cool pin-less trick) how do you program the EEPROM?
Just have to write a special keyboard driver.
http://www.mouser.com/Search/Refine.aspx?Keyword=PCF8574&Ns=Pricing%7c0&FS=True
I wonder if you could have a jumper and if the jumper is present it is always connected to the eeprom. Remove the jumper and it changes to the keyboard with an RC constant of maybe 2 seconds.
The downside to that is you might be constantly removing the jumper. But maybe not. For the touchscreen board it has now stabilised with an "operating system" which puts icons on the screen. The operating system is in eeprom, but the list of icons and where they are and which programs they run is stored in an excel .csv file on the sd card. So you edit that file and not the eeprom program to make changes. And as for programs like a synth, or a picture viewer or all the other things, they are binary files on the sd card too.
So in summary, you only reprogram the eeprom infrequently and that means a jumper should be ok. Of course, this is a bit of a special case that only applies to boards with SD cards.
I'm moving more towards a 4052, one resistor, one capacitor and one jumper.
And is sounds workable.
It would only be a 32k EEPROM, just used to cold boot?
Reset switch for a restart? It could dump the charge on the cap too?
Save having to power down to reset.
But as to the special case (only boards with SD cards), with this involved a system
it wouldn't be very useful without an SD card, so don't even consider leaving it out...
You know, as this Thingie(tm) has evolved I've often wondered what the end product is.
Pocket computer? Needs user programming language support. (but I want one!)
Notepad, calender, shopping list, handy dandy appliance?
Cell phone? needs to talk on the phone. But it almost does what cell phones mostly do these days.
Still needs the cheezy camera though.
Picture viewer? Takes a bunch of processing to make pics work in the tiny memory available.
I thing it's coming together as a general purpose solution to many problems - that haven't been named yet.
User writes (or picks?) and application, sticks the card in and that's what the Thingie(tm) does.
But one thing for sure and certain - you have pushed this little chip far, pilgrim. Far indeed.
I've been thinking quite a bit about this and I'm still leaning toward the MCP solution. I THINK the trick is to create a NEW i2c bus with "a group + propPin" for clock, pure propPin for Data. Now there's no worry about ACCIDENTALLY re-enabling the eeprom? Now on to what Cavelamb brought up:
This is a special case: The Touchburger (no trademark, this is a fully open-source project) is assumed to ALWAYS have an SD card. There will also be assumptions of the files necessary to boot. I think the end product we are gearing towards is a catch-all development platform. I need a display to control music specific applications. Others could find a variety of uses for such a powerful piece of hardware. You are right about it being a solution to many problems that have yet to be named. To clarify the specs a bit *I'm WAY off topic now, but the OTHER thread is a bit long and difficult to sift through. I want to start a NEW thread, just trying to pin a few things down first*
Hardware:
P8X32A-D40 40-pin Dip Propeller Chip
1mb "fast address" SRAM with transfers optimized for Ram-to-Display transfers.
2 "standard" 40-pin touchscreen lcd display ports, tested with 2 different display controllers (more coming soon)
32k eeprom for cold boot only,
20+ propeller pins for external interface (when not drawing to the display)
???
Now about applications you mentioned:
1. Pocket computer? Needs user programming language support. (but I want one!)
YES! Doc has a good start on the UPL and most LOW LEVEL functions will be transparent to the user.
Notepad, calender, shopping list, handy dandy appliance?
YES! We have several of the building blocks PRE-MADE, only some simple code would be necessary to write for these apps.
Cell phone? needs to talk on the phone. But it almost does what cell phones mostly do these days.
Not quite. While there MAY be potential for a VOIP device, microwave based cell calls are not in the cards. For many of the OTHER stuff today's cellphones do, like calculator, yes.
Still needs the cheezy camera though.
Great point! I will do some thinking about this one. I keep thinking USB may solve some problems such as this? Maybe as simple as plugging a webcam into a USB expansion board?
Picture viewer? Takes a bunch of processing to make pics work in the tiny memory available.
Yes to the picture viewer, no to the tiny memory problem. I'm glad you mention this since we all know the propeller has some memory shortcomings. By adding the 1mb of SRAM, and using 74hc161's to address the SRAM, we get plenty of memory space for pictures, gui elements, even text buffers or warm-boot flags! Using the 161's improves display time significantly, drawing a full 320x240 image from SRAM in 30ms? *I think this number may have changed a bit, need to check with Doc for the exact number for the CURRENT revision* Loading a BMP from SD to RAM takes a longer but is still fairly quick.
Anyone interested in the Touchburger, I will have kits for sale soon. I have stock on almost ALL the parts right now, except for the touchscreens. Feel free to PM me for more details!
Okay, back on topic. As a general solution to recovering the eeprom pins, I'm stuck on the MCP. For something as simple as a keyboard, I think an RC timed "transfer" would work. Remove power from eeprom, apply power to keyboard. Now I've though about this one a bit. Although it's not "best-practice" to simply remove power from a device, while it's still receiving power from it's inputs, I have used this trick a couple times without frying anything. Seems the "simplest" to me.
Ah yes, that would be completely deterministic. Create a new temporary I2C bus, say prop pins P0 and P1, MCP23008 enabled with (say) group 4 being low, tell the MCP23008 to do the changeover which could be a 4052 (or even power down chips/keyboard as suggested).
No chance of data corruption there.
Hmm - it need not be a MCP23008 - you could use 373 latches or a single latch even. Though I think the MCP23008 has the advantage of resetting to a known state on startup.
I had thought about using the stopping of the I2C signals as the trigger, but I always seemed to get spurious switches on initial power ups but not on subsequent resets. I didn't bother to find out if there were "undocumented activity" in the pins or it was just simplistic thinking on my part.
(Addit:- I did leave 10K pull up on the far side of the 4053 so that the EEPROM and KBD had stable conditions whilst not being used)
Anyway, things like keyboards might be happily sending data when that particular group is not selected. Or do they??
http://www.computer-engineering.org/ps2protocol/ and scroll down about half way to this
This means that any propeller pin can be used to talk to the keyboard. The "group" pins are active low, so use a transistor to invert the signal and pull the clock line low if the group is deselected. I think this can be done with a 74HC4316 to isolate the keyboard and a small signal transistor.
In general terms, the group system can increase the number of propeller pins to any arbitrary number, so long as any device that is inputting data can be told to hold and buffer data if required.
If the clock was held low to force the "buffering" I wonder how much would get stored, remembering that some PS/2 keystrokes are up to 8 bytes worth.
I tried, valiantly, to get Beau to bolt on a B port, but it just got a LOL (most of my suggestions get a LOL ...)
You know I use the keyboard with 1 pin (see my 1pin TV & keyboard software in obex for circuits). The main issue is that you software needs to determine the keyboard's timing - they all vary. You hit a spcae key when required. This timing can be stored if you always use the same keyboard. Since the keyboard now only transmits when a key is pressed/released, you can control the sharing of the SDA pin, and a series resistor(s) for protection.
Jazzed used an ATTiny (85?) to implement an I2C interface to the prop and keyboard & mouse on the other side. This could happily live with the eeprom, and you may gain some alternative features with the attiny. I have a prop program to program the attiny (use 4 pins) - only needs to be done once, so you can share some pins here for that purpose.
BTW If you use the ATTiny, use the 44A or 84A if you are using smt. Cost almost the same as 45/85 and same footprint space, but 14 pins instead of 8 but a little harder to hand solder.
You can have 12 I/O version (DIP20), 16 I/O (DIP24), 20 I/O (DIP28), 24 I/O (DIP32), 28 I/O (DIP36).
Cost is same as a normal prop provided you are prepared to cut the chip yourself. Requires a fine blade hacksaw. If you are not careful, you may crack a chip while sawing
I'll dig out a keyboard (and the PS/2 jack) in the next couple days. The easiest solution to me *IN THEORY* is give the keyboard a couple "group" pins and pull clock low when not selected.
The new "board" is quite nice! It's fast and very flexible. I see plenty of room for "expansion" of groups later if needed.. Needless to say it has a couple "quirks" I need to wrap my head around... But that's another thread...
I'm crossing my fingers for the group pin solution.
The released propeller platform version used atTiny84 and had PS2 or USB-A footprints. The atTiny84 is easier to program and offers 4 ADC or GPIO pins in addition to the 2 PS2 ports. The code is posted for hackers.
If you do, then the fuses cannot be reset with normal programming - I realise you know this but others may not.
Shame there isnt a cheap 20pin version readily available. The 20 pin versions seem to be older relics.
The 88 32 pin TQFP is not bad at $1/100. But its hard to beat a 44A at 0.65c/100 or 84A at 0.71c/100
I will have to pull my finger out and put the code into a m168 as that's the one that I have most of, or even the t861 that is looking lonely.
I will have a go at the addition of the extra pins to the prop, now that the thunder storms have finished and I can get to the shed. What about a couple of lollypop sticks top and bottom with a few nails driven through, and turned over at each end, for stability? :-)
You won't be able to use the crystal (and a lot of other things) if you saw it in half.
I did once playfully apply a wood chisel to one of those olde EPROM packages that was really nothing more than two plates of ceramic, top and bottom and it parted them very neatly. It ended up being shown around by the next door guy to his students. The wiring outlets stayed put so well that I wondered if a QFP -> DIP could be based around it.