Hello to all GCbasic users out there.
I need a bit of help to test the buttons (& specific displays)
Attached is a .GCB test program to read TM1638 Keys & display Button Number
or Raw hex data. (4 bytes)
I have tested 2 module boards I have:
"LED&KEY" - This one is Common Cathode display with non sequential wired button switches
"QYF-TM1638" -This one is Common Anode display with sequentially wired button switches & digit com pins are wired reverse.
If you get a garbled display or out of order buttons, try another configuration constant by enabling another #define in the Configuration. (only 1 can be enabled)
'#Define TM1638_OEM ' "OEM" board (Common Cathode display & No Btn re-Map)
'#Define TM1638_OEM ' "LED--KEY" module board (should be same as OEM)
'#Define #Define LED_KEY ' "LED&KEY" module board (Common Cathode display & Btn re-Map)
QYF_TM1638 ' "QYF-TM1638" board (Common Anode display & rev. digits)
' #Define NEW_BRD1 ' "new board" here & edit #Script
If none work then enable #Define NEW_BRD1, & edit the Script block IF DEF(NEW_BRD1) by un-commenting relevant line.
If you get out of order buttons with or without Butn_Map1 active in script, change mode to display raw key values, enable this line #Define Raw_Key,
Refer attached "TM1638 Buttons Table.pdf" & then edit table Butn_Map2 in the .GCB code.
Looking at a schematic of a board "LED--KEY" is shows sequentially wired buttons, so this one should be display = Com_Cathode , Button re-map = inactive, RevDig = inactive.
Any result of testing will be much appreciated.
It is quite likely some "Identical looking" boards may be wired different.
I tested with my LED&KEY board -worked in a few seconds on a LGT board!
Result:
When static (no buttons pressed) Eight 0s.
Push any single button - a value of the button is shown on right hand LED = ranges from 1 to 8 returning to 0 when the button is released
Then, all the conditioanl logic and the assiocated code blocks that 'will be' processed. Showing the line numbers and the tests. The #ENDIFs are not shown. And, noting that #ELSE (if used) is shown as inverse test ( #IF > #IF NOT, IFDEF > IFNDEF etc).
135:#IFNDEFRAW_KEY;Makealinearbuttonmapfrom4Keybytes(Onlysinglekeypress);ForCnt1=1to4137:FORCNT1=1TO4;SelectCaseTMKeyVal(Cnt1)138:SELECTCASETMKEYVAL(CNT1);Case4139:CASE4;IfCnt1=1thenButnVal=1140:IFCNT1=1THEN;IfCnt1=1thenButnVal=1140:BUTNVAL=1;IfCnt1=1thenButnVal=1140:ENDIF;IfCnt1=2thenButnVal=3141:IFCNT1=2THEN;IfCnt1=2thenButnVal=3141:BUTNVAL=3;IfCnt1=2thenButnVal=3141:ENDIF;IfCnt1=3thenButnVal=5142:IFCNT1=3THEN;IfCnt1=3thenButnVal=5142:BUTNVAL=5;IfCnt1=3thenButnVal=5142:ENDIF;IfCnt1=4thenButnVal=7143:IFCNT1=4THEN;IfCnt1=4thenButnVal=7143:BUTNVAL=7;IfCnt1=4thenButnVal=7143:ENDIF;Case64144:CASE64;IfCnt1=1thenButnVal=2145:IFCNT1=1THEN;IfCnt1=1thenButnVal=2145:BUTNVAL=2;IfCnt1=1thenButnVal=2145:ENDIF;IfCnt1=2thenButnVal=4146:IFCNT1=2THEN;IfCnt1=2thenButnVal=4146:BUTNVAL=4;IfCnt1=2thenButnVal=4146:ENDIF;IfCnt1=3thenButnVal=6147:IFCNT1=3THEN;IfCnt1=3thenButnVal=6147:BUTNVAL=6;IfCnt1=3thenButnVal=6147:ENDIF;IfCnt1=4thenButnVal=8148:IFCNT1=4THEN;IfCnt1=4thenButnVal=8148:BUTNVAL=8;IfCnt1=4thenButnVal=8148:ENDIF;Case2149:CASE2;IfCnt1=1thenButnVal=9150:IFCNT1=1THEN;IfCnt1=1thenButnVal=9150:BUTNVAL=9;IfCnt1=1thenButnVal=9150:ENDIF;IfCnt1=2thenButnVal=11151:IFCNT1=2THEN;IfCnt1=2thenButnVal=11151:BUTNVAL=11;IfCnt1=2thenButnVal=11151:ENDIF;IfCnt1=3thenButnVal=13152:IFCNT1=3THEN;IfCnt1=3thenButnVal=13152:BUTNVAL=13;IfCnt1=3thenButnVal=13152:ENDIF;IfCnt1=4thenButnVal=15153:IFCNT1=4THEN;IfCnt1=4thenButnVal=15153:BUTNVAL=15;IfCnt1=4thenButnVal=15153:ENDIF;Case32154:CASE32;IfCnt1=1thenButnVal=10155:IFCNT1=1THEN;IfCnt1=1thenButnVal=10155:BUTNVAL=10;IfCnt1=1thenButnVal=10155:ENDIF;IfCnt1=2thenButnVal=12156:IFCNT1=2THEN;IfCnt1=2thenButnVal=12156:BUTNVAL=12;IfCnt1=2thenButnVal=12156:ENDIF;IfCnt1=3thenButnVal=14157:IFCNT1=3THEN;IfCnt1=3thenButnVal=14157:BUTNVAL=14;IfCnt1=3thenButnVal=14157:ENDIF;IfCnt1=4thenButnVal=16158:IFCNT1=4THEN;IfCnt1=4thenButnVal=16158:BUTNVAL=16;IfCnt1=4thenButnVal=16158:ENDIF;Case1159:CASE1;IfCnt1=1thenButnVal=17160:IFCNT1=1THEN;IfCnt1=1thenButnVal=17160:BUTNVAL=17;IfCnt1=1thenButnVal=17160:ENDIF;IfCnt1=2thenButnVal=19161:IFCNT1=2THEN;IfCnt1=2thenButnVal=19161:BUTNVAL=19;IfCnt1=2thenButnVal=19161:ENDIF;IfCnt1=3thenButnVal=21162:IFCNT1=3THEN;IfCnt1=3thenButnVal=21162:BUTNVAL=21;IfCnt1=3thenButnVal=21162:ENDIF;IfCnt1=4thenButnVal=23163:IFCNT1=4THEN;IfCnt1=4thenButnVal=23163:BUTNVAL=23;IfCnt1=4thenButnVal=23163:ENDIF;Case16164:CASE16;IfCnt1=1thenButnVal=18165:IFCNT1=1THEN;IfCnt1=1thenButnVal=18165:BUTNVAL=18;IfCnt1=1thenButnVal=18165:ENDIF;IfCnt1=2thenButnVal=20166:IFCNT1=2THEN;IfCnt1=2thenButnVal=20166:BUTNVAL=20;IfCnt1=2thenButnVal=20166:ENDIF;IfCnt1=3thenButnVal=22167:IFCNT1=3THEN;IfCnt1=3thenButnVal=22167:BUTNVAL=22;IfCnt1=3thenButnVal=22167:ENDIF;IfCnt1=4thenButnVal=24168:IFCNT1=4THEN;IfCnt1=4thenButnVal=24168:BUTNVAL=24;IfCnt1=4thenButnVal=24168:ENDIF;CaseElse;ButnVal=0;EndSelect171:ENDSELECT;Next172:NEXT174:#IFDEFBUTN_MAP1;ReadTableButnMap1,ButnVal-16,ButnVal175:READTABLEBUTNMAP1,BUTNVAL-16,BUTNVAL174:#IFDEFBUTN_MAP1;ReadTableButnMap1,ButnVal-16,ButnVal175:READTABLEBUTNMAP1,BUTNVAL-16,BUTNVAL240:#IFDEFCOM_CATHODE;setTM1638_STB0241:SETTM1638_STB0;TM1638_WrVal(TMcmd2)' Fixed address mode 44h __ 242: TM1638_WRVAL (TMCMD2) ;set TM1638_STB 1 243: SET TM1638_STB 1 ;Wait TMdly us 244: WAIT TMDLY US ;For BufIndx = Dig_pos - (Num_Digs -1) to Dig_pos 245: FOR BUFINDX = DIG_POS - (NUM_DIGS -1) TO DIG_POS ;set TM1638_STB 0 246: SET TM1638_STB 0 ;TM1638_WrVal (TMaddr +(BufIndx -1)*2) 'Digitaddr247:TM1638_WRVAL(TMADDR+(BUFINDX-1)*2);TM1638_WrVal(DBuf(BufIndx))'Digitdata248:TM1638_WRVAL(DBUF(BUFINDX));setTM1638_STB1249:SETTM1638_STB1;WaitTMdlyus250:WAITTMDLYUS;Next251:NEXT;tmCtrlSnd252:TMCTRLSND
I have updated the test code to enable Multiple key press, a value greater than 24 will be result.
Only the boards with diodes on the key lines will work (so not the QYF- board)
Not all combination will work due to the LED multiplexing.??
The actual return value of a multi key press is (obviously) dependent on the wiring order between switches & TM1638 so could vary between different boards.
The "LED&KEY" board has misaligned key wiring ( K3 & KS not sequential).
An OEM board should align switch button numbers to K1->K3 & KS1->KS8. eg.K1_KS1=butn1
File in a later post. - Test_TM1638_2Buttons.gcb
Last edit: ToniG 2022-09-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The "LED&KEY" board with misaligned key wiring works. ;-)
The user could simply write a lookup table to correct the misaligned key wiring ? Or, is it the case that pressing more than one key will yield results that may be Zero? ( S1&S5;S2&S6;S8&S4;S7&S3 )
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please disregard the previous "Test_TM1638_Buttons.gcb", there are 2 issues with 2 buttons code.
I only have 1 board that will do multi button press test. LED&KEY (17-24 key codes)
1. The method was flawed, same value could result with different combination of low key values.
2. My assumption "...due to the LED multiplexing.??" was incorrect, actually was due to 2 key bits in the same byte.
I have modified to new file "Test_TM1638_2Buttons.gcb"
It has 2 bytes. ButnVal for 1 key & ButnVal2 for 2nd key.
User can test for non-zero value in ButnVal2.
Lower button number is always ButnVal.
This could be useful for a shift function.
I can put it in TM1638_OEM_lib
(I hope someone can find any issues)
Edit:
The user could simply write a lookup table to correct the misaligned key wiring
In this test program there is already a lookup table that can be enable/disabled with #Define LED_KEY ( creates Butn_Map1 = "" in script)
In the TM1638_OEM_lib it will be #Define Butn_Map1 or #Define Butn_Map2.
If undefined a user can create their own button re-map table if desired.
Edit:
Update GCB file 2022-09-21
(see file for details)
No, you don't need to.
I just updated the test file as I was finding things that were not right.
I was interested in anyone with some different boards to test, but as the new lib has a flexible setup (& easy default) they hopefully will ask for help on the forum if their board does not work..
Thanks for your testing & advise.
The new TM1638_OEM lib is ready now for review.
On the subject of the CDF output, I get a different structure from what you posted.
There is mostly symbols not used in my program & I don't see the conditional logic.
I click the make hex button in the IDE, G+Stool calls batch file(s)
I have tried various permutations...
conditionaldebugfile = "sourcefilename".gcb "sourcefileame".gcb
conditionaldebugfile = Test_TM1638_2Buttons.gcb,
make hex with other source file & don't change name in .ini etc
It always produces the .CDF in the source folder & with current compiled file name so that is ok
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello to all GCbasic users out there.
I need a bit of help to test the buttons (& specific displays)
Attached is a .GCB test program to read TM1638 Keys & display Button Number
or Raw hex data. (4 bytes)
I have tested 2 module boards I have:
"LED&KEY" - This one is Common Cathode display with non sequential wired button switches
"QYF-TM1638" -This one is Common Anode display with sequentially wired button switches & digit com pins are wired reverse.
If you get a garbled display or out of order buttons, try another configuration constant by enabling another #define in the Configuration. (only 1 can be enabled)
If none work then enable #Define NEW_BRD1, & edit the Script block IF DEF(NEW_BRD1) by un-commenting relevant line.
If you get out of order buttons with or without Butn_Map1 active in script, change mode to display raw key values, enable this line #Define Raw_Key,
Refer attached "TM1638 Buttons Table.pdf" & then edit table Butn_Map2 in the .GCB code.
Looking at a schematic of a board "LED--KEY" is shows sequentially wired buttons, so this one should be display = Com_Cathode , Button re-map = inactive, RevDig = inactive.
Any result of testing will be much appreciated.
It is quite likely some "Identical looking" boards may be wired different.
Toni
Brilliant!
I tested with my LED&KEY board -worked in a few seconds on a LGT board!
Result:
When static (no buttons pressed) Eight 0s.
Push any single button - a value of the button is shown on right hand LED = ranges from 1 to 8 returning to 0 when the button is released
See attached LGT code.
If it works on an LGT it will work on an AVR!
Last edit: Anobium 2022-09-14
The CDF for the program Test_TM1638_Buttons.gcb
The CDF can really help developers understand where and when constants are created and used.
Shows this relative to this program
A set of constants in the Test_TM1638_Buttons.gcb
lots of other constants, then two constants added from the script
Then, all the conditioanl logic and the assiocated code blocks that 'will be' processed. Showing the line numbers and the tests. The #ENDIFs are not shown. And, noting that #ELSE (if used) is shown as inverse test ( #IF > #IF NOT, IFDEF > IFNDEF etc).
I have updated the test code to enable Multiple key press, a value greater than 24 will be result.
Only the boards with diodes on the key lines will work (so not the QYF- board)
Not all combination will work due to the LED multiplexing.??
The actual return value of a multi key press is (obviously) dependent on the wiring order between switches & TM1638 so could vary between different boards.
The "LED&KEY" board has misaligned key wiring ( K3 & KS not sequential).
An OEM board should align switch button numbers to K1->K3 & KS1->KS8. eg.K1_KS1=butn1
File in a later post. - Test_TM1638_2Buttons.gcb
Last edit: ToniG 2022-09-24
The "LED&KEY" board with misaligned key wiring works. ;-)
The user could simply write a lookup table to correct the misaligned key wiring ? Or, is it the case that pressing more than one key will yield results that may be Zero? ( S1&S5;S2&S6;S8&S4;S7&S3 )
Please disregard the previous "Test_TM1638_Buttons.gcb", there are 2 issues with 2 buttons code.
I only have 1 board that will do multi button press test. LED&KEY (17-24 key codes)
1. The method was flawed, same value could result with different combination of low key values.
2. My assumption "...due to the LED multiplexing.??" was incorrect, actually was due to 2 key bits in the same byte.
I have modified to new file "Test_TM1638_2Buttons.gcb"
It has 2 bytes. ButnVal for 1 key & ButnVal2 for 2nd key.
User can test for non-zero value in ButnVal2.
Lower button number is always ButnVal.
This could be useful for a shift function.
I can put it in TM1638_OEM_lib
(I hope someone can find any issues)
Edit:
In this test program there is already a lookup table that can be enable/disabled with #Define LED_KEY ( creates Butn_Map1 = "" in script)
In the TM1638_OEM_lib it will be #Define Butn_Map1 or #Define Butn_Map2.
If undefined a user can create their own button re-map table if desired.
Edit:
Update GCB file 2022-09-21
(see file for details)
Last edit: ToniG 2022-09-24
My display looks
___00_00then then display represents the key pressed ___0n_0n`The results make sense and the program makes a lot of sense also.
Test on UNO with LED&KEY. Results look good.
Should I test again?
No, you don't need to.
I just updated the test file as I was finding things that were not right.
I was interested in anyone with some different boards to test, but as the new lib has a flexible setup (& easy default) they hopefully will ask for help on the forum if their board does not work..
Thanks for your testing & advise.
The new TM1638_OEM lib is ready now for review.
On the subject of the CDF output, I get a different structure from what you posted.
There is mostly symbols not used in my program & I don't see the conditional logic.
I can see the static constants, and the scripts. So, we know the report is handing the constants plus the 100's of others.
What is the entry in your use.ini? And, are you using the IDE(s) to execute the compiler (as you need to pass use.ini as the parameter)?
I click the make hex button in the IDE, G+Stool calls batch file(s)
I have tried various permutations...
conditionaldebugfile = "sourcefilename".gcb "sourcefileame".gcb
conditionaldebugfile = Test_TM1638_2Buttons.gcb,
make hex with other source file & don't change name in .ini etc
It always produces the .CDF in the source folder & with current compiled file name so that is ok
conditionaldebugfile = Test_TM1638_2Button.gcbwith no quotes works. Generates a CDF with the conditional statements at CDF lines 810 - endDisplay...