Hacking More PSoCs and Integrating a PS2 Keyboard

By Conrad Mannering |

The Cypress Creator IDE is chock-full of useful ready-made FPGA hardware modules, which you drop and drag onto a schematic page in the Creator IDE to produce the design of your dreams.


As you all know by now, Crusty (me, the author) is never happy unless he’s pushing his own boundaries. Over the last 60 years, I have used a lot of technical gizmos and haven’t truly understood how these gizmos worked, which is why I have an understanding with Max the Magnificent that -- one day before I die -- I will re-life my long departed UK101 clone of the Ohio Scientific Superboard 6502 computer with my own new hardware version.

This desire to manufacture my lost youth has taken me into a lot of areas of old technology, which I have to admit I did not really understand, but that I’ve have used more times than I can count as an end-user. (Yes, Max, I come from an old British tribe that counts, “one, two, and many.”)

I have recently put the old video display technology of a PAL 625-line video display circuit into a Cypress PSoC 5 chip, using all the standard FPGA logic modules that Cypress has been so good about providing in the standard PSoC Creator IDE. I found that I had to learn a lot about the video technology I wanted to emulate. There was not much PSoC hardware on the web covering this older video technology, so I had to go to the net and learn about how to achieve my goal.

Flushed with success of displaying a video picture, I decided that I would use a standard (PC) PS2 Keyboard to input key strokes into my re-lifed UK101. Like the video display, surely it must possible to make a PS2 keyboard decoder out of the standard PSoC Creator IDE components, mustn’t it?

TestBed FreeSoC2 Development Board -- PSoC5LP (Source: Crusty, a.k.a. Michael Conrad Mannering)

I had thought that there would be a whole host of pre-compiled components or projects available from Cypress users that have already achieve decoding PS2 keyboard transmissions, but surprisingly, I didn’t come up with any hits on the web that I wanted to use. Having said this, now that I’ve created my own solution, my recent searches seem to turn up quite an array of other ways to do this. Perhaps Google knew I wanted to do my own thing?

I had previously thought to use a PS2 keyboard interface module available for a few UK pounds on Amazon and E-Bay, but none of those seemed to work well. They do a lot better when not connected to a dead keyboard; when connected to a working keyboard, they do work, but not the way I want.

I am down a few UK pounds for these modules, so they will be winging their way to the local technical college for the girls and boys to use.

The end result is that it’s been another round of learning how a PS2 keyboard communicates to the host PC. Happily, the web does have a lot of information on this -- some good and some not so good.

Craig Peacock has a brilliant article showing how the data is sent in both directions, which you can see here, and Scott Larson and Robert Nelson show how to implement a Verilog decoder for an FPGA here. This was such an inspiration in my hardware, because they showed that you only need an idle counter to trigger the hardware-to-software link. 

The big thing is that I did not want to do a lot of bit-bashing of individual ports. I feel that if you have FPGA fabric at your disposal, then why get tied up in lots of interrupt handling and waiting for individual port pins to be activated when the hardware can do most of the heavy lifting for you? 

So, is it difficult to make PSoC fabric capture a PS2 data and clock stream? In fact, it’s surprisingly easy, which may explain why no one puts their projects on the web, but this will not deter Crusty from blogging about this subject. Below is my Cypress Creator Schematic of the hardware used.

Cypress Creator Schematic (Source: Crusty, a.k.a. Michael Conrad Mannering)

I had previously thought to use a PS2 keyboard interface module available for a few UK pounds on Amazon and E-Bay, but none of those seemed to work well. They do a lot better when not connected to a dead keyboard; when connected to a working keyboard, they do work, but not the way I want.

I am down a few UK pounds for these modules, so they will be winging their way to the local technical college for the girls and boys to use.

The end result is that it’s been another round of learning how a PS2 keyboard communicates to the host PC. Happily, the web does have a lot of information on this -- some good and some not so good. 

Craig Peacock has a brilliant article showing how the data is sent in both directions, which you can see here, and Scott Larson and Robert Nelson show how to implement a Verilog decoder for an FPGA here. This was such an inspiration in my hardware, because they showed that you only need an idle counter to trigger the hardware-to-software link.

The big thing is that I did not want to do a lot of bit-bashing of individual ports. I feel that if you have FPGA fabric at your disposal, then why get tied up in lots of interrupt handling and waiting for individual port pins to be activated when the hardware can do most of the heavy lifting for you? 

So, is it difficult to make PSoC fabric capture a PS2 data and clock stream? In fact, it’s surprisingly easy, which may explain why no one puts their projects on the web, but this will not deter Crusty from blogging about this subject. Below is my Cypress Creator Schematic of the hardware used.

/* ========================================
 *
 * Copyright YOUR COMPANY, THE YEAR
 * All Rights Reserved
 * UNPUBLISHED, LICENSED SOFTWARE.
 *
 * CONFIDENTIAL AND PROPRIETARY INFORMATION
 * WHICH IS THE PROPERTY OF your company.
 *
 * ========================================
*/
#include "project.h"
#include "D:\Cypress\UK101\Workspace03\Design01.cydsn\I2C_Port_8Bit.h"
#include "D:\Cypress\UK101\Workspace03\Design01.cydsn\HD44780I2C.h"
#include <stdbool.h>
#include "D:\Cypress\MyIncludes\Bit_Control.h"
#include "D:\Cypress\MyIncludes\PS2_Keyboard.h"
#include "D:\Cypress\MyIncludes\PS2_Key_lookup.h"
CY_ISR(Get_Key_Frame)
{
    Raw_Data = ShiftReg_1_ReadRegValue();// read the data from the shift reg direct no clock needed
    Raw_KeyBuf[KeyBuf_In_Count] = Raw_Data; // put the value in the buffer
    KeyBuf_In_Count++; //Incriment the buffer
    NewValFlag = 1; // set the flag to say a new value got and return from the interrupt
};
int main(void)
{
    CyGlobalIntEnable; /* Enable global interrupts. */
    BackLight = BL_On;
    Initalise_LCD(HD44780I2C);
    SetLine_HD44780(0,0,true);
    WriteMessage_HD44780("Keyboard Test");
    CyDelay(2000);
    Timer_1_Start();
    Timer_1_Enable();
    ShiftReg_1_Start();
   
    New_Byte_StartEx(Get_Key_Frame);
    New_Byte_Enable();
    
    
    /* Place your initialization/startup code here (e.g. MyInst_Start()) */
    for(;;)
    {
        /* Place your application code here. */
        if (NewValFlag == 1 ) //test if there is a new key value sent from keyboard
        {   
           Read_Key_Buf(); 
        };
        CyDelay(1000);
    }
}
/* [] END OF FILE */

I actually created a Verilog module in place of the schematic, but it took up a lot more resources than the Cypress modules used in the schematic. When I looked into the Cypress Modules I had used, I discovered that and a lot of them perform the heavy lifting and shifting using the Cypress UDB fabric.

This takes me into another question waiting for an answer. Is the UDB logic using the microprocessor resources or the digital fabric?

I want to learn more about using the UDB logic/glue, but I’m scared of this new ghost in the wings. Has Cypress got a video lecture describing how to use the UDB resource?

I use the Cypress Video lectures a lot, and I really like the voice of one of the lecturers. He sounds so much like Alistair Cook, who, as kid, I listened to at night on my headphones as BBC radio broadcast called “Letter from America.” 

Currently, I have the data frame stop start and parity (odd) code checking written, and so its onto getting the ASCII hex from the key code sent, which you can see on the picture of the display I have managed to get done before sending this article to Max.

Testbed HD44780 4 * 20 display (Source: Crusty, a.k.a. Michael Conrad Mannering)

As far as I can understand, the PC keyboards somehow never opted to send ASCII standard characters for each key sent, but instead use what seems to be an arbitrary code for each physical key. This menas it has been a bit of a slog to set up a lookup data array with the corresponding key code and ASCII code linked all the way through the printable codes.

Next Question: is there a numerical or computational method for calculating ASCII values from PS2 key codes, other than via look-up tables? This is for my own satisfaction, it’s really not a problem as I have to have a lookup table to match keys to ASCII values when I re-life the output to the UK101 as it has an 8*8 scanned key matrix of its own design. So, part of this project will be to generate quasi key push codes to be scanned by the UK101 memory mapped port.

There is much more in the pipeline, which means that I can carry on boring you throughout the coming year, and the year after that, and – hopefully -- many more.

Join the Conversation!

User must log-in to comment.
  • by  David Ashton
    A lot of effort to read a keyboard, Crusty!  (And Happy New Year to you BTW.)  When I was playing around with the PICAXE chips (Microchip PIC chips with a basic interpreter) they have a command to read a keyboard that is connected to them - all the routine done for you.  That said I never got that far, but it does illustrate how they made the PICAXEs very easy to use.  You can also buy a remote control off them and get it to read that as well.  I have an amplifier module scrounged from an old TV that talks I2C.    I'd like to get a PIC to talk I2c to it - the PIC also reading the remote to tell it to increase volume, treble, bass etc.  As usual time is the problem.

    I am working on my plan to win the lotto and retire so I get time for this stuff.   But one ticket (paid $12.80 for it) won $22.10, and the other won a free ticket.  Suppose I should not complain, but the $1.4 and 6 million that were the big prizes would have been nicer... :-(

  • by  Conrad Mannering
    Hi David, I gave up on chance long ago when on a weekend that everyone was supposed to have won the football pools I ended up loosing my weekly stake. However good luck for the next draw.


    I never got to grips with the PICAXE chips though I have played with the PROPELLER chips which are an oddity but extremely powerful. 

    I have used BASCOM for BASIC programming of AVR chips and it is like the PICKAXE Basic in that it has a pre_Compiled routines for the PS2 keyboard. 

    I found it hard when I started working with FPGA fabric moving my mind set away from linear programming and into lots of things happening at the same time on their own. Max has written a lot about this in his vey good books on the subject. 

    I just wish Max would put his mind to writing a simple primer for how to write Test Benches.  

    Whilst it looks like a lot of work one of the good things about "C" programming is that you can link header files into your new project, so I have only worked at this time on the code to support the keyboard hardware. The 4 * 20 line display is a header file that I worked on when the first cheap PSoC development boards came out. So you know where I am going with this thread the Keyboard code is becoming a hardware module and header file that will be available next time I do anything needing the PS2 Keyboard. I would have done a PS2 USB keyboard but the PSOC 5 at the moment does not itself support a USB host mode.

    PS I apologise for the slightly doubled up text as I think my hard copy may have got a bit of festive exuberance while it winged its way to Max.


    • by  Aubrey Kagan

      Crusty

      PS I apologise for the slightly doubled up text as I think my hard copy may have got a bit of festive exuberance while it winged its way to Max.

      The hot links also were also omitted.

      Craig Peacock has a brilliant article showing how the data is sent in both directions, which you can see here, and Scott Larson and Robert Nelson show how to implement a Verilog decoder for an FPGA here.

  • by  Aubrey Kagan

    Crusty

    PS I apologise for the slightly doubled up text as I think my hard copy may have got a bit of festive exuberance while it winged its way to Max.

    The hot links also were also omitted.

    Craig Peacock has a brilliant article showing how the data is sent in both directions, which you can see here, and Scott Larson and Robert Nelson show how to implement a Verilog decoder for an FPGA here.

  • by  Aubrey Kagan (edited)

    Crusty

    I actually created a Verilog module in place of the schematic, but it took up a lot more resources than the Cypress modules used in the schematic. When I looked into the Cypress Modules I had used, I discovered that and a lot of them perform the heavy lifting and shifting using the Cypress UDB fabric.

    '''

    I want to learn more about using the UDB logic/glue, but I’m scared of this new ghost in the wings. Has Cypress got a video lecture describing how to use the UDB resource?

    I would really like to see a series of lectures on both the subject of using Verilog and UDBs. I admire that you got to work with the Verilog aspect. I think I will need some pointers from you.


  • by  Conrad Mannering
    Hi Aubrey,

    I hope the new year is good to you and all of us.

    I think I would like to collaborate with you on the aspect of modules. 

    The is a great amount that I still need to understand .

    A module using Verilog I can just about understand, but it is bit hard work to put into the PSOC WARP Verilog into the module as you basically have to type the code in and hope that it works. If I try to port say Xilinx ISE Verilog  into the WARP environment I have to do a lot of changes.

    If I could get hold of a full WARP Verilog environment then I think things might be easier.

    The UDB is powerful without doubt and I think I am going to have to take time out try and get something working. Probably the Keyboard module could be done in the UDB almost entirely.

    Yes I just noticed that one of the links has been broken and this is a very good explanation.

    here for Beyond Logic PS2 keyboard description

    Regards Crusty

  • by  John Beetem (edited)

    When I saw the title "Hacking More PSoCs" I eagerly looked to see if this article was about hacking the PSoC chip itself, particularly the routing matrix.  When I first heard about PSoC5 back in 2010 IIRC, I was very excited since it seemed like the register documentation defined how to program all chip resources at the bit level.  It does, except for the routing matix.

    Thus every year or so I ask whether anyone has published how to program the PSoC3/4/5 routing matrix.  PSoC Creator is a fine tool if you "like flying a jet airliner with 100,000 switches" as a professor of mine once put it, but I would like to have open-source alternatives.  Also, I avoid Microsoft Windows as much as possible.

    • by  Aubrey Kagan (edited)

      John

      Back in the early days of PSOC1 (it was just PSoC then, and in reality, probably PSoC 0 (that's a zero, this vershtukener editor won't let me enter the numeric zero here), since the original version of the chip is obsolete) I was trying to make the chip reconfigurable (because dynamic reconfiguration had not yet been implemented in PSoC Designer) and I went through the source code- I found that the compiler created a table of all the register bits and then fetched the set up from there. Taking one configuration and comparing to a second allowed one to deduce the different bits.

      PSoC3/4/5 doers not offer dynamic reconfiguration as part of PSoC Creator- I am not sure whether there is a reason that it cannot be done, or it is just that the designers of PSoC Creator decided that the parts were versatile enough not to warrant the feature.

      Maybe one day I will investigate that as a post-retirement exercise. Watch this space (unless someone gets there first), but my results would be limited to whatever I can achieve within Windows and given my background the likelihood of using Microsoft Excel would be quite high..
  • by  Aubrey Kagan (edited)

    John

    Back in the early days of PSOC1 (it was just PSoC then, and in reality, probably PSoC 0 (that's a zero, this vershtukener editor won't let me enter the numeric zero here), since the original version of the chip is obsolete) I was trying to make the chip reconfigurable (because dynamic reconfiguration had not yet been implemented in PSoC Designer) and I went through the source code- I found that the compiler created a table of all the register bits and then fetched the set up from there. Taking one configuration and comparing to a second allowed one to deduce the different bits.

    PSoC3/4/5 doers not offer dynamic reconfiguration as part of PSoC Creator- I am not sure whether there is a reason that it cannot be done, or it is just that the designers of PSoC Creator decided that the parts were versatile enough not to warrant the feature.

    Maybe one day I will investigate that as a post-retirement exercise. Watch this space (unless someone gets there first), but my results would be limited to whatever I can achieve within Windows and given my background the likelihood of using Microsoft Excel would be quite high..
  • by  Conrad Mannering
    Hi John,

    Lets answer the aspect of PSoC Creator as I see it, as you say it is chock full of things and so is Word or Excel and most of the time most people just use a 1/10 of the available IDE to do what they wan,  just as they want with no problems. Which is the way PSoC works for me.

    I like the Mac, I also like Windows 10, if I avoid one tool available to me as an engineer, then I would not be as productive as I want. so I use both systems equally.

    As far as the routing matrix is concerned I just do not have the time to think about trying to do what Cypress have put in place already.

    If we take open source to the maximum then I suppose we would all be asking for a bench top fab uint. Something for a crowd sourcing project maybe?

    However I agree with you knowing what is under the hood is a good thing.

    Best Crusty.


Add Comment

You must log-in to comment.