Main > Main Forum

Which is better - I-pac or KeyWiz keyboard encoder?

<< < (9/17) > >>

AndyWarne:

--- Quote from: Fozzy The Bear on February 02, 2008, 09:57:38 am ---
I'm just about to start using the Cypress chips on another project that has nothing to do with arcade machines. They really are very adaptable little beasts. I notice they incorporated your passthrough and auto interface detection directly into some of their other chips now. They should be paying you a development fee ROFL  :laugh2:


--- End quote ---
If they have used my pass-through code I need to know about it! But I cant imagine why or where they would use a keyboard pass-through.
The auto-detect code thats in some of the Cypress reference designs is an early version which gets it wrong quite often. The later version was a joint effort between myself and Cypress and, yes, I did get paid for it!
Beware of using these chips now though as in some packages they are obsolete and others they are in "not recommended for new design" status which means they will go obsolete soon. Another problem with these chips is that the development boards are expensive and crap (Cypress openly admit this!). I suppose I cant complain though as I never bought mine, I just blagged them off Cypress.

Fozzy The Bear:

--- Quote from: AndyWarne on February 02, 2008, 02:40:01 pm ---Beware of using these chips now though as in some packages they are obsolete and others they are in "not recommended for new design" status which means they will go obsolete soon.
--- End quote ---

I guess, that means you and Randy are going to be looking for a new core chip very shortly then.

Best Regards,
Julian (Fozzy The Bear)

Grasshopper:

--- Quote from: RandyT on January 31, 2008, 11:38:11 am ---
--- Quote from: patrickl on January 31, 2008, 10:40:46 am ---Of the last 5 computer I bought over the last few years none had a PS/2 connector.

--- End quote ---

That's because you keep buying computers that don't have them.  :)  We did this dance a few years back when people were incorrectly predicting that the demise of PS/2 was "right around the corner" (and I think you were one of them, using the same shaky argument).......

--- End quote ---

I'm not sure I agree with that. Sure most full size ATX motherboards still have PS/2 connectors but they're far less common on smaller form factor boards, and very few laptops have them.  The trend seems to be towards much smaller computers and motherboards so eventually lack of space is likely to dictate that the legacy ports will slowly disappear.

Tiger-Heli:

--- Quote from: Grasshopper on February 02, 2008, 03:42:02 pm ---Sure most full size ATX motherboards still have PS/2 connectors but they're far less common on smaller form factor boards, and very few laptops have them.  The trend seems to be towards much smaller computers and motherboards so eventually lack of space is likely to dictate that the legacy ports will slowly disappear.
--- End quote ---
Points taken, but very few people are buying the KeyWiz for use on a laptop (maybe for a bartop cab, but that would be a small fraction of total sales).  For arcade cab builders buying new motherboards, if you want to use the KeyWiz, you can find a board with PS/2 ports, just like if you have two IDE CD's and an IDE HD, you can find a board with two IDE controllers (with a lot of looking), and for cab builders buying used hardware or upgrading their primary CPU and moving the old one to the cab, the boards will likely still have legacy support by definition of their age.

RandyT:
I apologize in advance for the long and technical posts that are about to ensue.  Some of this I have brought up in the past.  If you don't care about these types of things, feel free to stop reading now :)


--- Quote from: AndyWarne on February 02, 2008, 05:12:37 am ---So, when the keyboard is idle, no interrupts are generated and no processing is required by the pass through. It is not polled at all.

--- End quote ---

Ok, I'm not going to state that there is always functional speed impact on a well implemented pass-through, but I do know a thing or two about the Cypress CY7C63413 Microcontroller.  You state that the IPAC "Does not use a scanning method which causes a variable delay" and is "interrupt driven" so the following must apply.  I won't even go into why it's impossible to know what is happening on the inputs without "scanning" or why scanning can actually be as fast (or faster) and uniform in speed.  But we can if you would like.

One very important thing to understand when considering how these chips function is that the GPIO (General Purpose Input / Output) interrupt is a single interrupt linked to all inputs set to trigger it.  On a device setup to be "interrupt" driven on it's inputs, all inputs would be set to trigger the GPIO interrupt.  That means that when the interrupt is triggered, the only way to know if it was the keyboard clock line that triggered it, rather than one of the other inputs, is to specifically examine that bit for activity. It would do this any time a button was pressed, a joystick was moved, etc.  Every time, without exception.

From the datasheet:

------

GPIO Interrupt

Each of the 32 GPIO pins can generate an interrupt, if enabled.  The interrupt polarity can be programmed for each GPIO port as part of the GPIO configuration. All of the GPIO pins share a single interrupt vector, which means the firmware will need to read the GPIO ports with enabled interrupts to determine which pin or pins caused an interrupt.


------

So it would be inaccurate to state that a "pass-through" does not use any clock cycles when not triggered.  It's status is checked every time the GPIO interrupt is triggered, otherwise it cannot know what exactly caused the interrupt. One could even accurately state that all inputs are "scanned" whenever one of them is pulled low (button press, etc.), and that's only if the interrupts are not disabled due to another interrupt driven service being acted upon at that moment.  Microcontrollers can only use the CPU for one thing at a time, period, interrupt driven or not.

Furthermore, clocking in bits from the keyboard (or other serial devices) is very timing sensitive, so interrupts which would normally be generated by GPIO ports would be held off.  If the same method were used in daisy chaining controllers, or used internally on a 4-player controller between microcontrollers, one would always be held off while another was being serviced.  Very messy and not the most efficient approach, which is another reason I don't support it.

As an aside, Pass-through ports are pretty much moot nowadays.  USB keyboards are cheap, they don't impact the encoder used at all, and work very happily alongside KeyWiz's, IPAC's, etc...


--- Quote from: AndyWarne on February 02, 2008, 05:32:24 am ---Its easy to see from a picture of the Keywiz that it uses the same chip (although they seem to sand off the part numbers on their chips for some strange reason) but its a different animal of course, different coding.

--- End quote ---

As for why we take the numbers off of the chips, it's spelled out in this very thread.  Laypersons aren't fully up to speed with the concept that a microcontroller is a "brick" without the code that gives it life / purpose.  Those same individuals often believe that chips which can be purchased at the local "electronics hut" have only the value of the purchase price, but without understanding how they work, the value of the software is not considered. Much like saying the media for the latest PS3 game costs less than a dollar, why do the games cost sixty? By removing identifying markings, the foundation for that incorrect assumption is removed.  BTW, it's a very common practice, especially for "caseless" products.

Is there anything else I can clear up for you regarding GGG's practices?   ;)

RandyT

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version