AVR's RX-TX communication issues (USB-Serial-TTL)

Go To Last Post
32 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dear all,

It looks like I'm in trouble and need assistance.

The AVR (ATmega-644p) on my desk is connected through TTL>>RS-232 bidirectional adapter to a D_tech USB>>Serial/RS-232 cable to my PC where I use my IDE and other programs to work with AVR. Since many months it has worked just fine. I never had any issues receiving or transmitting bits of data. Since today, its not functioning anymore. 

 

  So far, I have tried  : - checked in devmgmt.msc for driver issues, no issues.

                                    - changed to another USB>>Serial Cable , same results.

                                    - tried with new AVR MCU, same results.

                                    - I flashed a simple program into AVR which echoes the typed characters back to my PC, does not work.

                                    - if I short the RX-TX at the end of the RS-232>>TTL converter and then type in terminal, in this case it echoes back, if I connect back to AVR and try the same, nothing happens.

                                    - while connected to AVR, if I wave with my hand very close to RS-232>>TTL converter, I see some garbage in terminal. It send garbage if my hand is very close to that adapter, if I remove my hand it stops.

Using avrdude in Windows Console shows that the AVR is initialized and ready to accept instructions. So at least I know that AVR is running properly. I can without any issues program it back and forth.

Right now I have no idea what else should I try to find out whats wrong.

I hope that someone here come across to such a issue.

 

Dave

 

 

This topic has a solution.

program is working......

Last Edited: Fri. Nov 9, 2018 - 10:30 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That cable is a USB to something converter/  How do you know its TTL in the DSUB connector and not actual RS232.  If its actual RS232 you could be damaging the USART port on the AVR.

 

Post a link to the cable.

 

JIm

 

EDIT:  Should have looked at the pictures a little better.  Flip the 232/ttl converter board over so we have an idea what it is.  It could be the converter is damaged  You could test it doing a simple Loopback and a terminal program

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

Last Edited: Thu. Nov 8, 2018 - 12:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The usual way to diagnose RS232/UART issues is to recognize the fact that at any "termination point" along the system you can disconnect the ongoing connection and simply loopback Tx to Rx then send some characters and see if they come back (make sure you aren't just seeing "Local echo"!)

 

So plug the USb into the PC then connect pins 2/3 in the 9 pin connector then try using a terminal to send some characters to the COM port - do they echo back? Does the echo stop if you remove the pin 2-3 link? If yes then the data is getting that far. So next connect the MAX232 and do the same with a connection from its output Tx pin to its input Rx pin. Again do the characters make it through that? Keep working your way along the line until you finally arrive at the UART of the AVR. If possible use a scope to text the RXD pin - is that seeing the inbound traffic? If it is then does the bit timing look right - the other reason RS232/UART connections fail is when the timing of some part of the system has been inadvertently changed.

 

BTW this is 2018 - why would you be using RS232 anyway? Surely you just use a USB-TTL cable plugged into the PC and the TX/RX pins from that direct to the RX/TX pins of the AVR?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Although looping RX to TX may work ok, you can still be missing a common ground connection and fail to work to the AVR, as each signal needs a working return via the ground connection.

Check each of the jumper wires from the RS232/TTL adapter to the AVR.

 

And as cliff mentioned, simplify your life with a USB - TTL cable.

Jim

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

so far I have tried what was proposed above.

 

1. connected the USB cable to my PC, then connected pin 2 to pin 3 on DSUB of the same cable and used terminal, typed characters showed up back in terminal. When pin2 disconnected from pin3, it stopped the traffic in terminal.

2. Next step attached the MAX232 to the end of the same cable, powered-up max, did the same for pin Tx-Rx on MAX, again the terminal echoed back the types characters.

 

Now the AVR , Scope probe is attached to Rx on AVR, and I something but not sure what it is.

 

The Scope imaging results for the AVR Rx pin

---------------------------------------------------------

 

 

The Scope imaging results for the AVR Tx pin

---------------------------------------------------------

 

 

can't really distinguish if there any data transmission is taking place, unless buried deep under this noise or something.

 

by the way, went to shop bought the USB-TTL cable for 15 euro, !^_^! ca,e back connected and it is also not working. AGrrrrrr.....

 

 

David

 

 

 

 

program is working......

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Post a link to the cable.

 http://www.shopmadeinchina.com/p...

 

program is working......

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The image for the MCU Rx input shows that only bit edges are getting "through". This usually means (1) damaged circuit or (2) bad connection. Many would call this "AC coupled" as it is missing the low frequency part of the signal.

 

There are a couple of things to look for:

 

(1) What ground point did you use for the scope? Was it ground on the MCU board or ground on the converter board?

 

(2) What was the point you connected the probe to? Rx input on the MCU board or signal output on the converter board?

 

(3) Do you have DC continuity (meter check) for both the Rx wire and the ground wire, all the way from the converter to the MCU?

 

There is more to check but what you try depends, somewhat on how these three questions are answered.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hold on a minute - there have to be TWO MAX232 in this !! You can't possibly have:

 

Because if it was like this you would have blasted the AVR with -12V. If there are to be RS232 level converters involved there have to be TWO of them:

 

This is why in 2018 people actually do this:

The days of (two) MAX232 and +/-12V are long gone unless that bit between the two MAX232 is something like 50ft of cable, which is when use of RS232 level voltages would be justified.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(1) answer = scope ground clip was attached to the ground rail on the breadboard where the AVR itself is plugged.  FYI the power to the AVR and hole circuitry comes from ISP programmer which is attached to my PC as the hole USb cable and everything else.

 

(2) answer= RX pin hole on the breadboard where the AVR is plugged.

 

 (3)answer=? you mean circuit continuity? surprise

 

 

program is working......

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

forgot to mention, it happened often that due to this terminal stuff, my PC crashes and restarts many times. Can it be related to something here.

program is working......

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i went to shop purchased the cable which is the last one in the drawing, and it still shows the same bad results as with all other suitable cables.

program is working......

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just to be clear, the TX pin of the adapter connects to the RX pin of the AVR and

the TX pin of the AVR connects to the RX pin of the adapter, and

the ground pins of both the AVR and adapter are connected, and the adapter is powered (ie. it has vcc connected as well).

 

Jim

 

Note: I have seen some adapters mark the RXD pin as TX, and vise versa.....   A link to the adapter would help us verify the connections.

 

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The scope set to 20mV is going to show noise. 1V a div is more sensible. The common problem is rx and tx swapped. You can measure this with a multimeter. For ttl level, both should show 3V or greater, for rs232 both should show a negative voltage of a few volts.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

See my posting in: https://www.avrfreaks.net/forum/...

 

Jim

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But if you already blasted the AVR with +/-12V you have probably terminally damaged the AVR

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

new updates on current situation.

 

I measured voltages at the end of the wire, Rx = 4.6 Volt, Tx = 0.29 Volt and changes from time to time.

When I connect to Rx and Tx on AVR and connect scope, it shows  that some data transmission occurs. But in Terminal is garbage.

So after looking at the thread from #14 I think using 2X speed is highly needed.

 

I have this code, but I really have no experience with preprocessor stuff. So The 2X speed is defined in this code, But i don't know what should I do to make it complied instead of regular speed. I am using make files and avrdude.

 

#include <avr/io.h>
#include "USART.h"
#include <util/setbaud.h>

void initUSART(void) {                                /* requires BAUD */
  UBRR0H = UBRRH_VALUE;                        /* defined in setbaud.h */
  UBRR0L = UBRRL_VALUE;
#if USE_2X
  UCSR0A |= (1 << U2X0);
#else
  UCSR0A &= ~(1 << U2X0);
#endif
                                             /* Enable USART transmitter/receiver */
  UCSR0B = (1 << TXEN0) | (1 << RXEN0);
  UCSR0C = (1 << UCSZ01) | (1 << UCSZ00);   /* 8 data bits, 1 stop bit */
}


void transmitByte(uint8_t data) {
                                     /* Wait for empty transmit buffer */
  loop_until_bit_is_set(UCSR0A, UDRE0);
  UDR0 = data;                                            /* send data */
}

uint8_t receiveByte(void) {
  loop_until_bit_is_set(UCSR0A, RXC0);       /* Wait for incoming data */
  return UDR0;                                /* return register value */
}

The Makefile which i mostly use for programming.....


##########------------------------------------------------------##########
##########              Project-specific Details                ##########
##########    Check these every time you start a new project    ##########
##########------------------------------------------------------##########

MCU   = atmega328p
F_CPU = 1000000UL
BAUD  = 9600UL
## Also try BAUD = 19200 or 38400 if you're feeling lucky.

## A directory for common include files and the simple 
USART library.
## If you move either the current folder or the Library folder, you'll
##  need to change this path to match.
LIBDIR = ../../AVR-Programming-Library

##########------------------------------------------------------##########
##########                 Programmer Defaults                  ##########
##########          Set up once, then forget about it           ##########
##########        (Can override.  See bottom of file.)          ##########
##########------------------------------------------------------##########

PROGRAMMER_TYPE = avrisp
# extra arguments to avrdude: baud rate, chip type, -F flag, etc.
PROGRAMMER_ARGS = -P com4 -b 19200

##########------------------------------------------------------##########
##########                  Program Locations                   ##########
##########     Won't need to change if they're in your PATH     ##########
##########------------------------------------------------------##########

CC = avr-gcc
OBJCOPY = avr-objcopy
OBJDUMP = avr-objdump
AVRSIZE = avr-size
AVRDUDE = avrdude

##########------------------------------------------------------##########
##########                   Makefile Magic!                    ##########
##########         Summary:                                     ##########
##########             We want a .hex file                      ##########
##########        Compile source files into .elf                ##########
##########        Convert .elf file into .hex                   ##########
##########        You shouldn't need to edit below.             ##########
##########------------------------------------------------------##########

## The name of your project (without the .c)
# TARGET = blinkLED
## Or name it automatically after the enclosing directory
TARGET = $(lastword $(subst /, ,$(CURDIR)))

# Object files: will find all .c/.h files in current directory
#  and in LIBDIR.  If you have any other (sub-)directories with code,
#  you can add them in to SOURCES below in the wildcard statement.
SOURCES=$(wildcard *.c $(LIBDIR)/*.c)
OBJECTS=$(SOURCES:.c=.o)
HEADERS=$(SOURCES:.c=.h)

## Compilation options, type man avr-gcc if you're curious.
CPPFLAGS = -DF_CPU=$(F_CPU) -DBAUD=$(BAUD) -I. -I$(LIBDIR)
CFLAGS = -Os -g -std=gnu99 -Wall
## Use short (8-bit) data types
CFLAGS += -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums
## Splits up object files per function
CFLAGS += -ffunction-sections -fdata-sections
LDFLAGS = -Wl,-Map,$(TARGET).map
## Optional, but often ends up with smaller code
LDFLAGS += -Wl,--gc-sections
## Relax shrinks code even more, but makes disassembly messy
## LDFLAGS += -Wl,--relax
## LDFLAGS += -Wl,-u,vfprintf -lprintf_flt -lm  ## for floating-point printf
## LDFLAGS += -Wl,-u,vfprintf -lprintf_min      ## for smaller printf
TARGET_ARCH = -mmcu=$(MCU)

## Explicit pattern rules:
##  To make .o files from .c files
%.o: %.c $(HEADERS) Makefile
	 $(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c -o $@ $<;

$(TARGET).elf: $(OBJECTS)
	$(CC) $(LDFLAGS) $(TARGET_ARCH) $^ $(LDLIBS) -o $@

%.hex: %.elf
	 $(OBJCOPY) -j .text -j .data -O ihex $< $@

%.eeprom: %.elf
	$(OBJCOPY) -j .eeprom --change-section-lma .eeprom=0 -O ihex $< $@

%.lst: %.elf
	$(OBJDUMP) -S $< > $@

## These targets don't have files named after them
.PHONY: all disassemble disasm eeprom size clean squeaky_clean flash fuses

all: $(TARGET).hex

debug:
	@echo
	@echo "Source files:"   $(SOURCES)
	@echo "MCU, F_CPU, BAUD:"  $(MCU), $(F_CPU), $(BAUD)
	@echo

# Optionally create listing file from .elf
# This creates approximate assembly-language equivalent of your code.
# Useful for debugging time-sensitive bits,
# or making sure the compiler does what you want.
disassemble: $(TARGET).lst

disasm: disassemble

# Optionally show how big the resulting program is
size:  $(TARGET).elf
	$(AVRSIZE) -C --mcu=$(MCU) $(TARGET).elf

clean:
	rm -f $(TARGET).elf $(TARGET).hex $(TARGET).obj \
	$(TARGET).o $(TARGET).d $(TARGET).eep $(TARGET).lst \
	$(TARGET).lss $(TARGET).sym $(TARGET).map $(TARGET)~ \
	$(TARGET).eeprom

squeaky_clean:
	rm -f *.elf *.hex *.obj *.o *.d *.eep *.lst *.lss *.sym *.map *~ *.eeprom

##########------------------------------------------------------##########
##########              Programmer-specific details             ##########
##########           Flashing code to AVR using avrdude         ##########
##########------------------------------------------------------##########

flash: $(TARGET).hex
	$(AVRDUDE) -c $(PROGRAMMER_TYPE) -p $(MCU) $(PROGRAMMER_ARGS) -U flash:w:$<

## An alias
program: flash

flash_eeprom: $(TARGET).eeprom
	$(AVRDUDE) -c $(PROGRAMMER_TYPE) -p $(MCU) $(PROGRAMMER_ARGS) -U eeprom:w:$<

avrdude_terminal:
	$(AVRDUDE) -c $(PROGRAMMER_TYPE) -p $(MCU) $(PROGRAMMER_ARGS) -nt

## If you've got multiple programmers that you use,
## you can define them here so that it's easy to switch.
## To invoke, use something like `make flash_arduinoISP`
flash_usbtiny: PROGRAMMER_TYPE = usbtiny
flash_usbtiny: PROGRAMMER_ARGS =  # USBTiny works with no further arguments
flash_usbtiny: flash

flash_usbasp: PROGRAMMER_TYPE = usbasp
flash_usbasp: PROGRAMMER_ARGS =  # USBasp works with no further arguments
flash_usbasp: flash

flash_arduinoISP: PROGRAMMER_TYPE = avrisp
flash_arduinoISP: PROGRAMMER_ARGS = -b 19200 -P /dev/ttyACM0
## (for windows) flash_arduinoISP: PROGRAMMER_ARGS = -b 19200 -P com5
flash_arduinoISP: flash

flash_109: PROGRAMMER_TYPE = avr109
flash_109: PROGRAMMER_ARGS = -b 9600 -P /dev/ttyUSB0
flash_109: flash

##########------------------------------------------------------##########
##########       Fuse settings and suitable defaults            ##########
##########------------------------------------------------------##########

## Mega 48, 88, 168, 328 default values
LFUSE = 0x62
HFUSE = 0xdf
EFUSE = 0x00

## Generic
FUSE_STRING = -U lfuse:w:$(LFUSE):m -U hfuse:w:$(HFUSE):m -U efuse:w:$(EFUSE):m

fuses:
	$(AVRDUDE) -c $(PROGRAMMER_TYPE) -p $(MCU) \
	           $(PROGRAMMER_ARGS) $(FUSE_STRING)
show_fuses:
	$(AVRDUDE) -c $(PROGRAMMER_TYPE) -p $(MCU) $(PROGRAMMER_ARGS) -nv -U
## Called with no extra definitions, sets to defaults
set_default_fuses:  FUSE_STRING = -U lfuse:w:$(LFUSE):m -U hfuse:w:$(HFUSE):m -U efuse:w:$(EFUSE):m
set_default_fuses:  fuses

## Set the fuse byte for full-speed mode
## Note: can also be set in firmware for modern chips
set_fast_fuse: LFUSE = 0xE2
set_fast_fuse: FUSE_STRING = -U lfuse:w:$(LFUSE):m
set_fast_fuse: fuses

## Set the EESAVE fuse byte to preserve EEPROM across flashes
set_eeprom_save_fuse: HFUSE = 0xD7
set_eeprom_save_fuse: FUSE_STRING = -U hfuse:w:$(HFUSE):m
set_eeprom_save_fuse: fuses

## Clear the EESAVE fuse byte
clear_eeprom_save_fuse: FUSE_STRING = -U hfuse:w:$(HFUSE):m
clear_eeprom_save_fuse: fuses

 

program is working......

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
F_CPU = 1000000UL
BAUD  = 9600UL

An illegal combination:

 

 

Anything greater than abs(2%) in this table will not work. 9600@1MHz is -7.0% so definitely will not work.

 

If your goal here is to work with the UART why on Earth are you running the AVR at 1MHz anyway?

 

(U2X will get it to 0.2% so that will work but, really, running the AVr at a sensible speed is the answer)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I get your point. So what would be then sensible speed?, taking into consideration two points.

 

1. The maximum UART throughput

2. The CPU clock speed without external Crytal.

 

 F_CPU = 8000000UL

 BAUD = 115200UL      would this be a better option?

 

 

program is working......

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well for UART take a look at this:

 

Notice anything "interesting" here (and some later frequencies too like 11.0592MHz, 14.7456MHz etc) ?

 

Yup for all the common baud rates they are all 0.0%

 

So you might wonder why the datasheet includes these alongside the more obvious 1mHz / 2MHz / 4MHz / etc ? Well they are all multiples of 300Hz. That fact means that for all the common baud rates (300, 600, 1200, 2400, 4800, 9600 ...) the integer UBRR value you calculate and use is an exact integer divisor of the crystal frequency so the baud rates are "spot on", no error whatsoever.

 

In commercial applications (including your PC in the old days!) then these "odd" frequencies were always used to ensure that all common baud rates had 0.0% error. That' as true today for AVR as it was then for PC etc. So if you have an application that is going to make use of UART then if you want it accurate you spend $0.10 to buy one of these crystal frequencies (all readily available) and two capacitors to hang on each leg.

 

So if you had been planning to run your AVR at 8MHz (say) then you pick the "magic crystal" that is closest - so 7.3728MHz and so on. For 16MHz you might instead choose 14.7456MHz.

 

If you are going to stick to the internal oscillator then perhaps consider 8MHz but you might want to then look at using OSCCAL to derate this to 7.3728

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

finally it started to work. Can't believe that I spent 4 days on this. So it looks like F_CPU = 8000000UL and BAUD = 9600UL works. Would be nice to-get hands on method that calculate those numbers. 

laugh

 

program is working......

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dave_Zeb. wrote:
Would be nice to-get hands on method that calculate those numbers. 
It's all in the datasheet for your mega644P:

 

 

Those formulae tell you how to calculate UBRR for a given F_CPU and BAUD. Assuming no U2X then UBRR = (F_CPU/(16 * BAUD)) - 1. So slot in your numbers and you get UBRR = (8000000 / (16 * 9600)) - 1. So that is (8000000 / 153600) - 1. That comes out as UBRR = 52.083333 - 1. So UBRR = 51.083333 and then you hit a bit of a problem. Because UBRR is an integer register, it doesn't do .08333 fractions. So the best you can achieve is setting just 51. 

 

Then there is a second equation to work out what the BAUD actually is for a given UBRR value. The equation is BAUD = F_CPU / (16 * (UBRR + 1)). So now work that backwards and BAUD = 8000000 / (16 * (51 + 1)). So BAUD = 8000000 / (16 * 52) in which case BAUD - 8000000 / 832 so BAUD = 9615.38. You asked for "9600" and you actually got 9615. So it's over by 15. Well 15/9600 is 0.00156 which is a 0.2% error. This is why the datasheet (that already did all these calculations for you for common F_CPU shows:

 

 

Above those tables it says:

 

I effectively just did the formula there by calculating both the "BaudRate" (desired) and "BaudRate-closestMatch"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

thanks a lot for this great explanation clawson. I need to change the approach of mine in reading the datasheets. Somehow I read through all above and missed everything what I could as usual.

 

 

 

 

 

 

program is working......

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PL2303HX can do 1Mbps> that's " The maximum UART throughput" you can get at 8 MHz F_CPU (2x setting). At 16 MHz  2Mbps is OK.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

at the moment UART speed is at 9600bps at F_CPU = 8 MHz, if I change it to a value from 9600 to 38400 bps from the table #21, it doesn't work although the table shows error of 0.2%.  Looks like only 9600 works at 8.0Mhz.

 

program is working......

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dave_Zeb. wrote:
F_CPU = 8 MHz, if I change it to a value from 9600 to 38400 bps from the table #21, it doesn't work

 

Are you still using the internal RC osc?   What happens if you use a xtal?

 

Jim

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

there is something interesting actually. I have changed the speed to 57600bps with F_CPU = 8MHz. Meanwhile in Terminal Program on PC , have to put wrong baud rate for the data stream to work, 56000bps. So even tho the baud in makefile is set to 57600bps in Terminal software I must choose 56000 in order to be able to see the data. If I put correct baud rate which is 57600 it does not work. All that with internal OSC. 

program is working......

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dave_Zeb. wrote:
there is something interesting actually.

Not interesting at all given the inaccuracy of the R/C osc.  No surprise here as attested by the hundreds of similar threads here about this very issue, all were solved with a xtal.

You told the compiler your F_CPU is 8MHz and all calculations it does for baud rate are based on that, but the R/C osc is not 8MHz, but some unknown rate slower than that.  

All of this is easily fixed with a xtal and two caps and a fuse setting,  or by adjusting the OSCCAL value to bring the R/C osc to 8MHz, at least for the current VCC level and temperature.

 

Jim

 

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

or by adjusting the OSCCAL value to bring the R/C osc to 8MHz, at least for the current VCC level and temperature

how can I adjust the internal OSC?-

program is working......

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Look at the table in #21 again. 57600 on 8MHz is shown as -3.5% which means it will be slow. In fact it will be reduced by 0.035 * 57600 so it will be 2016 lower. That means it will be 55,584 so, yes, if you set 56,000 rather than 57,600 you would be much closer.

As said previously the error has to be less than abs(2%). A -3.5% error means it almost certainly won't work right.

 

If you reduced UBBR by 1 then it would be 7 and the baud rate would be  8000000 / (16 * 8) = 62,500 baud - so that doesn't help much.

 

As I suggested above, for a more "subtle" adjustment look at using OSCCAL to change the 8MHz. If 57600@8MHz is -3.5% then you want to increase the 8MHz by 3.5% so 8.28MHz. There will very likely be some value of OSCCAL that will bring the 8MHz up to somewhere close to that.

 

One way is simply to do (conceptually) something like:

for (int i=0; i < 255; i++) {
    OSCCAL = i;
    printf("Hello %d\n", i);
}

There will probably be about 10 to 15 values of OSCCAL that make that come out right so after a lot of initial noise you will likely see:

?ell& 16#
h£l@o ~67
hello 168
hello 169
...
hello 174
h!llo 175
h:@~o ^76
...

Pick the value "in the middle" (maybe 170 or something) then in your code later just do:

int main(void) {
    OSCCAL = 170;
    // rest of program
}

Now when this runs it will uprate the internal oscillator from 8MHz to 8.28MHz (roughly) and 57600 will work accurately.

 

But, seriously, for UART work spend the entire ten cents!!

Last Edited: Fri. Nov 9, 2018 - 03:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One way is to run the range of possible values for the OSCCAL register in a loop while printing to the terminal "/n/rHello world, OSCCAL value is: %d", oscal_value

 

This will print garbage, until....

Eventually it will hit a printable range of values, choose a value in the middle of those shown, and use that in your program, now you know your close to 8MHz.

 

Frankly, I would just use a xtal and get on with developing my project....  

 

Good luck,

Jim

 

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SNAP!! cheeky

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
But, seriously, for UART work spend the entire ten cents!!

Still, no matter what speed your USART, and how far off, there is no way that that can cause

Dave_Zeb. wrote:
it happened often that due to this terminal stuff, my PC crashes and restarts many times.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.