Hello, the inhabitants of this forum. Maybe you read my topic about the problem with 2561, duck here, she did not dare ... the manor does not work. Help please find the simplest code to send something to the serial port (without using the standard library)) Generally, the simplest code is to send one or two digits to the serial port to just make sure that with the standard library all is well and the joint is somewhere else
code "the most simple usart"
In datasphere there is such an example.
#define FOSC 1843200// Clock Speed #define BAUD 9600 #define (MYUBRR FOSC/16/BAUD-1) void main( void ) {... USART_Init ( MYUBRR ); ...} // main void USART_Init( unsigned int ubrr){ /* Set baud rate */ UBRRH = (unsigned char)(ubrr>>8); UBRRL = (unsigned char)ubrr; /* Enable receiver and transmitter */ UCSRB = (1<<RXEN)|(1<<TXEN); /* Set frame format: 8data, 2stop bit */ UCSRC = (1<<USBS)|(3<<UCSZ0); } // USART_Init
void USART_Transmit( unsigned char data ) { /* Wait for empty transmit buffer */ while ( !( UCSRnA & (1<<UDREn)) ) ; /* Put data into buffer, sends the data */ UDRn = data; }
Will this be enough to make your estate work? Unless I would translate this code into the code arduino.
If you want people to refer to another thread, then give a link to it:
https://www.avrfreaks.net/forum/2561-serial
To find all the documentation & resources for a chip, go to the Product Page:
https://www.microchip.com/wwwproducts/en/ATmega2560 - easily found by putting the part number into google
then look on the 'Documents' tab - there you will find the Datasheet, and a list of all the Application Notes.
The Datasheet, in the USART section, contains simple examples - in both 'C' and assembler.
The example on p207 must be the simplest possible example - it just send a single character.
Other Application Notes to look at:
AN_1451 - AVR306: Using the AVR UART in C on tinyAVR and megaAVR devices
AN_2547 - AVR244: UART as ANSI Terminal Interface
You should also pay attention to:
AN2519 - AVR Microcontroller Hardware Design Considerations
Yes, that is the simplest code to transmit a single byte.
Yes, that is the simplest code to transmit a single byte.
Also there is an error here:
#define (MYUBRR FOSC/16/BAUD-1)
The opening parenthesis is in the wrong place. Should be:
#define MYUBRR (FOSC/16/BAUD-1)
(though there are some that might suggest <util/setbaud.h> depending on which compiler is being used).
Oh and in :
/* Set baud rate */ UBRRH = (unsigned char)(ubrr>>8); UBRRL = (unsigned char)ubrr;
there's an implicit cast to uint8_t (unsigned char) anyway as the targets are uint8_t. So this would be fine:
/* Set baud rate */ UBRRH = ubrr >> 8; UBRRL = ubrr;
This is wrong:
/* Wait for empty transmit buffer */ while ( !( UCSRnA & (1<<UDREn)) ) ; /* Put data into buffer, sends the data */ UDRn = data;
"n" is a placeholder. The 2561 has multiple UART so n should be replaced with 0 or 1 or whatever. Something like:
/* Wait for empty transmit buffer */ while ( !( UCSR1A & (1 << UDRE1)) ) ; /* Put data into buffer, sends the data */ UDR1 = data;
and similarly back in:
UBRRH = (unsigned char)(ubrr>>8); UBRRL = (unsigned char)ubrr; /* Enable receiver and transmitter */ UCSRB = (1<<RXEN)|(1<<TXEN); /* Set frame format: 8data, 2stop bit */ UCSRC = (1<<USBS)|(3<<UCSZ0);
if this is a 2561 all that should be:
UBRR0H = (unsigned char)(ubrr>>8); UBRR0L = (unsigned char)ubrr; /* Enable receiver and transmitter */ UCSR0B = (1 << RXEN0)|(1 << TXEN0); /* Set frame format: 8data, 2stop bit */ UCSR0C = (1 << USBS0)|(3 << UCSZ0);
(actually I just typed that from memory - you need to look up what the symbols are actually called).
The code in #2 seems to be copied direct from the Datasheet examples.
Yes, the datasheet has the error with the #define !!
Clearly, they didn't actually test that code!
This is why I would actually use the articles in the Tutorial Forum or perhaps Atmel's application notes as a starting point and not the datasheet.
...it would be easier to simply take the 8N1 default and forget the write to UCSRC
I thought that best practice was to assume nothing and always set registers how you want them? "|=" anyone?
#define MYUBRR (FOSC/16/BAUD-1) #define FOSC 1843200 #define BAUD 9600 void setup() { UBRRH = ubrr >> 8; UBRRL = ubrr; UCSR0B = (1 << RXEN0) | (1 << TXEN0); UCSR0C = (1 << USBS0) | (3 << UCSZ0); } void loop() { while ( !( UCSR1A & (1 << UDRE1)) ) ; UDR1 = data; }
oh my God ... that is, there are mistakes even in datashits ... how to understand a man who does not speak English well and everything else has not been engaged in angrily programming)) a nightmare ... ... from your post I realized that to me you need to write the following
sketch_apr12a:5: error: 'UBRRH' was not declared in this scope UBRRH = ubrr >> 8; ^ sketch_apr12a:5: error: 'ubrr' was not declared in this scope UBRRH = ubrr >> 8; ^ sketch_apr12a:6: error: 'UBRRL' was not declared in this scope UBRRL = ubrr; ^ sketch_apr12a:7: error: expected primary-expression before '|' token UCSR0B = | (1 << RXEN0) | (1 << TXEN0); ^ sketch_apr12a:8: error: expected primary-expression before '|' token UCSR0C = | (1 << USBS0) | (3 << UCSZ0); ^ sketch_apr12a:8: error: 'UCSZ0' was not declared in this scope UCSR0C = | (1 << USBS0) | (3 << UCSZ0); ^ C:\Users\Nikolai\Documents\Arduino\sketch_apr12a\sketch_apr12a.ino: In function 'void loop()': sketch_apr12a:14: error: 'data' was not declared in this scope UDR1 = data; ^ exit status 1 'UBRRH' was not declared in this scope
This is why I would actually use ... Atmel's application notes as a starting point and not the datasheet.
But, if we can't trust Atmel to get the datasheet right, how can we trust them to get the App Notes any better?
datashits
@UNikolai please don't keep quoting entire posts - it just clogs the thread and makes it hard to read.
just pick out the bits you're specifically referring to.
Or use the 'Reply' button if it's a general reply to an entire post - the forum automatically fills-in which post it relates to.
I'll keep it on mind. And what of the code that I wrote, why arduino gives an error?
You have several types of error, the simplest one is that you did not declare the ubrr and data variables.
You have several types of error, the simplest one is that you did not declare the ubrr and data variables.
You have several types of error
Actually, it seems to be just one type of error: it is a basic requirement of the C and C++ programming languages that things must be declared before they are used.
If you use something before there has been any declaration of it, then you will get an error:
error: 'UBRRH' was not declared in this scope
You seem to be getting this for all your peripheral register names: UBRRH, UBRRL, UCSR0B, UCSR0C , etc.
So either you are using the wrong names, or your sketch is not properly configured to provide those names.
You are also getting the same errors for ubrr, and data - these are your variables - so you need to declare them!
This is basic C/C++ language stuff - nothing specific to Arduino or AVR or Atmel.
But in the example they are also not declared
The examples are clearly not complete programs!
And they also tell you to read the section, "About Code Examples" - did you do that?
It says,
These code examples assume that the part specific header file is included before compilation.
I don't do Arduino, so I don't know how that happens in Arduino - presumably it's own of the things it tries to be "helpful" by hiding from you?
Presumably, you have to tell it what chip you're using when you set up your "Sketch" ?
The datasheet example for transmit does define the 'data' variable - it is parameter to the function:
void USART_Transmit( unsigned char data ) { /* Wait for empty transmit buffer */ while ( !( UCSRnA & (1<<UDREn)) ) ; /* Put data into buffer, sends the data */ UDRn = data; }
Similarly for ubrr:
void USART_Init( unsigned int ubrr) { /* Set baud rate */ UBRRH = (unsigned char)(ubrr>>8); UBRRL = (unsigned char)ubrr; /* Enable receiver and transmitter */ UCSRB = (1<<RXEN)|(1<<TXEN); /* Set frame format: 8data, 2stop bit */ UCSRC = (1<<USBS)|(3<<UCSZ0); } // USART_Init
mples are clearly not complete programs!
#define MYUBRR (FOSC/16/BAUD-1) #define FOSC 1843200 #define BAUD 9600 unsigned char data = 1; unsigned int ubrr; void setup() { UBRRH = ubrr >> 8; UBRRL = ubrr; UCSR0B = (1 << RXEN0) | (1 << TXEN0); UCSR0C = (1 << USBS0) | (3 << UCSZ0); } void loop() { while ( !( UCSR1A & (1 << UDRE1)) ) ; UDR1 = data; }
sketch_apr12a:8: error: 'UBRRH' was not declared in this scope UBRRH = ubrr >> 8; ^ sketch_apr12a:9: error: 'UBRRL' was not declared in this scope UBRRL = ubrr; ^ sketch_apr12a:11: error: 'UCSZ0' was not declared in this scope UCSR0C = (1 << USBS0) | (3 << UCSZ0); ^ exit status 1 'UBRRH' was not declared in this scope
And now here such error. And in fact there is such register like as in the microcontroller (UBRRH)
Go on. I am sure that there is an Arduino "core" for the ATmega2561.
If not, most of the code for a MEGA2560 is going to work on the smaller 2561.
If you are using Arduino, you just use the Serial class. Exactly the same as any other Arduino.
Yes, you can write directly to the USART if you want. Note that the Arduino is already set up for interrupt-driven code with the Serial class. So make sure to disable the USART interrupts for your code.
If you are writing directly to AVR registers, you must read the datasheet like anyone else. Especially when the datasheet refers to UBRRnH you need to use the specific UBBR0H, UBRR1H, UBRR2H, ...
David.
in fact there is such register like as in the microcontroller (UBRRH)
That's irrelevant.
The C or C++ compiler can't read datasheets!
So you have to suitably declare these within your source code: as already explained, if there is no declaration, then you will get that error!
As the datasheet said, this is normally done by #include-ing the appropriate header file - but this is something that Arduino hides from you.
EDIT: for convenience, the header file usually follows the same names as the datasheet - but there is no compulsion for it to do so.
Also pay attention to what David said.
UNikolai wrote:
datashits
+1
A translation error? or editorial?
Go on. I am sure that there is an Arduino "core" for the ATmega2561.
If not, most of the code for a MEGA2560 is going to work on the smaller 2561.
If you are using Arduino, you just use the Serial class. Exactly the same as any other Arduino.
Yes, you can write directly to the USART if you want. Note that the Arduino is already set up for interrupt-driven code with the Serial class. So make sure to disable the USART interrupts for your code.
If you are writing directly to AVR registers, you must read the datasheet like anyone else. Especially when the datasheet refers to UBRRnH you need to use the specific UBBR0H, UBRR1H, UBRR2H, ...
David.
@UNikolai please don't keep quoting entire posts - it just clogs the thread and makes it hard to read.
just pick out the bits you're specifically referring to.
Or use the 'Reply' button if it's a general reply to an entire post - the forum automatically fills-in which post it relates to.
Here is an example of how to quote "selectively":
when the datasheet refers to UBRRnH you need to use the specific UBBR0H, UBRR1H, UBRR2H,
So do that, and see if it fixes your errors.
Yes, there is a kernel. But unfortunately does not work yusart for some reason ...
If there is a problem in the Arduino (or 3rd-party) Core, then you need to take that up with Arduino (or the 3rd party)
However, the errors you're showing here are plain programming errors on your part - so try again with the proper UBRRnH names ...
EDIT
Fix quote attribution
EDIT 2
add "3rd party" - see #24
I do not have a 2561. And I generally like to stick with genuine Arduino boards. Then everyone in the world can run the same code on known Arduino boards.
There are several third-party cores available e.g. for Tiny85 or Mega2561.
These cores are not officially supported by the Arduino team.
If you want to add direct hardware-access code to your project, you must consider any side effects on the existing Arduino code.
For example. Timers are already set up for PWM by the Arduino init() code. USART0 is already set up for Serial class.
You must initialise every Timer or USART register before you use Timer or USART for yourself. Use = and not |= in assignments.
Seriously. You can write your own polled USART functions. And use them in your program. Cliff gave you examples.
However, if you are using an "Arduino", why not stick to the proven Serial class ?
Write Arduino sketches that work on Uno, Mega, Zero, ... by just using the official methods e.g. Serial.begin(), digitalWrite(), ...
David.
There are several third-party cores available e.g. for Tiny85 or Mega2561.These cores are not officially supported by the Arduino team.
I didn't know that - #23 updated accordingly
If you want to add direct hardware-access code to your project, you must consider any side effects on the existing Arduino code.
And you must have a proper understanding of how the hardware works, and how to do the access in the C++ programming language.
if you are using an "Arduino", why not stick to the proven Serial class ?
+1
Write Arduino sketches that work on Uno, Mega, Zero, ... by just using the official methods e.g. Serial.begin(), digitalWrite(), ...
+1
#define MYUBRR (FOSC/16/BAUD-1) #define FOSC 1843200 #define BAUD 9600 unsigned char data = 1; unsigned int ubrr; void setup() { UBRR0H = ubrr >> 8; UBRR0L = ubrr; UCSR0B = (1 << RXEN0) | (1 << TXEN0); UCSR0C = (1 << USBS0) | (3 << UCSZ00); } void loop() { while ( !( UCSR1A & (1 << UDRE1)) ) ; UDR1 = data; }
Here it is already compiled, but what variable ubbr should be?
but this standard serial port is not working ... I'm looking for a reason. So then I generally need this only to debug a sketch, and in the final version of this will not be
what variable ubbr should be?
I think you mean, "what value should the variable ubbr have?"
Look at the code: it is the value that will be loaded into the UBBR register
Is he missing the #include <avr/io.h> header? Is that the reason why the ubbr is unknown?
Jim
He's doing Arduino - so shouldn't that be done for him?
In #26 he says it is now compiling.
Anyhow, surely <avr/io.h> only defines the registers - not user variables like ubbr ?
Your code initialised USART0 and then wrote to USART1
Try this:
#define MYUBRR (FOSC/16/BAUD-1) //#define FOSC 1843200 #define FOSC F_CPU //Arduino code "knows" the correct CPU frequency #define BAUD 9600 char uart_putchar(char c) { while ( !( UCSR0A & (1 << UDRE0)) ) ; UDR0 = c; } void uart_putstring(char *s) { char c; while (c = *s++) { uart_putchar(c); } } void setup() { UBRR0H = MYUBRR >> 8; UBRR0L = MYUBRR; UCSR0B = (1 << RXEN0) | (1 << TXEN0); UCSR0C = (1 << USBS0) | (3 << UCSZ00); } void loop() { uart_putstring("David Prentice"); uart_putchar('\n'); //newline delay(5000); }
But you could also try this regular Arduino code:
void setup() { // put your setup code here, to run once: Serial.begin(9600); } void loop() { // put your main code here, to run repeatedly: Serial.println("David Prentice"); delay(5000); }
If your "Arduino" board is configured wrong, you might need to force 1843200 if that is your correct clock frequency.
David.
In the first example in #31 a mix of arduino and C is used. It takes more than 600b flash.
I would prefer to write either pure arduino or pure C code.
Arduino sketch in C:
#include <avr/io.h> #include <util/delay.h> #define MYUBRR (FOSC/16/BAUD-1) //#define FOSC 1843200 #define FOSC F_CPU //Arduino code "knows" the correct CPU frequency #define BAUD 9600 char uart_putchar(char c) { while ( !( UCSR0A & (1 << UDRE0)) ) ; UDR0 = c; } void uart_putstring(char *s) { char c; while (c = *s++) { uart_putchar(c); } } void setup() { UBRR0H = MYUBRR >> 8; UBRR0L = MYUBRR; UCSR0B = (1 << RXEN0) | (1 << TXEN0); UCSR0C = (1 << USBS0) | (3 << UCSZ00); } int main() { setup(); uart_putstring("David Prentice"); uart_putchar('\n'); //newline _delay_ms(5000); }
takes only 256 bytes of flash.
I guess this is not so simple after all...................
JIm
I guess this is not so simple after all...................frown
You have to put Uber from #32 under the FOSC and BAUD definitions:
//#define FOSC 1843200 #define FOSC F_CPU //Arduino code "knows" the correct CPU frequency #define BAUD 9600 #define MYUBRR (FOSC/16/BAUD-1)
Well, some people just work way too hard...
JC
'Simple USART Comm's Test 'File: SUCT V1.bas $regfile = "m328pdef.dat" 'Specify the uC $crystal = 16000000 'uC Clock MHz $hwstack = 64 'Hardware Stack $swstack = 64 'Software Stack $framesize = 64 'Frame Space $Baud = 19200 'Baud Rate Main: do Print "Testing 1, 2, 3" waitms 1000 loop
My 2 cents:
You have to put Uber from #32 under the FOSC and BAUD definitions:
Surprisingly the compiler does not care about the order of #defs.
I have tested in real with arduino board.
@Visovian,
You do not need to worry about basic system include files if built as a INO file.
You do not need to worry about forward declarations if built as a INO file.
The Arduino Build processes INO into CPP file. It adds "Arduino.h" and adds any forward declarations.
If you save the source file as C or CPP, it is your responsibility to include system file like avr/io.h
Your example does not use a loop(). So it only prints "David Prentice" once.
I would not worry whether an executable is 600 bytes or 250 bytes in a 256kB MCU.
I would choose whether to write straight C, C++ or to take advantage of the Arduino INO processing.
The C preprocessor does worry about what it "knows" at the time of expansion.
MYUBBR is only evaluated after it knows the MYUBRR define and the BAUD, FOSC defines.
I removed any global variables like ubrr and data. They serve no purpose.
@docJC,
The Arduino code is the simplest of all. But the Basic is simpler than the C code.
In practice, the m2561 has got plenty of Flash memory.
David.
C:\Users\Nikolai\Documents\Arduino\sketch_apr12a\sketch_apr12a.ino:2:0: warning: "FOSC" redefined #define FOSC F_CPU //Arduino code "knows" the correct CPU frequency ^ C:\Users\Nikolai\Documents\Arduino\sketch_apr12a\sketch_apr12a.ino:1:0: note: this is the location of the previous definition #define FOSC 1843200 ^ C:\Users\Nikolai\Documents\Arduino\sketch_apr12a\sketch_apr12a.ino: In function 'char uart_putchar(char)': C:\Users\Nikolai\Documents\Arduino\sketch_apr12a\sketch_apr12a.ino:13:1: warning: no return statement in function returning non-void [-Wreturn-type] } ^ C:\Users\Nikolai\Documents\Arduino\sketch_apr12a\sketch_apr12a.ino: In function 'void uart_putstring(char*)': C:\Users\Nikolai\Documents\Arduino\sketch_apr12a\sketch_apr12a.ino:18:18: warning: suggest parentheses around assignment used as truth value [-Wparentheses] while (c = *s++) { ^ C:\Users\Nikolai\Documents\Arduino\sketch_apr12a\sketch_apr12a.ino: In function 'int main()': C:\Users\Nikolai\Documents\Arduino\sketch_apr12a\sketch_apr12a.ino:33:36: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] uart_putstring("David Prentice"); ^ Compiling libraries... Compiling core... Using precompiled core Linking everything together... "C:\Users\Nikolai\Desktop\arduino-1.8.5-windows\arduino-1.8.5\hardware\tools\avr/bin/avr-gcc" -Wall -Os -Wl,--gc-sections -mmcu=atmega2561 -o "C:\Users\Nikolai\AppData\Local\Temp\arduino_build_869229/sketch_apr12a.ino.elf" "C:\Users\Nikolai\AppData\Local\Temp\arduino_build_869229\sketch\sketch_apr12a.ino.cpp.o" "C:\Users\Nikolai\AppData\Local\Temp\arduino_build_869229/..\arduino_cache_490980\core\core_MegaCore-master_avr_2561_BOD_1v8,LTO_Os,clock_8MHz_internal_789f896693846094e303cbac6561f2a9.a" "-LC:\Users\Nikolai\AppData\Local\Temp\arduino_build_869229" -lm "C:\Users\Nikolai\Desktop\arduino-1.8.5-windows\arduino-1.8.5\hardware\tools\avr/bin/avr-objcopy" -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 "C:\Users\Nikolai\AppData\Local\Temp\arduino_build_869229/sketch_apr12a.ino.elf" "C:\Users\Nikolai\AppData\Local\Temp\arduino_build_869229/sketch_apr12a.ino.eep" "C:\Users\Nikolai\Desktop\arduino-1.8.5-windows\arduino-1.8.5\hardware\tools\avr/bin/avr-objcopy" -O ihex -R .eeprom "C:\Users\Nikolai\AppData\Local\Temp\arduino_build_869229/sketch_apr12a.ino.elf" "C:\Users\Nikolai\AppData\Local\Temp\arduino_build_869229/sketch_apr12a.ino.hex" Скетч использует 382 байт (0%) памяти устройства. Всего доступно 261120 байт. Глобальные переменные используют 16 байт (0%) динамической памяти, оставляя 8176 байт для локальных переменных. Максимум: 8192 байт. C:\Users\Nikolai\Desktop\arduino-1.8.5-windows\arduino-1.8.5\hardware\tools\avr/bin/avrdude -CC:\Users\Nikolai\Desktop\arduino-1.8.5-windows\arduino-1.8.5\hardware\MegaCore-master\avr/avrdude.conf -v -patmega2561 -cusbasp -Pusb -Uflash:w:C:\Users\Nikolai\AppData\Local\Temp\arduino_build_869229/sketch_apr12a.ino.hex:i avrdude: Version 6.3, compiled on Jan 17 2017 at 12:00:53 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ Copyright (c) 2007-2014 Joerg Wunsch System wide configuration file is "C:\Users\Nikolai\Desktop\arduino-1.8.5-windows\arduino-1.8.5\hardware\MegaCore-master\avr/avrdude.conf" Using Port : usb Using Programmer : usbasp AVR Part : ATmega2561 Chip Erase delay : 9000 us PAGEL : PD7 BS2 : PA0 RESET disposition : dedicated RETRY pulse : SCK serial program mode : yes parallel program mode : yes Timeout : 200 StabDelay : 100 CmdexeDelay : 25 SyncLoops : 32 ByteDelay : 0 PollIndex : 3 PollValue : 0x53 Memory Detail : Block Poll Page Polled Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- eeprom 65 10 8 0 no 4096 8 0 9000 9000 0x00 0x00 flash 65 10 256 0 yes 262144 256 1024 4500 4500 0x00 0x00 lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00 signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00 Programmer Type : usbasp Description : USBasp, http://www.fischl.de/usbasp/ avrdude: auto set sck period (because given equals null) avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.02s avrdude: Device signature = 0x1e9803 (probably m2561) avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: auto set sck period (because given equals null) avrdude: reading input file "C:\Users\Nikolai\AppData\Local\Temp\arduino_build_869229/sketch_apr12a.ino.hex" avrdude: writing flash (382 bytes): Writing | ################################################## | 100% 3.99s avrdude: 382 bytes of flash written avrdude: verifying flash memory against C:\Users\Nikolai\AppData\Local\Temp\arduino_build_869229/sketch_apr12a.ino.hex: avrdude: load data flash data from input file C:\Users\Nikolai\AppData\Local\Temp\arduino_build_869229/sketch_apr12a.ino.hex: avrdude: input file C:\Users\Nikolai\AppData\Local\Temp\arduino_build_869229/sketch_apr12a.ino.hex contains 382 bytes avrdude: reading on-chip flash data: Reading | ################################################## | 100% 2.47s avrdude: verifying ... avrdude: 382 bytes of flash verified avrdude done. Thank you.
as you wrote)) thanks for the help) but that's what writes arduin in response to this sketch. Tomorrow I am soldering the new board, there will be all capacitors in place, I will also use external quartz to definitely exclude all variants of the "wrong printed circuit board"
I apologize for the fuzzy photo, but in general everything is visble. And unfortunately, nothing works at all. Even the elementary light-emitting diode will not be able to blink ... on any of the ports. I xs what's up. It's somehow wildly sad
n this case sketches are loaded, fyuzes are read and written. Tried to light the LEDs and standard blink, as well as ddrd portd
Wouldn't life be easier if you simply got an Arduino? If you really need that many IO and that much flash get a "Mega".
Arduino boards just let you get on and design stuff without worrying about dodgy hardware.
That would be my advice too. Develop software on the Arduino MEGA2560. Final tests of the completed software on your 2561 target hardware.
.
The 2561 is just a 2560 with missing ports i.e. to fit in TQFP-64 package instead of TQFP-100.
.
David.
no, it does not work out, I have very strict limitations on the size of the case and its shape.
Maybe it's worth it ... I think it would be easier ... but that's only one thing we have about $ 10 ... not that I'm sorry, it's just that something can not happen again ...
Our advice was for "project development" in a pleasant environment. Size does not matter. Convenience of using Serial, JTAG, ... is more important.
Of course your final hardware will be made on a small pcb.
David.
From the "fuzzy photo" it seems that many of the pins near the crystal are shorting out.
Also I can see VCC being routed to the top half of the chip but not GND.
I apologize for the fuzzy photo
Go on. You managed to get it in-focus in your previous thread:
https://www.avrfreaks.net/commen...
So try again until you get it.
Also, either get a good "square-on" shot, or add some other angles - so that we can clearly see everything.
Remember: this is the only way we get to see what hardware you have - so it's up to you to give us a good view!
Also, please post the schematic.
Maybe even the bare board layout.
Again, the better the info you provide, the more likely it is that you will get good replies.
I have nothing and is not confined anywhere
Well, that's better - but:
it seems that many of the pins near the crystal are shorting out.
I still can't see that clearly due to the angle of the photo - but it does seem to be the case.
That's why I asked for some other angles!
If you're not going to post the photos, then you're just going to have to inspect it yourself - and confirm that there are not shorts.
And what about the schematic?
But you see everything there. And the components are signed
But you see everything there.
But not clearly.
Again, it looks like you have solder bridges between pins 29 & 30 and 31 & 32 - but the photo is not clear enough to tell for sure.
Due to the angle, it looks like nearly all the pins on the 49-64 side could be shorted.
And the components are signed
The legends on your layout are hard to read - due to both the colour and being too crammed together - and make it hard to see the detail of the tracks.
So you have
#define FOSC 1843200// Clock Speed
Whats frequency is your crystal???
it's a matter of days gone by, now the problems are completely different
I marked the (possible) solder bridges (short-circuits). They are in the top right corner of the chip.
Admittedly it looks less like a solder splash in this view:
Maybe just flux or something? But it should be cleaned.
it's a matter of days gone by, now the problems are completely different
Sorry for butting in with wrong assumptions.
it's a matter of days gone by, now the problems are completely different
So what crystal frequency do you have you code configured for now, then?
But it should be cleaned.
Indeed.
@UNikolai - again: the better the information you provide, the better your chance of getting good help!
Well, really, you really think that I would not have noticed this
On this board does not work, even a simple blink, what really there to say about yusart. Although the sketches are loaded
It has been noted several times, and you have not said anything about it.
So it seems that you had not noticed it.
Again, the only thing we have to go on is what you post here - so it's up to you to make sure that everything is clear, complete, and accurate
Well, duck and what can I say? The clock frequency? I tried also with an external crystal for 8 megahertz and with an internal chain and with a divider, but in this case it does not matter, because it does not even go out to light an LED
Do you have an oscilloscope - to see if the crystal is actually oscillating?
Do you have a debugger - to see what the code is actually doing?
Or an Xplained board with built-in debugger?
The ground trace used by the crystal and its caps should not be shared with anything else. Currently, your LED shares that trace. Indeed, with the PCB layout shown, >>all<< ground return current from all pins will pass through the same trace shared by the crystal's caps. This is ill-advised.
Although, if you say you can't get it to work with the internal RC oscillator either, then this isn't the root of your current problem.
Admittedly it looks less like a solder splash in this view:
Looks pretty obvious to me here:
That is some pretty thick flux residue for it to block out the sun.
Mind you, if they are indeed solder bridges, they only short PD4 to PD5, and PD6 to PD7. Not implicated in any of the code the OP has shown, but he has not shown his 'simple blink' code. If he's trying to toggle the LED on PD4, but has tied PD5 as an output low, then drive contention would likely keep the LED unlit.
I'd also like to know if the OP has confirmed that:
- the LED is undamaged and does in fact work, by applying an external voltage across it and it's series resistor.
- the LED has been installed with the correct polarity.
The OP only has one GND pin (pin 22) connected to PS return, all the other GND pins (53,63) are floating!
all the other GND pins (53,63) are floating!
Nope. See post the first image in post #48.
I'm just a bit mangler not a nuts and bolts man but what frequency are we expecting a crystal labeled "18 000" to be. Rather naively I would have thought that meant 18k or 18M? Does a 1.8432MHz crystal really have such markings?
It is an 18MHz xtal.
But UNikolai still hasn't confirmed that the code is properly configured for this ...
He has, however, said:
it's a matter of days gone by, now the problems are completely different
... and:
On this board does not work, even a simple blink
... and:
I tried also with an external crystal for 8 megahertz and with an internal chain and with a divider, but in this case it does not matter, because it does not even go out to light an LED
Andy, I'm talking about the very clear photo in #52. Difficult to read that as anything but "18 000"
.
EDIT or are you saying the leading character is T not 1? If there's a cross bar it's very faint. Trick of the light?
Ah OK. Damned mobile phones!
That's the one!
like the others, I did look at the more recent photo and that certainly does look like "18 000"
I assume they are both the same board - and OP hasn't actually got one board with 8MHz and another with 18MHz.
But I know where "assume" get get you ...
It's not solder, it's dirt, well, I'm not an absolute beginner in this business, I've been soldering and much more complicated things, I will not allow such an elementary mistake. I have a multimeter and it's not possible to install any pin at all (not just the one on which there is no LED)
The code is configured for this particular quartz, at 8 megahertz. This is just chosen in the settings. And yes, it's certainly a crystal for 8 megahertz
There is perhaps a small nuance, the two previous boards had a signatureavrdude: Device signature = 0x1e9803
avrdude: Expected signature for ATMEGA2561 is 1E 98 02while this 2561 has the correct signature ending at 3 (although the MK is from the same batch.) Tomorrow I will get a microcontroller 2561 from a trusted store, and I ordered these in China (and as a result, one local 2561 cost me like 5 Chinese ((() But I do not think that the Chinese 2561 are unoriginal ... the same 328 I ordered 20 pieces from them and everything is fine.I also want to clarify that the LED on the previous cards it turned out.
A thought or two,
Take a tooth brush and wash the board.
Your DMM reassures the DC resistance between two pins.
The Flux can have a high DC resistance and yet conduct the 16 MHz, etc., signals.
Probably not the issue, but still good to clean up the board.
Next, keep trying to read the Device Signature.
Until you can read the correct Device Signature, nothing else matters.
Finally,
Once the Signature can be reliably read, then hook up another LED and resistor on another I/O pin, (or two, or three, on different ports and pins).
Test the new LED and resistor combinations before you solder them in place.
You can connect them with some short jumper wires soldered to the pads, as you have connected the other wires.
Report back on your progress.
JC
Take a tooth brush and wash the board.
Fly Over Jim
On this board does not work, even a simple blink
So where are we, exactly?
The hardware looks basically OK. I find the GND and power traces to be a bit "skimpy", but I've seen working boards with similar.
It sounds like your program have uploaded successfully? So your program is able to talk to the chip enough to actually load code, which is pretty significant.
And you say that you've checked it pretty carefully for things like shorted pins, and it looks OK. We'll assume that the LED is mounted correctly? (have you checked the pin with a VOM or SCOPE during your blink test?)
The last software you posted showed FOSC set to 1843200, which doesn't match what showed up on the crystal in the photos of your board. And it seems a somewhat unlikely frequency for an AVR (should it have been 18.xx MHz instead 1.8xx?) But an LED blink should still do something (though you haven't shown us that code, or described exactly how it it doesn't work.)
the two previous boards
?? Do all the boards fail, or are you using SW that works on some but not others? Are we debugging HW or SW?
Next, keep trying to read the Device Signature.
but:
n this case sketches are loaded, fyuzes are read and written. Tried to light the LEDs and standard blink, as well as ddrd portd
It's not solder, it's dirt, well, I'm not an absolute beginner in this business, I've been soldering and much more complicated things, I will not allow such an elementary mistake. I have a multimeter and it's not possible to install any pin at all (not just the one on which there is no LED)
Well, sorry, I didn't want to offend you, but everybody does mistakes sometimes. You should just have said it was dirt the first time people started talking about solder bridges and put the matter to rest.
You should just have said it was dirt the first time people started talking about solder bridges and put the matter to rest.
Indeed - see #62 !
as I understood, the signature of the 2561 mod can be switched to 1,2 or 3
about the LEDs, I repeat, I have a multimeter, I can check the voltage on the port by running LEDs and I checked them all, no results
" I find the GND and power traces to be a bit "skimpy" what this means, do not quite understand. Are the paths too narrow?
"have you checked the pin with a VOM or SCOPE during your blink test?" you mean a multimeter or what are those abbreviations (abbreviations)
I have quartz at 8 MHz
The simplest code, in order to at least check the LED
void setup() { DDRD = 0b11111111; } void loop() { PORTD = 0b11111111; }
resentment? What are you talking about? in the very first photo you can see that it's mud. In postings 52 and 56 it is clear that this is dirt. And I do not understand how you might think that I can not help noticing the "soldered" pins ... I'm more than 3 years old, if that
Yes "skimpy" = too narrow
https://dictionary.cambridge.org/dictionary/english/skimpy
VOM = Volt (and) Ohm Meter.
yah. After all, 0.4 mm of the track is enough for the meager currents that pass there
Well, with a multimeter we are inseparable friends
remember that it's not just about the steady-state currents - there's also transients to consider ...
http://radioaktiv.ru/raschet-shi... 0.5 amperes is recommended 0.15 mm, and such currents I will never even be close
http://radioaktiv.ru/raschet-shi... 0.5 amperes is recommended 0.15 mm, and such currents I will never even be close
But this isn't about current causing your tracks to 'blow' like a fuse. This is about making a good solid ground and power connection so that your chip works properly. Tracks have resistance; thin tracks have a higher resistance than thick tracks. A current flowing through a resistor (ie thin track) will cause a voltage to develop along that track. Which means your "0V" connection at one point on the board can have a voltage difference from a different "0V" point elsewhere.
If you think it doesn't matter then why do you get PCBs with ground planes?
This is part of one of my boards. The green is my 0V connection. I have no current higher than 100mA flowing and yet I have made a huge 0V 'track'. Why? Because I want my products to work reliably.
In postings 52 and 56 it is clear that this is dirt.
but these were after the point was first raised (#48?)
and Cliff noted that in #56
but we can't tell what might be under the dirt, or if it is just an artefact of the photo.
So it may be clear to you, because you have the actual board in front o you and can look at it with your own eyes; but we don't have that, and can't do that - so we rely on you to state it clearly and explicitly.
Don't take it as an insult - just a straightforward request for information & clarification.
We have no idea that you are an experienced PCB maker.
EDIT
If it were a simple / obvious problem, it would surely been spotted by now - so we're having to eliminate all the more "unlikely" possibilities ...
Cute avatar ;-)
You've probably noticed that the forum software does a terrible job of reformatting animated gifs which have been 'optimised'. Here's the same animation you started with, but I've properly formatted in a 'safe' way for the forum software: