4x4 membrane keypad giving unexpected signals - arduino

I am working on a project where I try to code my own function for a membrane keypad. I want the 16 key states to be stored in a uint16_t variable, so I have only one variable. The code compiles.
The problem is that it will not properly display the key states. When I press the 1 key, it will tell me a lot more keys are being pressed. It will also display that keys are being pressed without touching the thing at all.
Pins 5-8 of the keypad are connected to PORTD, pin 4-7 on the Nano.
Pins 1-4 of the keypad are connected to PORTB, pin 0-3 on the Nano.
Keypad [PDF].
This is the code.
uint16_t keys = 0;
void setup() {
// put your setup code here, to run once:
DDRD |= 0xF0; //Set bit 4-7 as output on PORTD
DDRB &= 0xF0; //Set bit 0-3 as input on PORTB
Serial.begin(9600);
}
void loop() {
getKeys(&keys);
Serial.println("-----------------------");
delay(100);
}
void getKeys(uint16_t* keys){
*keys = 0; //Clear keys variable
for(int rows = 0; rows < 4; rows++){ //Loop through every row
PORTD &= 0x0F; //Turn pin 4-7 on PORTD off
PORTD |= (16 << rows); //Turn on pin.
Serial.print(String(PORTD) + String(" : ")); //Print current selected bit(row)
uint16_t temp = (PINB & 0x000F); //Take bit 0-3 from PORTB
Serial.println(temp, BIN); //Print the PINB values as binary
*keys |= (temp << (rows*4)); //Shift the PORTB values into keys.
}
}
This is the output in the Serial monitor.
16 : 0
32 : 0
64 : 0
128 : 0
-----------------------
16 : 0
32 : 0
64 : 0
128 : 1
-----------------------
16 : 0
32 : 0
64 : 0
128 : 11
-----------------------
16 : 0
32 : 1000
64 : 10
128 : 1111
-----------------------
16 : 1000
32 : 1110
64 : 1110
128 : 1111
-----------------------
16 : 1000
32 : 1110
64 : 1110
128 : 1111
-----------------------
16 : 0
32 : 0
64 : 0
128 : 0
-----------------------
16 : 0
32 : 0
64 : 0
128 : 0
-----------------------

When you have all keys unpressed, then you inputs are not connected to anything. They just are "floating in the air" and can receive any electrical disturbance from outside.
Keypad should work in other way.
On input pins (PINB) turn on pull-up resistors DDRB &= 0xF0; PORTB |= 0x0F. Then ALL you inputs now should read as logical 1, eg. 1111.
On output pins (PORTD) provide HIGH level (logical 1) to all rows, except the one, that you are going to measure (this should be LOW level - logical 0), e.g. 1110, 1101, 1011, 0111.
Then you can read pressed key as LOGICAL 0 on input pins (PINB). After that, you can invert the read number, if you need (bitwise NOT operator ~), e.g. temp = PINB; temp ~= temp; temp &= 0x0F or just temp = (~PINB) & 0x0F.
The same way you can use bitwise NOT opearator before output, e.g. PORTD = (~(16 << rows)) & 0x0F.
This way your inputs on PINB will always be connected to some source - to VCC (+5V) through pull-up resistors inside the AVR chip, or to GND, when you set logical 0 on output pins of PORTD. And you will not receive any electrical noise on them.

Related

PLL Voltage scalling STM32

I am working with the STM32F767 Nucleo board and currently, I trying to set the PLL as the system clock. While I have been able, thanks to an example generated by the CubeMX, I really don't understand why it must be done so. The setup is:
HSI = 16MHz
PLLM = 8
VCO_Input_Frequency = 16/8 = 2MHz
PLLN = 144
Frequency = 144*2 = 288MHz
PLLP = 6
PLL_Output_Frequency = 288/6 = 48MHz
PPRE1 = 2
APB1_Frequency = 24MHz
APB1_Frequency_Timer = 2*24MHz = 48MHz
The following line of code is what is buging me:
//Sets the voltage scaling mode to 3, VOS = 0x1 = b1
PWR->CR1 |= PWR_CR1_VOS_0;
a = PWR->CR1; //Small delay
When this line is commented the period is 19.7ms and when is active the period is 20ms, as expected. It is very strange, this is how the generated code from CubeMX does. It makes the voltage scaling to 1 (low performance). I don't understand how seting the voltage scaling equals to 1 makes the PLL works correctly.
Down below is the code that configure the PLL:
void sys_clock_init(void){
int a;
//Sets the wait states to 1
FLASH->ACR |= 0x01;
a = FLASH->ACR; //Small delay
//Enables the power interface (for the power controller)
RCC->APB1ENR |= RCC_APB1ENR_PWREN;
a = RCC->APB1ENR; //Small delay
//Clears the bits for the voltage scaling
PWR->CR1 &= ~(PWR_CR1_VOS);
//Sets the voltage scaling mode to 3, VOS = 0x1 = b1
PWR->CR1 |= PWR_CR1_VOS_0;
a = PWR->CR1; //Small delay
//Makes HSI the source of the PLL
RCC->PLLCFGR &= ~(0x400000);
//Clears the bits for the different factors
RCC->PLLCFGR &= ~(RCC_PLLCFGR_PLLM);
//Sets the PLLM = 0x08 = b100
RCC->PLLCFGR |= (RCC_PLLCFGR_PLLM_3);
//Clears the PLLN bits
RCC->PLLCFGR &= ~(RCC_PLLCFGR_PLLN);
//Sets PLLN = 0x90 = b10010000
RCC->PLLCFGR |=(RCC_PLLCFGR_PLLN_7 | RCC_PLLCFGR_PLLN_4);
//Clears the PLLP bits
RCC->PLLCFGR &= ~(RCC_PLLCFGR_PLLP);
//Sets the PLLP = 0x02 = b10
RCC->PLLCFGR |=(RCC_PLLCFGR_PLLP_1);.
//Clears the PPRE1 bits
RCC->CFGR &= ~(RCC_CFGR_PPRE1_2 | RCC_CFGR_PPRE1_1 | RCC_CFGR_PPRE1_0);
//Set bit PPRE1 = 0x02 = b100
RCC->CFGR |= (RCC_CFGR_PPRE1_2);// | RCC_CFGR_PPRE1_0);
//Turns the PLL ON
RCC->CR |= RCC_CR_PLLON;
//Waits for the PLL to be ready
while(!((RCC->CR & RCC_CR_PLLRDY) == RCC_CR_PLLRDY));
//Clears the switch bits
RCC->CFGR &= ~(RCC_CFGR_SW);
//Set the PLL as the System Clock
RCC->CFGR |= (RCC_CFGR_SW_1);}
I have also tested commenting the lines that sets VOS bits on the CubeMX code and the period is 19.75ms like mine.
This is my code to get that board to 16Mhz using the PLL and the external clock.
static int clock_init ( void )
{
unsigned int ra;
//switch to external clock.
ra=GET32(RCC_CR);
ra|=1<<16;
PUT32(RCC_CR,ra);
while(1) if(GET32(RCC_CR)&(1<<17)) break;
if(1)
{
ra=GET32(RCC_CFGR);
ra&=~3;
ra|=1;
PUT32(RCC_CFGR,ra);
while(1) if(((GET32(RCC_CFGR)>>2)&3)==1) break;
}
//HSE ready
//PLLM aim for 2mhz so 8/4=2
//PLLN input is 2, want >=100 and <=432 so between 50 and 216
//PLLP 16Mhz*8 = 128, 16MHz*6 = 96, not enough
//so PLLP is 8 VCO 128 so PLLN is 64
//don't really care about PLLQ but have to have something so 8
PUT32(RCC_PLLCFGR,0x20000000|(8<<24)|(1<<22)|(3<<16)|(64<<6)|(4<<0));
ra=GET32(RCC_CR);
ra|=1<<24;
PUT32(RCC_CR,ra);
while(1) if(GET32(RCC_CR)&(1<<25)) break;
ra=GET32(RCC_CFGR);
ra&=~3;
ra|=2;
PUT32(RCC_CFGR,ra);
while(1) if(((GET32(RCC_CFGR)>>2)&3)==2) break;
return(0);
}
PUT32/GET32 are abstraction functions to do str/ldr. I will try either 48 HSE or 48Mhz HSI, and post what I find.
static int clock_init ( void )
{
unsigned int ra;
//PLLM aim for 2mhx so 16/8 = 2;
//PLLN input is 2, want >=100 and <=432 so between 50 and 216
//PLLN = 144, VCO 288
//PLLP = 6, output 288/6 = 48MHz
//don't really care about PLLQ but have to have something so 6
PUT32(RCC_PLLCFGR,0x20000000|(6<<24)|(0<<22)|(2<<16)|(144<<6)|(8<<0));
ra=GET32(RCC_CR);
ra|=1<<24;
PUT32(RCC_CR,ra);
while(1) if(GET32(RCC_CR)&(1<<25)) break;
ra=GET32(RCC_CFGR);
ra&=~3;
ra|=2;
PUT32(RCC_CFGR,ra);
while(1) if(((GET32(RCC_CFGR)>>2)&3)==2) break;
return(0);
}
The uart works, but that is not saying much.
With the default of scale 1 I do see that a little fast. but if I use the 8MHz HSE then it looks better. I use systick to count 120 seconds. set systick to roll over every 1million counts then wait for 120 rollovers, compare to a stopwatch/timer.
Next using 16000000 in systick and counting 900 rollovers that should be 5 minutes and it is to within a second since comparing visually to a timer is only that accurate. Using HSE, scaling 1 (default)
Using HSI scaling 1 it is off by a few seconds to get 19.7ns though would be a lot of seconds and I don't see that many.
Now using HSI scaling 3:
static int clock_init ( void )
{
unsigned int ra;
ra=GET32(RCC_APB1ENR);
ra|=1<<28; //PWR enable
PUT32(RCC_APB1ENR,ra);
PUT32(FLASH_ACR,0x00000001);
PUT32(PWR_CR1,0x4000);
GET32(PWR_CR1);
//PLLM aim for 2mhx so 16/8 = 2;
//PLLN input is 2, want >=100 and <=432 so between 50 and 216
//PLLN = 144, VCO 288
//PLLP = 6, output 288/6 = 48MHz
//don't really care about PLLQ but have to have something so 6
PUT32(RCC_PLLCFGR,0x20000000|(6<<24)|(0<<22)|(2<<16)|(144<<6)|(8<<0));
ra=GET32(RCC_CR);
ra|=1<<24;
PUT32(RCC_CR,ra);
while(1) if(GET32(RCC_CR)&(1<<25)) break;
ra=GET32(RCC_CFGR);
ra&=~3;
ra|=2;
PUT32(RCC_CFGR,ra);
while(1) if(((GET32(RCC_CFGR)>>2)&3)==2) break;
return(0);
}
Does appear to be more accurate. 5 minutes measured as 5 minutes to the second. So it appears perhaps that the documentation isn't correct with respect to the accuracy of HSI (as there is this exception using default scaling).
48Mhz -> 20.83ns
20.62 - 21.04 with the documented error.
There is a reason for using external clocks. If you are interested in more accuracy since you have the NUCLEO board use the external clock HSE not the internal HSI.
Hmmm, actually 1% for the 16Mhz which is 3% when multiplied by 3 to get 48MHz. I think using the divisor in the PLL makes it worse, but I would have to ponder that some more.
20.21 to 21.46 is the range you should see at the calibration temperature, then vary from that based on die temp.

Reading/writing to EEPROM - incorrect values

I'm using the Arduino IDE to program a ESP8266 board.
The idea is to play a sound of a random frequency for a random amount of time, and save the last frequency played to the EEPROM. Then, I have a watchdog ISR that restarts the board if the delay time is 4 seconds or more. When this happens and the board restarts, I want to play the last played frequency for 1 second, and then resume normal functionality again.
Here is my code,
#include <Ticker.h>
#include <EEPROM.h>
#define PIN_BUZZER 13 // the digital pin the Buzzer is attached to
PROGMEM const int freqs[] = {31, 49, 78, 123, 196, 311, 494, 784, 1245, 1976, 3136,
4978};
Ticker secondTick;
volatile int watchdogCount = 0;
volatile int freqIdx = 0; //the index that will store the last frequency before it restarts
int EEPROM_Addr = 42;
//The Watchdog Interrupt Service Routine (ISR)
void ISRwatchdog() {
watchdogCount++;
//The watchdog will be waken up when the couter reaches 4
if (watchdogCount == 4) {
ESP.restart(); //restarting the board
}
}
void setup() {
EEPROM.begin(4096);
Serial.begin(115200);
secondTick.attach(1, ISRwatchdog); //registering the watchdog ISR
pinMode(PIN_BUZZER, OUTPUT);
int prevFreq = EEPROM.read(EEPROM_Addr); // read previous frequency
if (prevFreq != 255){
Serial.println("Previous frequency found : ");
Serial.println(prevFreq);
analogWrite(PIN_BUZZER, 256);
analogWriteFreq(prevFreq);
delay(1000);
}
}
void loop() {
Serial.print("Watchdog counter = ");
Serial.println(watchdogCount);
watchdogCount = 0;
int freq = freqs[random(0, 11)];
Serial.print("Frequency: ");
Serial.println(freq);
Serial.println("Saving to EEPROM");
EEPROM.write(EEPROM_Addr, freq);
EEPROM.commit();
// generating 50% PWM
analogWrite(PIN_BUZZER, 256);
analogWriteFreq(freq);
//depending on the value of delay, the program may wake up the watchdog
int delayTime = random(1, 5) * 1000;
Serial.print("Delay time: ");
Serial.println(delayTime);
delay(delayTime);
}
The problem I'm facing is that values are either written to the EEPROM incorrectly or they are being read incorrectly. For example, here is some of the output I got,
Watchdog counter = 2
Frequency: 31
Saving to EEPROM
Delay time: 3000
Watchdog counter = 3
Frequency: 1245
Saving to EEPROM
Delay time: 4000
ets Jan 8 2013,rst cause:2, boot mode:(3,0)
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v09f0c112
~ld
Previous frequency found :
221
The previous frequency in this case is incorrect.
And again in this output snippet,
Watchdog counter = 1
Frequency: 784
Saving to EEPROM
Delay time: 4000
Watchdog counter = 4
Frequency: 1976
Saving to EEPROM
Delay time: 1000
ets Jan 8 2013,rst cause:2, boot mode:(3,0)
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v09f0c112
~ld
Previous frequency found :
184
There are some cases where my output is correct, but that is rare.
The EEPROM library for ESP8266 only stores one byte. That means it cannot store values over 255 -- the value you get back is least significant byte of the value you stored (i.e, freq % 256).
Consider storing the index of the value in the array instead of the value itself, e.g.
uint8_t idx = random(0, 11);
int freq = freqs[idx];
...
EEPROM.write(EEPROM_addr, idx);
and
uint8_t idx = EEPROM.read(EEPROM_addr);
int freq = freqs[idx];

How can I get the serial number printed on RFID tag with RFID reader?

How can I get the serial number printed on an RFID tag through an RFID reader?
I have:
Arduino uno,
RMD 6300 reader, and
RFID tag (125Khz).
I use the following code:
#include <SoftwareSerial.h>
SoftwareSerial RFID(2, 3); // RX and TX
int i;
void setup()
{
RFID.begin(9600); // start serial to RFID reader
Serial.begin(9600); // start serial to PC
}
void loop()
{
if (RFID.available() > 0)
{
i = RFID.read();
Serial.print(i, DEC);
Serial.print(" ");
}
}
I get this value:
2 48 57 48 48 50 69 52 69 65 50 67 66 3
But the following value is printed on the RFID tag:
0003034786
I would want to have this number, but I don't know how to convert it.
The value that you currently get is the serial number encoded as US-ASCII string. The value in decimal (as you currently print it) is
2 48 57 48 48 50 69 52 69 65 50 67 66 3
Converting these bytes into hexadecimal form (for better readability) leads to:
02 30 39 30 30 32 45 34 45 41 32 43 42 03
Encoding these bytes in US-ASCII leads to this string:
<STX>09002E4EA2CB<ETX>
Note that you could also receive this form directly on your console by using
Serial.write(i);
instead of Serial.print(i, DEC);
Thus, your reader starts outputting the serial number by sending a start-of-transmission (STX) character (0x02) and ends sending the serial number with an end-of-transmission (ETX) character. Everything in between is the serial number (represented as hexadecimal characters):
09002E4EA2CB
The serial number printed on your key (0003034786) is only a fraction of the complete serial number. This value is the decimal representation. If you convert
0003034786
to its hexadecimal representation, you get
002E4EA2
This value is contained in the serial number that you received from the reader:
09002E4EA2CB
Therefore, you could do something like this to print the value (use sprintf(), if you need the leading zeros):
void loop() {
int serialNumber = 0;
int charIndex = 0;
int currentChar;
if (RFID.available() > 0) {
currentChar = RFID.read();
++charIndex;
if (currentChar == 0x002) {
charIndex = 0;
serialNumber = 0;
} else if (currentChar == 0x003) {
Serial.print(serialNumber, DEC);
Serial.print(" ");
} else {
if ((charIndex >= 1) && (charIndex < 5)) {
serialNumber <<= 8;
serialNumber += currentChar;
}
}
}
}

Arduino read input pin 1 to 6 (BIN to BCD) and show value on Arduino TFT display

How do I read pin 1-6 and show the value on Arduino TFT display. (BIN to BCD)
Ex: pin 5,4,3,2,1,0 all = 1 (111111) will show the value on display: 63
Ex: pin 5,4,3,2,1,0 (100000) will show the value on display: 32
Ex: pin 5,4,3,2,1,0 all = 0 (000000) will show the value on display: 00
Something along these lines:
int result = 0;
for (int i = 0; i < 6; i++)
if (digitalRead (i + 1) == HIGH)
result |= bit (i);
if (result < 10)
Serial.print ("0");
Serial.println (result);
That "ors" in each bit from pins 1 to 6. I used a Serial print there because you didn't give any indication what sort of TFT display you have*, but the principle will be the same.
* Other than being an Arduino one. :)

for loop acts abnormally in Arduino

Consider the following loop in C:
int i;
for (i = 1; i > 0; i++);
After i reaches INT_MAX, it will turn INT_MIN at increment. Then i > 0 evaluates
false, and the for loop will terminate.
However, the same for loop will not terminate in Arduino, since i > 0 compares false
even if i is -32768.
Why is that?
PS. I'm using a Mega 2560 with Arduino version 1.0.5.
PPS. int is indeed 16 bit on Mega 2560
PPPS. The complete sketch below:
void setup () {
int i;
Serial.begin(9600);
for (i = 1; i > 0; i++);
}
void loop () {
Serial.println(100);
}
And I won't see any thing in the Serial Monitor
Disassembling the setup function gives:
0000014a <setup>:
14a: 80 e3 ldi r24, 0x30 ; 48
14c: 94 e0 ldi r25, 0x04 ; 4
14e: 40 e8 ldi r20, 0x80 ; 128
150: 55 e2 ldi r21, 0x25 ; 37
152: 60 e0 ldi r22, 0x00 ; 0
154: 70 e0 ldi r23, 0x00 ; 0
156: 42 d2 rcall .+1156 ; 0x5dc <_ZN14HardwareSerial5beginEm>
158: ff cf rjmp .-2 ; 0x158 <setup+0xe>
so now it's clear: avr-gcc thinks the i > 0 in for(i = 1; i > 0; i++) will never evaluates false and optimised the exit condition away.
Most likely, 'int' is also 32-bit on Arduino. It takes time to complete 2^31 iterations. You may change 'int' to 'short' and it should terminate as expected.
when int is defined, by default, its size is assumed to be of 16 bit by compiler.
But when you increment it beyond 32767 i.e.
int i=32767;
i++;
The size of 'i' is automatically increased to 32 bit. This is because the size is not specified in the declaration.
This causes your program not to stop at 32767.
Hence if you want to stop the for loop at 32767,
you have to specifically declare it as
short int i;
If you want to verify this, you can try following
short int x;
for(x=1; x>0; x++)
{
mySerial.println(x);
}
AND
int x;
for(x=1; x>0; x++)
{
mySerial.println(x);
}

Resources