I am using MSP430F5418 with IAR EW 5.10.
I am trying to output the RTCCLK signal from MSP's 29th pin with a frequency of 1Hz.
When I output the signal it is coming through the port.
But after I re-writing the RTC time, the signal stopped.
I tried to re-enable it, but it didn't worked.
Can anybody tell me what the reason is??
I am using the Work-around code provided by TI for setting RTC time.
My RTC configuration is:
RTCCTL01 |= RTCHOLD;
RTCCTL01 |= RTCMODE + RTCTEV_0 + RTCRDYIE + RTCTEVIE;
P2DIR |= BIT4; P2SEL |= BIT4;
RTCCTL23 = RTCCALF1 | RTCCAL0;
RTCCTL01 &= ~(RTCHOLD);
The RTC Calibration depends on the output of Pre-scalar timer
Related
I have several ATMEGA328 based custom boards: I recently found that the standard Arduino bootloader does not handle watchdog timeouts correctly (it keeps resetting, so the device is effectively bricked until the next power cycle) so I am switching to the Optiboot bootloader.
I want to add something to my app that tells me whether the bootloader is Arduino or Optiboot. As Optiboot is a lot smaller, the reset vector is different, so printing that out would be a good indication.
Serial.println (pgm_read_word_near(0), HEX);
The above line of code prints out 940C, and I was expecting something like 7E00. How can I print out the address from the reset vector?
The actual address of the start of the boot flash section is determined by the BOOTSZ fuses.
This reads the size of the bootloader for classic ATmega:
uint32_t bootloaderSize;
cli();
uint8_t highBits = boot_lock_fuse_bits_get(GET_HIGH_FUSE_BITS);
sei();
if (!(highBits & bit(FUSE_BOOTRST))) {
uint8_t v = (highBits & ((~FUSE_BOOTSZ1 ) + (~FUSE_BOOTSZ0 )));
bootloaderSize = MIN_BOOTSZ << ((v >> 1) ^ 3);
}
use #include <avr/boot.h>
i have a PIC32MX460F512L. I am setting up a UART communication with raspberry Pi 3. And i made also some tests with mi PC Windows serial terminal (Putty, Teraterm etc.). I am having stucking problems, because the raspberry sends and receives only rubbish. Then i tested it with putty on Windows and i noticed strange things. For example the uart baud rate on the board is set as 9600, and to send and receive data on windows i have to set putty's baud rate to 130 !! Then i had a look to my PCLK settings on pic and it seems like everything is correct since there is an external clk oscillator of 8MHz. I post the code below .
PIC CODE:
#define GetSystemClock() (80000000ul) // Hz
#define GetInstructionClock() (GetSystemClock()/1)
#define GetPeripheralClock() (GetInstructionClock()/1) //
long Baud_Rate;
Baud_Rate = 9600;
TRISFbits.TRISF8 = 0; // Set UART1TX like output
TRISFbits.TRISF2 = 1; // Set UART1RX like input
U1MODE = 0x00008000;
U1STA = 0x00001400; // RXEN set, TXEN set
U1BRG = ((USART_Clock_Source)/(Baud_Rate/16))-1;
May it be a fault on the external oscillator or maybe is there an error on the baud rate calculation? I cannot understand.
Here is an error:
U1BRG = ((USART_Clock_Source)/(Baud_Rate/16))-1;
it should be:
U1BRG = ((USART_Clock_Source)/(Baud_Rate*16))-1;
And this:
#define GetSystemClock() (80000000ul) // Hz
should be
#define GetSystemClock() (8000000ul) // Hz
In this calculation is 8 MHz the instruction frequency not the clock frequency. The instruction frequency is half of the clock.
I am trying to write a simple integer value from an Arduino Mega 2560 to a Qt Application. Baudrate is set to 9600 and Serial.read() works fine when I send data through an open port with serial->write(some_data); from Qt Application.
digitalWrite(SS, LOW);
if (Serial.available() == 2) {
response1 = SPI.transfer(Serial.read());
response2 = SPI.transfer(Serial.read());
}
digitalWrite(SS, HIGH);
The above code works fine. I read another by before and had to add delay(3) to make this work. Now I want to send back the response
Serial.print((response2 << 8 ) | (response1 & 0xFF));
But there are always truncated digits. I know from the logic analyzer that the response is e.g. 8193 so with QByteArray b = serial->readAll(); I get results like 8, 81, 819, and sometimes 8193. I.e.: always the last digits are truncated randomly. I assume that this is also a timing issue but I could not find a fix for this.
Just in case anyone facing the same issue: Changing the Baudrate from 9600 to 112500 fixed this.
I am trying to drive a 6v dc motor with L293D driver and Atmega8 without PWM. The problem is i am getting very low speed while connecting the motor with L293D driver. But, it rotates well when i provide direct 6V dc supply to the motor. I am using external 6v source at V2(motor supply) pin of L293D, but no improvement. The motor does not rotate until i turn the rotor with hand. Is the problem remaining for not using PWM? My code is here:
DDRB = 0xFF;
while(1)
{
PORTB = 0B00000010;
_delay_ms(20000);
}
i think may be you forgot to make Enable 1 pin high, if your connections is like this than
PB0 --> IN1
Penter code hereenter code here`B1 --> IN2
PB3 --> EN1
and pin 8 of L293d will connected with External Battery.
than code like this :
DDRB = 0xFF;
while(1) {
PORTB = 0B00000110;
_delay_ms(20000);
}
I have my embedded linux box with 2 serial ports application, which tests all serial ports with wrap cable (only Rx connected to Tx, no other pins).
The second (non-console) port works fine.
The first (console) port sometimes works, but sometimes does inexplainable things.
To test the first channel I kill running 'getty' before opening it. The respawn is also forbidden.
Then I do the following:
system("killall getty");
Sleep(1000);
if ((fd = open(Name, O_RDWR | O_NOCTTY | O_NONBLOCK)) <= 0)
MsgFatal("Serial '%s' open error %d.", Name, errno);
BRN = B115200;
tcgetattr(fd, &Opts);
cfsetispeed(&Opts, BRN);
cfsetospeed(&Opts, BRN);
cfmakeraw(&Opts);
Opts.c_cflag |= PARENB;
Opts.c_cflag |= PARODD;
Opts.c_cflag &= ~CSTOPB;
Opts.c_cflag &= ~CRTSCTS; /* no HW flow control */
Opts.c_cflag |= CLOCAL | CREAD;
tcsetattr(fd,TCSANOW,&Opts));
After this, SOMETIMES (I mean on some run of the application) the next write operation blocks!
Any advice will be highly appreciated.
First off, the death of a getty process should immediately be reaped by its parent, either init or an aspect of BusyBox, and relaunched. How long it takes can vary, but it is usually pretty quick. But that shouldn't affect writing to the port.
How do you know the write is blocking? Please show that code.