Any news or ideas on the topic? Just bought 324PB Xplained Pro and all of a sudden found out that I can't even compile for it.
Toolchain I have is 3.5.3, no mention of 324PB in headers and device specs. Release notes for the latest gcc toolchain (3.5.4) at
http://ww1.microchip.com/downloa...
list only 324A, P and PA
Is it the same with the Studio? I can't use it, just curious.
Thanks
PS
Not sure if this belongs here or in Compilers. Please, feel free to move.
all of a sudden found out that I can't even compile for it
Please explain that.
You mean you have previously been able to "compile for it", but now can't?
What, exactly, are you doing?
What, exactly, is happening?
Any error messages?
Sorry for not being perfectly clear. This is my first 324PB so I haven't been able to compile for it before.
Here is what happened:
avr-gcc -Wall -pedantic -O3 -pipe -mmcu=atmega324pb -DBLI_APP_VERSION=\"0.2\" -I. bli.c -c -o bli.o
avr-gcc: error: cannot access device-specs for 'atmega324pb'
Well, AS7 knows all about the ATmega324PB.
However there are a few changes in the header files compared to the ATmega324PA.
e.g. bit names in multiple peripherals like USART0, USART1 are now called RXC instead of RXC0, RXC1
and single peripheral SFR names like TWCR are now called TWCR0, TWCR1 because there are two TWI channels in the 324PB.
You will need to do a certain amount of conditional editing. e.g. #if ..324PB.. #define TWCR TWCR0
There have been similar name conflicts in the past. e.g. with RXC RXC0
The new system is more logical. i.e. single bit name because RXC0, RXC1 are both in the same position in UCSR0A and UCSR1A
David.
avr-gcc: error: cannot access device-specs for 'atmega324pb'
via
(page 8)
4. Supported Devices
P.S.
0-series megaAVR?
Some new megaAVR in the works.
gchapman,
Thanks, atpack worked. Do you know if avrdude part definition of 324pb can be derived from 324p by simply changing signature to 0x1e 0x95 0x17?
http://svn.savannah.gnu.org/viewvc/avrdude/trunk/avrdude/avrdude.conf.in?r1=1391&r2=1397
An assumption is like the change for mega328PB.http://svn.savannah.gnu.org/viewvc/avrdude/trunk/avrdude/avrdude.conf.in?r1=1391&r2=1397
That's what I did. I can flash the chip and change fuses.
However, Atmel's migration guide 324->324PB says `ATmega324PB is not a drop-in replacement for ATmega324 variants, but a new device.' So 324PB may require more profound changes. We'll see.
It works.
Someone can give me some instructions to do this on debian? I downloaded the patch and included it on avr-gcc command but did not work. I did the process below and didnt have results.
gchapman wrote:An assumption is like the change for mega328PB.http://svn.savannah.gnu.org/viewvc/avrdude/trunk/avrdude/avrdude.conf.in?r1=1391&r2=1397
That's what I did. I can flash the chip and change fuses.
However, Atmel's migration guide 324->324PB says `ATmega324PB is not a drop-in replacement for ATmega324 variants, but a new device.' So 324PB may require more profound changes. We'll see.
3.6.1 has made the home page (was 3.5.4) for macOS and Linux; Windows is still at 3.5.4 there :
Microchip Technology
'SAM(ARM) and AVR Toolchains (C Compiler)
http://www.microchip.com/avr-support/avr-and-arm-toolchains-(c-compilers)
source code and macOS build :
Atmel - Tools Distribution
http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/3.6.1/
Someone can give me some instructions to do this on debian?
mega324PB is not in the forthcoming AVRDUDE 6.4 avrdude .conf so patch it.
https://packages.debian.org/search?keywords=gcc-avr&searchon=names&suite=all§ion=all
http://svn.savannah.gnu.org/viewvc/avrdude/trunk/avrdude/avrdude.conf.in?revision=1422&view=markup
To patch it, I need to download and add the directory in the avr-gcc call? Just it? Because still not working for me...
I tried on Ubuntu and works fine, but on Debian still not working, any advice to solve this?
I did the patch download and modify avrdude.conf. Its work on Ubuntu but not in my Debian. It still dont recognize the atmega324pb. Looks like the avr-gcc is ignoring the path where is the patch...
... any advice to solve this?
This is a thread where someone had the same problem with a different uC. And I've posted additional information regarding the ATmega328PB (had the same problem a few weeks ago). I'm using Ubuntu by the way.
Max
Edit: Forgot the link: https://www.avrfreaks.net/forum/iom324pbh-not-latest-avr8-gnu-toolchain-linux?skey=theeye13
I admit I feel a bit lost.
I am using the ATmega324PB xplained pro board and I am constantly running into issues.
My experience with development environments is a bit rusty, to say the least.
The code example attached I have seen run on MPLAB X IDE in a youtube video yet I am having difficulty with following.
The compiler does not seem to like
void USART_Flush( void )
{
unsigned char dummy;
while ( UCSR0A & (1<<RXC) ) dummy = UDR0;
}
If I removed it and run without it compiles but when I open "Simple Serial Port Terminal" and try to send a text nothing returns.
it's a warning
You don't use dummy for anything. Either make it volatile or actually use it :)
when I open "Simple Serial Port Terminal" and try to send a text nothing returns.
The "terminal" in AS7 was an interns project that should have never been included with the suite, suggest you use a real terminal program!
So, two thing :)
I am not a super experienced....yet. I do see what you are saying about dummy. It was a copied example to clear the buffer. Apparently I did pay attention to the fact that it is going nowhere. ;)
In regards to the Terminal program. I tried YAT which I have used for quite a while but it does not return anything either.
It connects okay thought.
Is there another suggestion for clearing the rx buffer?
Is there another suggestion for clearing the rx buffer?
does it need clearing?
I usually have two functions for serial input:
//------RS232-------------------
unsigned char kbhit(void){
//return nonzero if char waiting polled version
unsigned char b;
b=0;
if(UCSRA & (1<<RXC)) b=1;
return b;
}
//-----------------------
int getchar(void){
//polled version...
unsigned char c;
while(!kbhit()){}; //wait for char
c=UDR; //get char from usart
return c;
}to clear the buffer, test for data using kbhit() and if true, then call getchar() and ignore the result, rinse and repeat if longer then one char buffer.
Just disable, and then re-enable the receiver...
23.3.2.4.2 Disabling the Receiver
When disabling the receiver, the operation is immediate. The receiver buffer will be flushed, and data from ongoing
receptions will be lost.
My program still is not working with a terminal??
I am not getting any compiler errors.
I am obviously communicating with the board as it programs okay.
It would be great with some help on that. Ideas, thoughts.
My program still is not working with a terminal??
How are you connecting the terminal program to the output of your AVR?
Are you sure you are connecting to the right COM port?
Common problems with serial comms:
1) cpu is not running at the clock speed you think it is, so the baud rate is also not what you think it is. (CLK/8 fuse is default so clock is 1/8 what you think it is)!
2) TX on AVR connects to RX on USB-ttl serial adapter, and RX on AVR connects to TX on USB-ttl serial adapter.
3) Using a USB to RS232 adapter, rather then a USB to ttl serial adapter.
4) Not having a common GND connection between AVR and USB-ttl adapter.
5) Using the internal RC osc (@ 1MHz) and trying to use 9600 baud! (error rate is TOO large, use 4800 baud), but best to use xtal with much better accuracy than the internal RC osc.
I'm sure there are more but see if that list will solve your issue.
Jim
does it need clearing?
Sometimes, with double-buffered (or deeper), it is nice to [say] clear the internal circular buffer and UART buffer(s).
Is there another suggestion for clearing the rx buffer?
If you want to clear the warning with a replacement line for dummy=UDR0; you can just use UDR0;
Thank you Jim
Sometimes, with double-buffered (or deeper), it is nice to [say] clear the internal circular buffer and UART buffer(s).
Hmm, I would just read what is in the buffer and let the input parser state machine discard if not needed.
Just disable, and then re-enable the receiver...
That could lose an incoming character, I would rather process what is in the buffer and discard if not needed.
If only I had an Oscilloscope.
You were right about the 1 M clk. I modified it but I am still not getting any USART action.
When I run in debug mode I can see all the registers being configured as i would expect but the RXC never go high nor do I see and action on UDR0.
You still haven't answered my questions back in #27.
The answer to your question is
The board I am using is a ATmega324PB Xplained Pro with a built-in EDBG Debugger which connects on COM8 virtual through USB.
My Terminal program YAT detects and connects via COM8.
Running in debugging mode I execute the code and watch the register values. They all change according to the program until it gets to the Receive while loop that is looking for a logic high on RXC to continue.
Here is gets stuck.
I looked at the Set Configuration Bit's
SUT_CKSEL = INTRCOSC_8MHZ_6CK_14CK_65MS
Int. RC Osc. 8 MHz; Start-up time PWRDWN/RESET: 6 CK/14 CK +64ms
CKDIV8 = SET
Divide clock by 8 internally
Also, when I run the code I get the following message.
"Configuration memory will not be programmed because no configuration bits settings have been defined in your code.
To program configuration memory, either define the settings in your code or use the Program Configuration Bits button on the configuration memory window."
I try changing the Configuration Bit's to 16 M or what I believe is 16 M.
Is there an LED on the board? Can you write a small program to turn the led on, delay 500ms, turn it off, delay another 500ms, and then loop continuously.
So the led will blink at 1Hz. And then we really know what speed you are running at.
If only I had an Oscilloscope.
You were right about the 1 M clk. I modified it but I am still not getting any USART action.
When I run in debug mode I can see all the registers being configured as i would expect but the RXC never go high nor do I see and action on UDR0.
You don't need any sophisticated equipment.
Blink an LED at 1Hz to verify the F_CPU is what you thought it was.
You can even measure the accuracy of a nominal RC clock. e.g. count 100 blinks against your wristwatch. gives 1% accuracy. 200 gives 0.5% accuracy.
You already have an onboard debugger on your XPRO board.
Buy a $8 Logic Analyser from China. (or $12 locally). This will give accurate timing and decode USART, SPI, I2C, ...
David.
I verified the clock and it is blinking at 1Hz.
I know I have mentioned this before but this is where it gets stuck.
unsigned char USART_Receive(void)
{
while ( !(UCSR0A & (1<<RXC)) );
return UDR0;
}
unsigned char USART_Receive(void)
{
while ( !(UCSR0A & (1<<RXC)) );
return UDR0;}
The virtual COM port connect to USART1 not USART0...
...and you should also be aware of this...
Ah,
I will make adjustments.
Thank you for alerting me to this error. I think I got blindsided.
My Serial loopback is working perfectly now.
Thank you all for helping.
Soren
