Jump to content
Sign in to follow this  
kuldeepdhaka

PS2 Interfaced with MSP430

Recommended Posts

i have been sucessful(somewhat) in interfacing a PS2 keyboard with MSP430.
usually for about ~25 keystrokes it works perfectly.
after that parity error occurs in data and data after the corrupt-data is also corrupt.
im supply keyboard 5V from external source and using POT to convert 5V to 3V.
communication with keyboard is at 20-25Khz and MSP430 is running at 16Mhz.
thing i tried (and didnt worked :-( ):
tried another keyboard.
circular queue to store temp data and then timer A1 to extract and decode.
 

note:
if im able to get first n data's then why is their a problem after that.
im having 4 more interrupts going on (usci0_rx (@ 9600 baud, 4Mhz), usci_tx, timerA0 ( @ 7Hz), timerA1 ( @ 500Khz )).
i have a MSP430G2553IN2.
 
   text       data        bss        dec        hex    filename
   6604          6        342       6952       1b28    build/diy-vt100.elf
 
total code(see below) is in diy-vt100.tar.gz
i had to remove doc/ , .git/ (size was ~100MB's)
schematics are not according to project right now.

ps2-scancode-en.c

ps2.c

port2.c

port2.h

ps2.h

diy-vt100.tar.gz

Edited by kuldeepdhaka

Share this post


Link to post
Share on other sites

i doubt anyone can spare the time to examine your full project and find intermittent problems. if u got this far (getting keys recognized) u understand better your code than anybody else.

 

u can describe better your problem and may be get advice here for where to look for things.

 

u have to 1st isolate the part that is problematic and may be present that part of code.

 

u only described that your project works well and after about 25 keys it suddenly failed.

 

Q.

 

  • can u repeat this diagnosis and does it fail every time (after reset), and it's always around 25 keys?
  • could your problem be time related. i.e. if u let your keyboard sit for 30 minutes it's the same problem, always after 25 keys or so?
  • can u do test with different keystrokes and does this affect the behavior? i.e. test1, type all 'a's, test2, type all 'z', etc.
  • using a POT to V-divide may not be the best idea for stable runs, can u put in a LDO or at least supply 2xAA=3v to msp430 during your trials?
  • u mention u are running 4+ interrupts (timer or what-not), if this is not essential at this stage, can u turn them off and retry? if successful, turn them back on one by one to pin-point the problematic one.
  • u mention parity error, did u list the "key typed" vs "key shown" and try to correlated them? it may give some hints. i.e. did we lost a bit, something got shifted?

Share this post


Link to post
Share on other sites

A:

  • yes mostly at 25 keys when i type "a for apple b for boy ".... slowly in one go, (sometimes it start occuring at 4/7/15 key but thats very rare, i think when i type fast error occurs early.)     near 25 means between 18 - 27 is more frequent.
  • Not tested
  • tried diferent keystrokes, didnt work
  • im supplying power to msp430 from USB and keyboard from external supply.
  • Not-tested
  • i have never seen any correlation between the error data and actuall data, though one thing was common that , everytime the error-data was mostly same as previous one. and some times no data was received.

Share this post


Link to post
Share on other sites

after that parity error occurs in data and data after the corrupt-data is also corrupt.

 

 

your code indicates that if there is a parity error, u had it enter a green led blink indefinitely. it is then locked up. additional key stroke would end up at the same place via interrupt.

 

may be u should let it thru (just turn on green led and pass) so u can see what happens w/ the next key stroke.

        case 8:
            if((!(KEYBOARD_PS2_PIN & KEYBOARD_PS2_DATA)) == (!keyboard_ps2.parity))
            {
                /* incorrect data */
                P1DIR |= BIT6;


                /* hang */
                while(1)
                {
                    P1OUT ^= BIT6;
                    __delay_cycles(600000);
                }
            }
            /* TODO: check parity for data */

also u are doing some business logic in your interrupt handler (when u see stop bit), are u sure u have enough time (every round) to do everything? i only look at it briefly and it appears to do uart / nokia display, etc.

 

it would be a good idea to move your business logic out of your interrupt handler.

 

 

        case 9:
            /* STOP bit */
            keyboard_ps2_data_decode();


        default:

u make effort and created various object modules but they are interlaced w/ one and other. a better approach would be to employ a "controller" module in your main.c to direct traffic.

Share this post


Link to post
Share on other sites

 

your code indicates that if there is a parity error, u had it enter a green led blink indefinitely. it is then locked up. additional key stroke would end up at the same place via interrupt.

 

may be u should let it thru (just turn on green led and pass) so u can see what happens w/ the next key stroke.

earlier i was doing so, then i wrote this "infinite blinking led" to check if im getting a parity error.

 

 

also u are doing some business logic in your interrupt handler (when u see stop bit), are u sure u have enough time (every round) to do everything? i only look at it briefly and it appears to do uart / nokia display, etc.

 

it would be a good idea to move your business logic out of your interrupt handler.

i also tried circular queue.

but no help.

 

 

 

u make effort and created various object modules but they are interlaced w/ one and other. a better approach would be to employ a "controller" module in your main.c to direct traffic.

 

not sure but lemme see.

till now i think my code is more optimized.

just to save push and pop in stack.

elaborate a little :).

 

NOTE:

A

  • i disabled all interrupts except port2(receive data from keyboard) & timerA1 (this is needed to print data on screen) but it didnt helped.
  • keyboard left alone for some time , shows same problem.

Share this post


Link to post
Share on other sites

 

 

not sure but lemme see.

till now i think my code is more optimized.

just to save push and pop in stack.

elaborate a little :smile:.

 

NOTE:

A

  • i disabled all interrupts except port2(receive data from keyboard) & timerA1 (this is needed to print data on screen) but it didnt helped.
  • keyboard left alone for some time , shows same problem.

 

 

it's a matter of programing style i guess. i would minimize things i do in interrupt handlers as u may have timing / re-entrant issues if u do too much there.

 

i would suggest also turn off timerA1 and rely only on your led to diagnosis the problem. your timerA1 is clocked at 500Khz u said and can easily run into your port2 interrupt (ps/2 clk at about 20khz). (check datasheet and see who has higher priority).

 

also it looks like your port2 interrupt is not disabling / re-enabling interrupts while servicing them. it's timing critical so u don't want any unnecessary blocking otherwise u will miss the beat readying from the keyboard.

 

both timerA1 and port2 access your queue. i did not examine it in detail but generally u would want to have some kind of locking.

 

well, not sure if my input can help. yours a big project and i don't have the h/w hook-up.

Share this post


Link to post
Share on other sites

it's a matter of programing style i guess. i would minimize things i do in interrupt handlers as u may have timing / re-entrant issues if u do too much there.

 

i would suggest also turn off timerA1 and rely only on your led to diagnosis the problem. your timerA1 is clocked at 500Khz u said and can easily run into your port2 interrupt (ps/2 clk at about 20khz). (check datasheet and see who has higher priority).

 

also it looks like your port2 interrupt is not disabling / re-enabling interrupts while servicing them. it's timing critical so u don't want any unnecessary blocking otherwise u will miss the beat readying from the keyboard.

 

both timerA1 and port2 access your queue. i did not examine it in detail but generally u would want to have some kind of locking.

 

well, not sure if my input can help. yours a big project and i don't have the h/w hook-up.

 

yes, one of the interrupt that i didnt disable (timer A1) was causing performance bottleneck.

i moved the code in main and goes to sleep inside while.

next time , timer A1 interrupt, it just wake up mps430. so their is not delay and when their are other interrupts, it plainly execute the main inside while() code and again goes to sleep.

in your previous comment , i think you mentioned something like this.

int
main()
{
    register uint8_t data;
    msp430_init();
    port1_init();
    vt100_init();
    
    splash();
    
    usci0_init();
    timerA_init();
    port2_init();

    while(TRUE)
    {
        _BIS_SR(LPM1_bits + GIE);
        
        /* screen refresh { */
        while(cqueue_count(uart_cqueue_rx))
        {
            vt100.data = cqueue_pop(&uart_cqueue_rx);
            control();
        }
        
        vt100_refresh();
        /* } */
        
        /* cursor blinking { */
        /* make sure we dont overflow the cursor */
        if(vt100.screen[vt100.cursor.row][0].double_width && vt100.cursor.col > VT100_WIDTH/2)
        {
            vt100.cursor.col /=2;
        }
        
        nokia1100_gotoyx(vt100.cursor.row, vt100.cursor.col * NOKIA1100_WIDTH_CHAR);
        
        vt100_print_char(vt100.cursor.row, vt100.cursor.col, vt100.mode.cursor_state);
        /* } */
    }
}

void timerA0_interrupt()
{
    vt100.mode.cursor_state ^= TRUE;
}

void timerA1_interrupt()
{
    /* exit sleep mode to refresh screen */
    __bic_status_register_on_exit(LPM1_bits);
    
    /* clear the interrupt flag */
    TACCTL1 &= ~CCIFG;
}

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...