Shop OBEX P1 Docs P2 Docs Learn Events
42 Key Keypad on 5 wires (Complete) - Page 2 — Parallax Forums

42 Key Keypad on 5 wires (Complete)

2»

Comments

  • I have used a lot of the 8051 parts, especially the Silabs parts but unless you are talking volume >1k then there is no point in picking the cheapest suitable part. Sometimes it pays just to spend $1 instead of 50c. I have Spin code that can burn the Flash of a Silabs part using just the Prop's I2C bus plus one extra select pin which is actually the clock/reset for programming. That way you solder the part in and use I2C plus one extra I/O to not only communicate with the keypad chip but also to Flash the part.

    Alternatively I leave 5 spaced vias for PIC chips so that I can press a PicKit programmer into the holes for ICP which is usually only ever once. I hate the small PIC instruction set but hardware is cheap and works whereas the 8051 parts are much nicer.

    I have also used a small XMC1100 in a tiny package running Forth so I don't even need to program any assembler code at all or use ICP, just paste a high-level Forth source code into it over the serial link and it is "programmed". In quantity they only cost around $1. This chip is now my preferred goto chip for small devices plus I have my one-wire high speed multidrop network built into Tachyon so I can have scores of different slave devices on the "network" which I can interact with at the Forth level and debug or reprogram them over the network. Dead simple.
  • I have used a lot of the 8051 parts, especially the Silabs parts but unless you are talking volume >1k then there is no point in picking the cheapest suitable part. Sometimes it pays just to spend $1 instead of 50c. I have Spin code that can burn the Flash of a Silabs part using just the Prop's I2C bus plus one extra select pin which is actually the clock/reset for programming. That way you solder the part in and use I2C plus one extra I/O to not only communicate with the keypad chip but also to Flash the part.

    Alternatively I leave 5 spaced vias for PIC chips so that I can press a PicKit programmer into the holes for ICP which is usually only ever once. I hate the small PIC instruction set but hardware is cheap and works whereas the 8051 parts are much nicer.

    I have also used a small XMC1100 in a tiny package running Forth so I don't even need to program any assembler code at all or use ICP, just paste a high-level Forth source code into it over the serial link and it is "programmed". In quantity they only cost around $1. This chip is now my preferred goto chip for small devices plus I have my one-wire high speed multidrop network built into Tachyon so I can have scores of different slave devices on the "network" which I can interact with at the Forth level and debug or reprogram them over the network. Dead simple.

    I keep seeing Tachyon 4th. Assuming I don't need an OS is there a distinct advantage to programming in 4th over Prop C and ASM? I'm willing to take the pill if there's a reason.
  • I keep seeing Tachyon 4th. Assuming I don't need an OS is there a distinct advantage to programming in 4th over Prop C and ASM? I'm willing to take the pill if there's a reason.

    Hmmm, lots and lots of reasons including the fact that things just work, it has a lot of device drivers built into it for RTC, EEPROM, keypads, LCDs, Shift regs, PING, DHT22, very fast SPI, 1-wire, I2C, WS2812, F32, 32-channel PWM, FAT32 on SD cards, Ethernet, my own one wire or RS485 networking etc etc. You won't get any faster SPI even in ASM plus Spin/C which is the bottleneck since the SPI interface in Tachyon is essentially a set of instructions that access PASM subroutines in the Tachyon cog. The same with SD cards as the interface communicates at 10MHz and the high level keeps up with it very well too.

    It is very fast and compact so it all squeezes into a standard Prop and of course you don't need a compiler and debugger as the resident Tachyon is the compiler, debugger, and application. This is at lease one of the reasons we are building a version of this to fit in the upcoming P2 boot mask ROM.

    Besides all that it is a lot of fun, it brings back the "hands on" interaction with the hardware and the software that you lose when using a PC based compiler and download the binary. The original Tachyon thread is huge but the V4 thread is a lot easier to trawl through. Click on my sig pic for a link page.
  • I keep seeing Tachyon 4th. Assuming I don't need an OS is there a distinct advantage to programming in 4th over Prop C and ASM? I'm willing to take the pill if there's a reason.

    Hmmm, lots and lots of reasons including the fact that things just work, it has a lot of device drivers built into it for RTC, EEPROM, keypads, LCDs, Shift regs, PING, DHT22, very fast SPI, 1-wire, I2C, WS2812, F32, 32-channel PWM, FAT32 on SD cards, Ethernet, my own one wire or RS485 networking etc etc. You won't get any faster SPI even in ASM plus Spin/C which is the bottleneck since the SPI interface in Tachyon is essentially a set of instructions that access PASM subroutines in the Tachyon cog. The same with SD cards as the interface communicates at 10MHz and the high level keeps up with it very well too.

    It is very fast and compact so it all squeezes into a standard Prop and of course you don't need a compiler and debugger as the resident Tachyon is the compiler, debugger, and application. This is at lease one of the reasons we are building a version of this to fit in the upcoming P2 boot mask ROM.

    Besides all that it is a lot of fun, it brings back the "hands on" interaction with the hardware and the software that you lose when using a PC based compiler and download the binary. The original Tachyon thread is huge but the V4 thread is a lot easier to trawl through. Click on my sig pic for a link page.

    That is impressively fast. I'm taking a different approach for my current project, but I will dig into 4th soon.
    Thanks for the info.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2017-12-13 03:25
    Don't use 74HCxxxx powered from 5V with a Prop. Use 74HCTxxxx instead. 74HC's inputs are not reliable with a 3.3V high.

    -Phil
  • Don't use 74HCxxxx powered from 5V with a Prop. Use 74HCTxxxx instead. 74HC's inputs are not reliable with a 3.3V high.

    -Phil

    Thank you, Phil

    I will do just that.

    I'm using the 4027 as an SR latch. What SR latch would you recommend for use with the 74HCT4017, please?
  • jmgjmg Posts: 15,140
    I'm using the 4027 as an SR latch. What SR latch would you recommend for use with the 74HCT4017, please?
    The classic 74HC Flip Flop, is the 74HC74, which has active low SET and CLR pins.
  • jmg wrote: »
    I'm using the 4027 as an SR latch. What SR latch would you recommend for use with the 74HCT4017, please?
    The classic 74HC Flip Flop, is the 74HC74, which has active low SET and CLR pins.

    Sweet. After I finish the 40xx I'll get those.
    Thank you
  • I've made a better version of the 40xx circuit here

    I posted more info with the schematic linked on imgur at the bottom of the video description.

    I will be hooking it up to a Prop in the next video :-D
  • kwinnkwinn Posts: 8,697
    edited 2017-12-14 03:31
    Looking good.
  • mikeologistmikeologist Posts: 337
    edited 2017-12-17 00:01
    Well, it works!
    I have learned that this is not the best method of achieving my goals, but I did complete my original goal of a multiplexing a large keypad onto 5 wires reading 4 bits in parallel. (Though, the parallel part is still not really parallel yet)

    It has no cross chatter and bounce does not effect the circuit, even at full speed.
    As predicted by others, the 40xx ICs are plenty fast for what the propeller can do. So there is no need to make the 74xx version.

    I still have a lot of optimization to do but here is the functioning code in Prop C:
    #include "simpletools.h"                  // Include simple tools
    
    int main()                                // main function
    {
      int buttons[] = {0,0,0,0};              // row buffer
      while(1)                                // Endless loop
      {
        int index;
        for(index = 0; index < 13; index++) { // Scan loop, to be time-sliced
          high(0);                            // Raise P0, Clock the multiplexer
          buttons[0] = input(1);              // P1 input -> button variable
          buttons[1] = input(2);              // P2 input -> button variable
          buttons[2] = input(3);              // P3 input -> button variable
          buttons[3] = input(4);              // P4 input -> button variable
          print("%d%d%d%d\n", buttons[0], buttons[1], buttons[2], buttons[3]);
          low(0);                             // Lower P0    
        }                                   
        pause(125);                           //125ms to time-slice other cog functions
      }
    }
    

    My next step after this is to build a controller out of an N76E003. It will pole the keys and buffer the decoded characters until my cog calls for them, and the best part is it will only need one wire to my Prop. It took some convincing but I see how this is vastly superior compared to my current design.
    I will continue this thread with that project as well.

    I may not have listened right away but everyone who commented here was a big help.
    Thank You
    2100 x 2258 - 883K
    1954 x 3496 - 1M
    2620 x 2400 - 2M
  • All soldered and tested. Now I just need to finish the software.
    2031 x 3563 - 1M
    1989 x 3262 - 1M
  • Parallel read code:
    int Mask = 0x1e; // pins 4, 3, 2, 1
    int I = INA & Mask;  // read all input pins and remove excess
    I = I >> 1;  // normalize value to 4 bits
    print("%d \n", I); //keyboard value
    

    Mike

  • iseries wrote: »
    Parallel read code:
    int Mask = 0x1e; // pins 4, 3, 2, 1
    int I = INA & Mask;  // read all input pins and remove excess
    I = I >> 1;  // normalize value to 4 bits
    print("%d \n", I); //keyboard value
    

    Mike

    Thanks a bunch
    #include "simpletools.h"                  // Include simple tools
    
    int main()                                // main function
    {
      int row_bf;
      int index;
      while(1)                                // Endless loop
      {
        for(index = 0; index < 13; index++) { // Scan loop, to be time-sliced
          high(4);                            // Raise P4, Clock the multiplexer
          row_bf = INA & 0xf;                 // Read pins 0, 1, 2, 3
          print("%d \n", row_bf);
          low(4);                             // Lower P4    
        }                                   
        pause(100);                           // 100ms to time-slice other cog functions
      }
    }
    

    This works very well, thanks @iseries :-)
  • I admire your fortitude, making all those solder connections!

    -Phil
  • I admire your fortitude, making all those solder connections!

    -Phil

    Thanks :smile:
    I need the practice
Sign In or Register to comment.