Given the amount of stuff you have there for the Propeller and the Pi there is no way you are going to be able to check it all out first. It would take ages. Building, compiling, testing everything.
Good luck anyway.
Thank you. There is actually one thing I already know I am short on, that I will have to make do with.
I only have two Propellers to work with. Unfortunately all my money is in cash form, so I can not order any more Propellers, Crystals, or EEPROMs before I drop offline. I have everything else I need on the HW side.
I will be reusing the same Propellers many times over, for many projects. So it will be interesting. I will definitely have to make sure that once I do get back online I have money in a form that can be used to order some more from Parallax.
I have never used the 1pin for a mouse. Not sure if it possible.
Some keyboards are outside the speed specs hence I used a test to determine the speed and then programmed it in, since there is no clock for the data shifting.
There is a circuit on my RamBlade thread for connecting the keyboard and video. See link in my signature.
I have never used the 1pin for a mouse. Not sure if it possible.
Some keyboards are outside the speed specs hence I used a test to determine the speed and then programmed it in, since there is no clock for the data shifting.
There is a circuit on my RamBlade thread for connecting the keyboard and video. See link in my signature.
Best of luck while off-line
Thank you. Looking at the one pin stuff now.
As to mouse, the timing specs are in-line with the keyboard, so it should work. PS/2 mouse just sends a rather simple 3 byte packet when there is a change, hypothetically it should be possible to detect this correctly by sampling at least 4 times faster than the highest possible bit rate, I will have to try.
Of course I am surprised to learn that it is possible for a PS/2 Keyboard to work without the clock line provided.
SD card clock and data in can be shared with the EEPROMs I2C lines SCL and SDA as there is no conflict and I have done it heaps of times although there was a Verbatim brand card that liked to clock the data in line at power-up but SanDIsk always works. PS/2 data rate can be automatically adjusted too by the data pattern as PS/2 is in the 10kHz to 16.7kHz range and essentially asynch serial. I already have all this O/S, FAT32, Ethernet, "scripts" and language tools in Tachyon bar some form of screen editor but that's easy enough. A basic 80x25 video screen needs at least 2k of buffer plus attributes but I either reuse the hub memory from the cog image as buffers or load "ROMS" from upper EEPROM. Good luck trying to get it all working in 32k of hub RAM and 32 I/O!
SD card clock and data in can be shared with the EEPROMs I2C lines SCL and SDA as there is no conflict and I have done it heaps of times although there was a Verbatim brand card that liked to clock the data in line at power-up but SanDIsk always works. PS/2 data rate can be automatically adjusted too by the data pattern as PS/2 is in the 10kHz to 16.7kHz range and essentially asynch serial. I already have all this O/S, FAT32, Ethernet, "scripts" and language tools in Tachyon bar some form of screen editor but that's easy enough. A basic 80x25 video screen needs at least 2k of buffer plus attributes but I either reuse the hub memory from the cog image as buffers or load "ROMS" from upper EEPROM. Good luck trying to get it all working in 32k of hub RAM and 32 I/O!
Thank you, would not have thought about sharing the EEPROM I2C lines, though I guess it is logical. That frees up another two lines. If all works out I should end up with 5 lines extra on most projects, time to play.
SD card clock and data in can be shared with the EEPROMs I2C lines SCL and SDA as there is no conflict and I have done it heaps of times although there was a Verbatim brand card that liked to clock the data in line at power-up but SanDIsk always works. PS/2 data rate can be automatically adjusted too by the data pattern as PS/2 is in the 10kHz to 16.7kHz range and essentially asynch serial. I already have all this O/S, FAT32, Ethernet, "scripts" and language tools in Tachyon bar some form of screen editor but that's easy enough. A basic 80x25 video screen needs at least 2k of buffer plus attributes but I either reuse the hub memory from the cog image as buffers or load "ROMS" from upper EEPROM. Good luck trying to get it all working in 32k of hub RAM and 32 I/O!
As to getting it to work in 32KB, I would go with a 40x12 screen resolution, thus reducing the text display buffer, and then it is a matter of paging the file out to the SD-Card while working on it, requiring a temp file, this would allow for arbitrary sized files. There are some details to get sorted before I would call the idea concrete, though the basics are there.
After power up where the prop may send data to the ps2 keyboard (with clock out from prop), the lines turn around and the keyboard outputs data together with the clock. When using 1pin only the data pin is connected so you don't see the clock to get the timing from the keyboard. The downside is that you have to time the keyboard. I found that some keyboards were not within the timing specification. I solved this in two different ways.
1: I required the user to press a space and timed this to set my timer in the prop. Ie autoboard.
2: Do part 1, getting the timing output. Then feed that into the code as a fixed constant.
Both these work.
As for sharing with SD, how do you ensure that no key is pressed/released while accessing the SD Card?
While I have never tested or researched this, I presume the keyboard is working as open collectors, as there are 10K pull-ups to 5V on both pins.
What you cannot do with the 1pin solution is send data to the keyboard, such as lighting the numlock etc leds. This really isn't a problem. The keyboard sends 2 characters every time a key is pressed and also when released.
After power up where the prop may send data to the ps2 keyboard (with clock out from prop), the lines turn around and the keyboard outputs data together with the clock. When using 1pin only the data pin is connected so you don't see the clock to get the timing from the keyboard. The downside is that you have to time the keyboard. I found that some keyboards were not within the timing specification. I solved this in two different ways.
1: I required the user to press a space and timed this to set my timer in the prop. Ie autoboard.
2: Do part 1, getting the timing output. Then feed that into the code as a fixed constant.
Both these work.
makes good sense to me. Option one seems the most universal.
As for sharing with SD, how do you ensure that no key is pressed/released while accessing the SD Card?
I do not think the SD can be shared with the keyboard. I understood the suggestion as using the EEPROM lines for the SD-Card, and that should work, putting the SD Card on GPIO's 28-31.
While I have never tested or researched this, I presume the keyboard is working as open collectors, as there are 10K pull-ups to 5V on both pins.
What you cannot do with the 1pin solution is send data to the keyboard, such as lighting the numlock etc leds. This really isn't a problem. The keyboard sends 2 characters every time a key is pressed and also when released.
That is not a problem, unless you really need to change the state of the LED's on the keyboard. You still get all the keys.
Comments
I only have two Propellers to work with. Unfortunately all my money is in cash form, so I can not order any more Propellers, Crystals, or EEPROMs before I drop offline. I have everything else I need on the HW side.
I will be reusing the same Propellers many times over, for many projects. So it will be interesting. I will definitely have to make sure that once I do get back online I have money in a form that can be used to order some more from Parallax.
Some keyboards are outside the speed specs hence I used a test to determine the speed and then programmed it in, since there is no clock for the data shifting.
There is a circuit on my RamBlade thread for connecting the keyboard and video. See link in my signature.
Best of luck while off-line
Thank you. Looking at the one pin stuff now.
As to mouse, the timing specs are in-line with the keyboard, so it should work. PS/2 mouse just sends a rather simple 3 byte packet when there is a change, hypothetically it should be possible to detect this correctly by sampling at least 4 times faster than the highest possible bit rate, I will have to try.
Of course I am surprised to learn that it is possible for a PS/2 Keyboard to work without the clock line provided.
Thank you, would not have thought about sharing the EEPROM I2C lines, though I guess it is logical. That frees up another two lines. If all works out I should end up with 5 lines extra on most projects, time to play.
As to getting it to work in 32KB, I would go with a 40x12 screen resolution, thus reducing the text display buffer, and then it is a matter of paging the file out to the SD-Card while working on it, requiring a temp file, this would allow for arbitrary sized files. There are some details to get sorted before I would call the idea concrete, though the basics are there.
1: I required the user to press a space and timed this to set my timer in the prop. Ie autoboard.
2: Do part 1, getting the timing output. Then feed that into the code as a fixed constant.
Both these work.
As for sharing with SD, how do you ensure that no key is pressed/released while accessing the SD Card?
While I have never tested or researched this, I presume the keyboard is working as open collectors, as there are 10K pull-ups to 5V on both pins.
What you cannot do with the 1pin solution is send data to the keyboard, such as lighting the numlock etc leds. This really isn't a problem. The keyboard sends 2 characters every time a key is pressed and also when released.