Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 7 of 7

Thread: Reading digital input for use keyboard commands

  1. #1
    Junior Member
    Join Date
    Apr 2018
    Posts
    6

    Reading digital input for use keyboard commands

    I want to hook my teensy 3.2 up to some gpio on an SBC. I would like to use 5-7 pins to read a signal and depending in which oins were on/off output those characters as usb keyboard keys. I have worked with usb keyboard libary. I just need advice on reading the pins and timing etc. So for instance 0000001 would be "a" 0000010 would be "b" . I understand I will have to write ankey mapping. Any advice would be awesome. Perhaps there is a library already?

  2. #2
    Senior Member
    Join Date
    Apr 2013
    Posts
    1,899
    The simple/ugly way to do this is via nested ifs doing pin reads and flowing down a tree structure This may actually make sense if your GPIO pins will make a complex pinmap (for instance if an 'error' pin should override the values read from others)

    if you are trying to reconstruct a byte a slightly better way is to create a temp byte variable and then have an if per pin cycle that adds the relevant pin value to it
    byte tempvalue =0;
    if (digitalRead(0)==HIGH) tempvalue=tempvalue+1;
    if (digitalRead(1)==HIGH) tempvalue=tempvalue+2;
    if (digitalRead(2)==HIGH) tempvalue=tempvalue+4;
    if (digitalRead(3)==HIGH) tempvalue=tempvalue+8;
    ...
    etc and then do your logic on tempvalue

    You can also do this in a while statement where you have a power value that you start at 1 and double each time you go through the loop, and if the current pin is HIGH add to the tempvalue

    A nominally faster approch involves adding your digitalRead value to tempvalue and rotating bits left each time with << but that requires a good mental model of bitwise operations.

    Finally you can carefully wire your pins so that the correspond with a single hardware port (and nothing else is on that port) and read the port as a single operation. If raw speed is critical this fastest but you end up with rats nest wiring. It may also avoid a read delay issue - think about what happens if your SBC changes value during a read cycle (So changes from 0011 to 0100 between second and third read), you may end up reading 0000 for that read cycle.

    Not something you asked for but if you have access to the SBC code side it may be easier to use some form of hardware method, either serial or I2C to get your byte from one to the other, basically use the hardware on both chips to do the heavy lifting for you.

  3. #3
    Junior Member
    Join Date
    Apr 2018
    Posts
    6
    Thanks! I was going to try and use an onion Omega 2, it has serial, SPI, and I2C. Which of those interfaces would work the best for this? I know nothing about that sort of communication but I can learn.

  4. #4
    Senior Member
    Join Date
    Apr 2013
    Posts
    1,899
    The simplest one is probably serial*, which depends a bit on your onion side code but would looks something like:
    https://docs.onion.io/omega2-docs/uart1.html
    Then you load the Teensy with file->examples->Teensy->Serial->EchoBoth
    Make sure both serial ports have the same baud rate and that you have transmits connected to receives (not transmit to transmit - that is bad!)
    Wire things up and stuff sent from your onion should echo onto the USB serial and the arduino terminal and vice versa.

    Then tweak on that example a bit to send the byte coming from the Onion to the code you are trying do things with. You may also want to remove the code that sends bytes arriving on serial 1 back out serial one so the onion is not getting bombarded with bytes.

    If you are just trying to send one byte then you probably only need a send on the onion end and a read on the Teensy end. Remember that if you do this that byte values from 0-16 are special and will do strange things if you write it straight out. The differences between
    https://www.arduino.cc/en/Serial/Write
    https://www.arduino.cc/en/Serial/Print
    matter while you are fault finding (ascii '1' does not equal char 0x01)

    All being well it can be a pretty painless process and may involve just two wires (Data from Onion to Teensy and Gnd).

    * for your use case which appears to be sending a byte - if you needed to send larger structures or control multiple devices I2C and SPI start becoming more useful.

  5. #5
    Junior Member
    Join Date
    Apr 2018
    Posts
    6
    Also could I do this with a 2.0 instead of a 3.2? The goal is to get data over serial and send keyboard keys with the USB keyboard library. Just want to save cost where I can.

  6. #6
    Junior Member
    Join Date
    Apr 2018
    Posts
    6
    Sort of bumping this thread I'm going to get testing tomorrow ish any help on the power question would be great.

  7. #7
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,782
    Looking at the deleted post I see a question about power?

    The internal VUSB pin will have 5V from USB when connected - that can be used.

    For cost savings use a Teensy LC - cheaper and more powerful than the Teensy 2 and generally fully compatible with the T_3.x family items just scaled down some.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •