Accelerometer | ADC | ADXL | Adxl20 | AVR | BasicStamp | BX-35 | BX28 | BX35 | COM3 | Compiler | Downloader | EEPROM | Electromagnet | GetADC | GP2D1 | GPS | I2C | IDE | Keypad | LCD | LCD+ | MIDI | Motors | Multitasking | Netmedia | Networking | PCB | PID | PlaySound | PWM | Relays | RTC | Servo | ShiftOut | SitePlayer | SPI | Stack | Timer | USB

Does anyone have source code for getting input from a PS/2 keyboard to a
BasicX?

Thanks!
[Non-text portions of this message have been removed]

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

You need to use an adapter to do this.

Try www.al-william.com for one that changes PS/2 keystrokes to RS-232.

This is just not doable in Basic. You need to program as the assembly
level and even then, you need to convert your 'keycodes' to ASCII. It
takes up a lot of space and processor time. So, it is better to just
plug in the device.

--- In b...@yahoogroups.com, andycamach@... wrote:
>
> Does anyone have source code for getting input from a PS/2 keyboard
to a
> BasicX?
>
> Thanks!
> [Non-text portions of this message have been removed]
>

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> ... This is just not doable in Basic.

I have not tried, but why not? Speed? Translation table size?

For ideas, Google "ps/2 keyboard data".
Tom



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

How about this:

http://www.k1el.com/

look at the ATKBD, a $6.00 8 pin Dip that does what you want. Check it out

Vic
________________________________________________________

Victor Fraenckel - The Windman
victorf ATSIGN windreader DOT com
KC2GUI

[Non-text portions of this message have been removed]



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> ... getting input from a PS/2 keyboard to a BasicX...

How about this:

The PS/2 keyboard data byte is 11 bits long, and the clock line is
pulsed low for each. The first bit (the start bit) can be discarded;
the following eight bits can be read with ShiftIn, and the remaining
two bits can be wasted. All that is necessary is a single D-flop to
discard the start bit.

I propose this circuit, though I've not built it:
http://groups.yahoo.com/group/basicx/files/Datasheets-Appnotes-Examples-Drawings/
PS2Keyboard.jpg.
Tom



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> ... This is just not doable in Basic.
***
Guys....Its do-able in BasicX.

Only issue I had with prototyping mine it was the 300-500ma requirement of the keyboard power DIN.
Power the K/B DIN from its own power source due to the ma requirements.

The baud rate is a non-standard rate but by using COM3 for the I/O, one can over come that since COM3 on the BX chips can be softcoded to any value.

All you have to do is map the returning Scan Code Values to ASCII characters.
I used two arrays....look up the scan code in array one, return back the same index value from array two.

The object code can be quite large for the processor.
Were talking 101+ keys, plus the LeftShifts of them, the RightShifts of them, both shifts of them, the ALTs, the CTLs, the Function Key and more.

I scrapped the whole idea because of the large code segments and the fact that there are already dedicated chips out there that do the same thing.

But its very do-able, If one were to dedicate an entire BX to be just doing the mapping.

.db.

[Non-text portions of this message have been removed]

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> ... The baud rate is a non-standard rate but by using COM3 for the I/O, one can over come that since COM3 on the BX chips can be softcoded to any value...

How did you do that, Dan? Nowhere is a datarate for PS/2 keyboard data
specified. Instead, the clock setup and hold times, and high and low
ranges are specified - and generously; a PS/2 keyboard clock can be
anywhere between 60 and 100uS wide.
http://www.computer-engineering.org/ps2protocol/

That corresponds to a serial rate of 10000 to 16667 baud, a too-wide
range for a single speed COM3, I think. Did your implementation tune
itself to the keyboard?
Tom



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

This is sychronous, not async. The keyboard is the MASTER and provides
the clock while the BX-24 would have to be the slave.

You need to be bi-directional to intialize the keyboard. Input to the
keyboard is 12bits wide [has an acknoledge bit], output from the
keyboard is 11bits wide.

The $6 chip from K1EL is quite reasonable, or Al Williams has a
complete kit. Al Williams' product will accept a mouse too.
>
> > ... The baud rate is a non-standard rate but by using COM3 for the
I/O, one can over come that since COM3 on the BX chips can be softcoded
to any value...



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Can you explain how you handled the asymetrical synchronous serial in
BasicX. Output from keyboard is 11bits and input is 12bits. Seems you
have to be able to program a software serial port at a bit-bang level.

--- In b...@yahoogroups.com, Dan.Bielecki@... wrote:
>
> > ... This is just not doable in Basic.
> ***
> Guys....Its do-able in BasicX.
>

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Tom posted:
> ... The baud rate is a non-standard rate but by using COM3 for the I/O, one can over come that since COM3 on the BX chips can be softcoded to any value...

How did you do that, Dan? Nowhere is a datarate for PS/2 keyboard data
specified. Instead, the clock setup and hold times, and high and low
ranges are specified - and generously; a PS/2 keyboard clock can be
anywhere between 60 and 100uS wide.
http://www.computer-engineering.org/ps2protocol/

That corresponds to a serial rate of 10000 to 16667 baud, a too-wide
range for a single speed COM3, I think. Did your implementation tune
itself to the keyboard?

*************

Tom -

I posted that at the office.
I had to go home to my development box to review that archive of BX logic I did.... its been a few years since I did the keyboard prototyping for my BX MCUs. I use a custom PC-to-bxCom1 interface for that now since Keyboards, directly connected just didnt seem to cut it. Heres the details:

***
Because of the non-standard timing of baud rate, I used a softcoded value stored in eeprom (external on a StampMem device). Im looking thru my logic, design notes and comments......

I had to play around with the baud to determine which one would work best (hence the softcoded value from eeprom so it could be changed and fetched on the fly). I have a few different keyboards laying around my loft and my notes indicate that of them all, the one that worked best with the BX was a clone-brand, a Mitsumi 101/102, model "U". The baud rate it liked best was plain-ol, 19200 baud. It was the rate that was prone to the least amount of errors for that keyboard --- which is also my *prefered* baud for all my BX communication needs.

Another one (second most stable) was a slow 396 baud (a PC/XT keyboard) for a reliable scancode return. I used just simple alpha/num-key tests and 7-of-10 returns of the keypress in order to be a "reliable" scan. That meant no normal keying. One had to press and hold the keys and buffer them in order to be a "sync-able" communication link using a Com3/Queues technique.

Im looking at my archived logic now on the Archive box.....and I the first thing to do after establishing the Com3 I/O and opening -- it is to place the Clock Pin bxOutputLow, then bxOutputHigh and then a Delay 0.50 .....to inform the KB MCUs to enable buffering mode. My design notes on that indicate the KB buffers should be used, with a footnote that the clocking was more stable with the buffers enabled, then without. Different KBs used different controllers/buffer chips (I opened and examined) so no set "rule" worked. Each KB had is own nuance and buffering overcame a lot of them. The 0.50 delay was the adverage of all the different chips used, and all of them responded (forgiving controllers) to the 0.50 in order to enable buffering.

This, by-the-way is the default of keyboards and you will see it enable at PC boot-time, just after a PC reset. The KB come online, syscheck themselves, flash the LEDs and then enable the buffers. The PC is actually instructing the keyboard to do all that and then post back an ACK-ClockPinHigh for a timed duration before the Keyboard is allowed to pass a PC POST. If it doesnt, the PC will beep with Keyboard error POST code.

Okay, back in BX logic again:
After the buffer-enable, I then entered a DoLoop and waited for the keystrokes with a StatusQueue on the RX pin. Once that triggered I did a GetQueue on the an inbound byte as a RawByte. Then, due to MSB/LSB, a Flipbits on the RawByte variable. The result is a scan code value which was used for the lookup index in the arrays, to return back the ASCII array index. (but thats not the typed character, just yet) Depending on the keystroke, there can be at least 2-to-3 scancodes returns for simple presses. Keypads return more, the pad codes and the values pressed....special chars even more. Most are documented as "standard" scancodes.

Because the KBs can output more then one ScanCode, depending on what keys are pressed, the loop recures, always waiting for StatusQueue to trigger. My design notes at the time on that, state that was because a User could press a key anytime, so any BX logic would have to be wrapped within that keyboard loop. Thats why I tossed out the notion of using a keyboard directly attached to the pins. I didnt want to be limited to always designing within that loop, never knowing exactly how many bytes would be returning.

I have a speical note as a Con (Pros & Cons) that pressing and holding L-Shift + R-Shift + L-CTL + R-CTL + L-ALT + R-ALT + NumLock...and then some Function Key or keystroke returned so many bytes (60+) that there was overrun and the trailing bytes were lost. This could have been K/B buffer or Com3 buffer overrun but since it wasnt stable to use other then some simple and single entries of A-Z, 0-9 keys, it wasnt what I was looking for at the time (7/19/2002 is my dates on that prototype BX logic). These are just normal keys that can be pressed (not the WINDOWS key or even the multimedia keys, Vol up/Dn, Next track...ect) A User could easily hang up a BX with queued data just by messing around with keys and dumping mass amounts of scancodes into the queues.

It does work in BasicX and Scan Codes can be fetched from the keyboards -- but depending on the maker, the model, the chips used for the KB guts .... its really not worth the time and effort (IMO) in developing a BX to work consistently with every type of K/B out there since there are so many other ways to implement a keyboard to a uMCU. Each KB was special in its own way, required tweaking of softcoded baud rate and timing values (ie configuration setup) just to get a readable scancode for basic keys. Some just flaked out totally on pad or function keys or extended scan codes.

I used 6 different K/Bs in my protype logic and testing, 2 were PC/XT class, 2 were AT class and 2 were PS2 class. (I like 3 sets of 3s for tests, but I only had 6 total laying around) My notes indicate the AT class were the most stable and the most reliable for the standard ScanCodes tables and the closest to a "normal" baudrate. I also have a footnote that the PS2 class required special reconfiguring of COM3 to be 9-databits by RAMpoke-ing a (CuInt(21)) with bit 2 as On, in order to begin seeing valid ScanCode values. This was so that the bxQueue processing naturally stripped off a CRC bit that some PCs require to be present. Something not implemented in the PC/XT/AT outputs at the time. It was done for PS2 KBs since the trend was moving to Special Keys, above and beyond the 101/102 specs. Keys like Internet, Help, User programmables, volume up/dn.....stuff like that. CRCs were implemented in order to ensure the data stream generated would be correct since a lot mor
e bits were flowing then before and is just another reason the DINs were physically changed since they are not backwards compatable to the XT/AT class.

But in all of my test KBs used, none were really stable in buffering/returning simple and normal typing of keystrokes at my normal typeing pace, 40+ WPM. Since the MCU is responsible for the clocking, Interupts, fetching....ect. A dedicated BX maybe, with ONLY the inbound scan working....but the MCU-to-KB-Control is even harder, in order to "control" a keyboard and so much code is needed to manage just a keyboard.

For Control...there were talking 11-bit instructions and hi/lows/timed-delays on the clock line just to tell the K/Bs what to do. I have some design notes on that also that indicated that ShiftIn/ShiftOut of the bits worked better then the TX/RX Queues and all I was looking to do for my tests was to alternate the 3 LEDs above the keypad to indicate the MCU was "waiting" for a keystroke, by moving the LEDs back and forth for a visual User signal to enter now. I was watching a KnightRider rerun and that gave me the idea of alternating those LEDs. KITT did that alot as he waited for humans....

It all ends up being just to much bxLogic just to manage a keyboard, convert ScanCode to ASCII values and string the values together for keystroke interpertation that theres not much room left for what your trying to do with your BX to begin with. Thats why I scrapped the idea and archived it for anything other then a dedicated BX that does the keystroke functions and then outputs via COM1: to another MCU. Theres so many ways out there already that do that for a lot cheaper then a BX costs. Vic's post of that 6 dollar PIC chip for example. $6 vs $49.

Yeah. I know what I would buy....a bunch of the $6ers for a total of $49.
(Where were ya Vic with that post when I was looking for a solution back in 2002 ???)
***
If one does with to attempt this, by all means go get Design Manuals on the subject of Keyboards. Thats what I used in addition to a lot of internet informaton on keyboards. Web info still didnt answer all my design needs and I had to gain access to hardware design manuals (IBM) as to some of the timing and interworkings of the keyboards. There is tons of Web info out here on tons of subjects, but manuals are always the best source of information for a subject matter, like keyboards or other forms of hardware.

They will go into indepth detail as to WHY something has or was done a special way. Even to this very day, most Keyboards are very smart and contain on-board processors all of their own, but in the end, they still drop back to the simple tasks of wait for the MCU to select, clock, sync, send. The onboards dont change all that and theres a reason for it. The PC is cycling its interupts, its the Master, the keyboards are the Slaves. They just cycle faster then we humans can type so it all seems like interactive magic to us.

"Keyboarding" can be done with a BX, its just not practical (or cost-worthy) to do so.

Vic? Your little $6 post got me thinking on my drive home:
A PC keyboard, to that chip, to a UART-BlueTooth, to the air......from the air....to a BlueTooth-UART, to Com3 and into the BX. Would be good for 100 to 1000 feet depending on the Tooth device....no cables....and FCC pre-approved. Hummmmm.

.db.

[Non-text portions of this message have been removed]



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> ... If one does with to attempt this, by all means go get Design Manuals on the subject...

There's advice you could have used. Wouldn't it have been wiser to use
the keyboard clock line? As G. says, it's a synchronous interface.

And spinning waiting for input? ShiftIn will block its task (but allow
others) until it gets it's eight bits, so why not use a task to get a
keyboard data byte, load a queue and be done with it? I suspect another
task can do the translation with a table in EEPROM.

> ... I had to gain access to hardware design manuals (IBM) as to some
of the timing and interworkings of the keyboards...

Mystery data. Share a link? Still, what's that have to do with a
roll-up membrane keyboard of recent manufacture (the OP's need)?

Dan, it sounds like you spent alot of time building an interface that
ignores the interface specs and doesn't work except poorly with any but
a selected device or two. That's no solution.

> ... I have some design notes on that also that indicated that
ShiftIn/ShiftOut of the bits worked better...
> ... That's why I scrapped the idea...

I should have read ahead.
Tom

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Tom -

Clock line is only really needed if one wants to Control the keyboard. Other then toggling it and that 0.50 wait, for buffer mode, one doesnt need it to read scancodes. An I will clearify something on that that I didnt state up front. In receive-only mode, the clockpin was strapped to a BX pin and pulsed in a task with a softcoded delay (after the buffer instruction, at powerup.)..so I could change the hi/lo pulses on-the-fly. But thats all it has to do really, Hi/Lo/Hi/lo and time the pulses, so that marks can be seen by the KB and changed until viable data would result.
***
Im referring to Physical Manuals ....not web links. I use and Favorate a lot of the very same design and development links you reference at times since we both need just about the same technical info. The web is not all-knowing.

When new PC hardware comes out, most are actually designed on the original PC design specs and wither expand upon it or emulate it. Your membrane keyboard example would still have to conform to the PC-spec, that came from IBM/Intel/Microsoft originally in order to be compatable. I use the web and manufactures datasheets also, but they do not define the specs. Only the limitations of the device described.
***
...and It is do-able and buildable...only took a week or so of my time back then to gather the info needed and write the prototype logic. It just isnt worth extensive effort and development to pursue a BX as an extensive Keyboard Controller and attempt to market it. Not when there are so many other alternatives for much less. We talking $45 per BX (roughly, give or take volume discounts) and then development time (programmer's costs)...and maybe some profit overhead....just to compete in a market of KB Controllers where one can buy handfulls at what a BX version would have to retail for.

The Return On Investment (ROI) figures just arn't there to pursue and is one reason I scrapped the development project, that and the size of code needed. Its is my favorate uMCU and is my personal choice for uMCU development but I recommend using an external dedicated chip or a custom peice of logic (what I use) that takes PC input and sends them to the BX via Com1.

.db.

[Non-text portions of this message have been removed]



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> ... Clock line is only really needed if one wants to Control the
keyboard. Other then toggling it and that 0.50 wait, for buffer mode,
one doesnt need it to read scancodes.

What? In your previous dissertation, you said:
"Each KB was special in its own way, requir[ing] tweaking of
softcoded baud rate and timing values (ie configuration setup) just to
get a readable scancode for basic keys. Some just flaked out totally
on pad or function keys or extended scan codes."

Dan, you show odd tolerances; perhaps you have inadvertantly
channelled some parallel universe. Reasonable people know that, in
this one, that is not a functioning system.

Give it up; you need the clock, man.
Tom



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Oh Com'on Now... this is not some super-high-level peice of hardware.
Its a keyboard. Thats an input device.

All the clock has to do is toggle on and off for keyboard reads. Which the Hi/Lo's did in the logic task.
If one wants to *control* a keyboard....write to it...then more advanced program-control of the clock is needed. For the most part, an MCU will be reading, not writing to the device. Its an input, remember?
***
Theres always that under-the-covers-tone to post code examples to prove things as stated....sorry I dont "do" Open Source Logic. This is my living, developing logic. Dont beleive me with Bx's and keyboards? Go do it yourself. This is a *discussion forum* after all, is it not? Someone stated its not feasable. I say it is, just not feasable to do so. Thats discussion.

I dont need to post code to be in a discussion or rely on information of others based on a weblink. I do my own researching as required. The web is not all-knowing. It is only a reference tool, but not the only reference tool one should use. There are many tools in a toolbox, not just one --- so the web should never be used as the single source of information on any matter. Use other tools available (manuals, reference guides, design specifications, etc) and then develop prototype logic against your theories to prove them. That means write some code.

Code-wise this is not a hard thing to do....to fetch the scancode ....Just pulse a pin. bxHi, delay, bxLow, delay......It will be your "clock". Put it in a task by itself but with delays based on a variable so you can manipulate the delay factor. Now you have a softcoded clock.

Now hook up a KB's TX pin to a BX pin as a Com3 with another softcoded baud variable and queue the input. Press a keyboard key. Tweak the baudrate and the delay factors of the clock until you get readable scan codes. One must know the scancodes for the keystroke to begin with in order to determine if the value is true or not. This is very basic communications debug techniques when a baud rate is an unknown.

Garbage is returned until the devices sync up properly and a proper scancode-set is returned for the key pressed.........now examine your variables, theres your baud and clock factors for that keyboard. Tweak the variables around, up and down until the two devices marry-up to what you would consider to be stable communications.

Clocking is nothing more then hi/lows on a pin, within timed durrations, nothing more. Use a PulseOut if you want to be fancier. But a clock is a clock.....want the chip clock? Strap directly to the bxClockPin.... and now you clock anything at the same rate as the MCU. Want to step that MCU clock down? Attached a divide-by-chip between the two and step down to any factor desired. There are always ways to overcome issues, be they hardware solutions or software solutions. I chose the solution for the job at hand since I do both H/W & S/W in the course of my career.

Questioning of my posts in this forum has always been there.... I purchased my first BX shortly after they were first released and joined the fourm then. Im only stating what I know is a bxFact:

A keyboard outputs its data on the Din-TX pin. That data can be read in by a BX and the results tabled-accrossed and the ASCII value obtained to determine what key a User pressed, if one knows all about how to go about and do it. ......been there.....done that.

It just isnt logic-feasable or cost effective to use a BX as a keyboard controller since to much code segment is required, but It Can Be Done for those that understand the hardware devices involved and knows how to program them. I have always posted I work on all types of CPUs......but I play with bxChips. I just love the little things! What I do with them at times you wouldnt beleive me (and dont) if posted, only if I posted the logic that does it....and that just aint gonna happen.

.db.

[Non-text portions of this message have been removed]



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> ... bxHi, delay, bxLow, delay ... It will be your "clock". Put it
in a task by itself but with delays based on a variable so you can
manipulate the delay factor. Now you have a softcoded clock.

If you are now suggesting that the BX-24 provides the clock when reading
the keyboard (which a moment ago you said was not required except to
control the keyboard), you've just debugged your method; that's wrong -
and I think not possible with the BX-24. The PS/2 keyboard supplies the
clock when the BX-24 is reading its data. You cannot control the rate
of data from the keyboard. Your recollection of The Great Readings of
The Manuals is flawed.

You tried to drive the keyboard clock while reading the data with COM3?
By bit-banging the clock, you say. The spec requires a 30 to 60 uS
low or high period maximum. The fastest a BX-24 can toggle a pin in a
loop is about 200uS, if the machine is doing nothing else. The result
can only be chaos on the clock pin, driven both by the keyboard and your
code; _any_ valid data is unlikely. Nonsense, Dan. I doubt that you
actually did this.

Drop it.
Tom



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Drop it?
It can not be done because someone just says it can not be done?
No more discussion on it because a message is posted that just says so and all who use a BX must follow the command? Sorry, Im just not that stupid so as to follow those preachings...

Controlling a PC Keyboard can be done with a BX.
I posted that statement and did so since it can be done.
I have done it in logic.

Not because I sat around thinking about it and doing math about it .
Because I hooked up the hardware, sat, and then wrote & tweaked code to do it.

I do not approch things from the same design direction or in the same manor as others on this forum so therefore, all I may post or program is not acceptable to the bxUsers unless its approved by someone else on the forum? Com'on! Thats just stupid. Some just can not, or do not even attempt to try, so therefore 'in Theory' it can not possibly work. It does.

The BX line of chips is a very diverse platform for development, no matter what the project may be. It may not be the most feasable or cost effective platform for a partictular project, and a Developer may not be able to implement the project on the platform, but in no way does that rule out the fact that it can not be done on the platform. One just has to do it, not talk about how it can not be done.

Always remember this:
NASA-Slideruler-Types were not the winners of the X-Prize.
It couldnt be done by them because the slideruler-math said it could not be so.
--- but boy do they drool over that StarShip One design.

At some point, some Slideruler one day will also be telling me that a triangle can not hover in mid air.
Yeah? I have some BXs and designs that state otherwise....

CMD: Voice On.
ACK: Ready for voice command.
"Power up Primary Drive."
"Power up Secondary Drive"
"Power up AIU Drives"
"Hover to 6 feet; then Look that human in the eyes."

Like I said before....keyboards and a BX?
Been there...done that. Do Able. Just not feasible (IMO).
Not when there are so many alternatives to that klunky way of life.

.db.

[Non-text portions of this message have been removed]



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

I thing the keyword is 'KEY'.
When IBM created this keyboard format it seems that their point of
view is that removing the keyboard is a first line of security. So
they did not use a simple ASCII keyboard interface like others.

It does have its own microprocessor which is in a unique format. An
you get a bunch of key codes that eventually have to be converted in
to ASCII and non ASCII data.

I would say they took it to as high a level as they could - to keep
it proprietory.

If you want a $25 chip with software that will do the PS/2 keyboard,
a PS/ mouse, a computer Video monitor, and lots of room left over,
there is a new 32 bit chip with 8 microprocessors in parallel that
will be out soon. Think 160mips and 32 I/O pins

But, do I dare say who?

--- In b...@yahoogroups.com, Dan.Bielecki@... wrote:
>
> Oh Com'on Now... this is not some super-high-level peice of
hardware.
> Its a keyboard. Thats an input device.
>

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Post your completed code in the Files section and I will download it
and attempt to reduplicate your sucess.

After doing that, I will eat humble pie and give great praise to your
excellence.

--- In b...@yahoogroups.com, Dan.Bielecki@... wrote:
>
> Drop it?
> It can not be done because someone just says it can not be done?
> No more discussion on it because a message is posted that just says
so and all who use a BX must follow the command? Sorry, Im just not
that stupid so as to follow those preachings...

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

D...@ATT.net wrote:
> It can not be done because someone just says it can not be done?

It cannot be done the way you claim you did it. When challenged, you
fantasize and pontificate. The available documentation about the PS/2
keyboard interface protocol (even lacking the Lost Ancient Manuals of
The I.B.M.) show that you cannot have done what you claim you did. It
_can't_ work, Dan.

This is a technical group with a specific focus; it is not a discussion
group where one can say whatever one likes. One cannot invent a new
reality here. If one has practical experience and advise, he is welcome
and invited to share it. If all one can do is boast about fantasy
projects and ignore reality, one is not welcome.

Dan, this is the end of this thread. If you can demonstrate a working
keyboard interface using your method, let us know.
Tom



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Tom is correct.
This is an 'open collector set up' where the BX24 or whatever is
receiving the serial data can only STOP the clock by pulling it low.
It is the slave, not the Master.

You have to fully comprehend SPI and I2C serial to see what is
happening.

This past winter, I spent a great deal of time trying to learn Assember
for PICs and SX-Ubicoms with the PS/2 keyboard i/o adapter as my study
model.

To clarify the discussion, ASSEMBLY code is required for this kind of
interface and if BasicX chooses not to write a Command to support it,
you will have to spend quite of bit of time to insert one into their
IDE.

The K1EL chip is a blessing. For $6 you can move on. I doubt if
anyone ever achieved this with existing BasicX code.

Respectfully,
G. Herzog

--- In b...@yahoogroups.com, Tom Becker wrote:
>
> > ... bxHi, delay, bxLow, delay ... It will be your "clock". Put
it
> in a task by itself but with delays based on a variable so you can
> manipulate the delay factor. Now you have a softcoded clock.
>
> If you are now suggesting that the BX-24 provides the clock when
reading
> the keyboard (which a moment ago you said was not required except to
> control the keyboard), you've just debugged your method; that's
wrong -
> and I think not possible with the BX-24. The PS/2 keyboard supplies
the
> clock when the BX-24 is reading its data. You cannot control the
rate
> of data from the keyboard.

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

My 'Internet persona'is not very good. I seem too often to step on
other people's threads by not fully comprehending the thread. I
sometimes digress and I may mis-quote or provide a bit of information
that includes a typo. I sometimes express certainty where there should
be speculation.

I usually try to back-track to set the record straight and to have
people aware that I am trying to be a contributor. I try to use the
Group as a resource and to provide what little I know or might think as
a resource.

I don't think there are stupid questions. Sometimes the answers just
don't come across the way I want them, but I try to press on with
learning and keeping friends and associations that I make along the way.

When extremely misleading information comes up, Tom is just trying to
preserve the usefulness of this group as support. I respect his desire
to do so, even when he is telling me that I am wrong.



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )