You need to go back and re-read the comments made above.
The USART baud rate needs to have an error of less than 2%, or you can easily have serial communications problems, which include wrong data, or no data.
The App AVRCalc by Jack Tidwell is an easy tool for checking Xtal frequencies, baud rates, and error rates (%).
The data sheets often have tables with this information as well.
115200 Baud with either an 8 or a 16 MHz Xtal gives a 7.8 % baud rate error.
That simply won't work.
An 11.0592 MHz Xtal gives a 0 % error for 115.2K Baud.
The PC to ESP connection works because both have an accurate baud rate.
The micro to ESP fails because the baud rate is not accurate with your 16 MHz Xtal.
Get out your soldering iron and change crystal on the board.
Finally)))Problem was not correct FUSE config on ATmega16. I set LOW Fuse Resister on 0xFF and Termite start to receive correct data) BUT I STRONGLY RECOMMENDED TO READ MANUAL TWICE BEFORE SET FUSES Not correct fuses set may cause microcontroller failed permanently.
I guess ATmega16 will work with 8MHz as well, I will tested it.
There's an Arduino Core for the mega16. This implements things like a circular buffer and a system tick which come as part of the Arduino infrastructure. There's plenty of Arduino/esp8266 examples, so this should smooth the path a little.
You are just reinventing eeprom_write_byte() in the above. Also note that it's not a good idea to use eeprom_write_byte() (or your function) anyway. If you keep calling the function for the same location with the same data it will write it anyway. Each write eats away at the 100,000 cycle life of the eeprom location. Better is to use eeprom_update_byte() this does a (fast) read before write check and if the location already holds the value to be written it doesn't do it. This can save major amounts of EEPROM wear!
This requires some knowledge of the avr-gcc ABI but basically the first parm (addr) will be in R25:R24 the the second parm (16 bit value to write) will be in R23:R22. The first call will write R22 (low byte) then second writes R23 (high) but what I don't see is the EEAR increment but the must be implied by the write_r18 routine. The whole of avr-gcc does things little endian. I doubt the EEPROM routines would be any different.
.
Hope you are having a good day by the way ;-)
Posted by MarkThomas: Fri. Mar 15, 2019 - 04:16 PM
1
2
3
4
5
Total votes: 0
I will have to be careful where I have written ints big endian using the code examples in the data sheet for reading and writing to EEPROM when I switch over to the gcc functions. The update function is nice, even though my use of EEPROM will probably take 10,000 years to get to 100,000 writes.
clawson wrote:
Hope you are having a good day by the way ;-)
Thanks for that. Doing much better. Hope your day is one of the better ones too.
I'm a little late to the party, so my apologies if the following has been answered already:
Is the OP absolutely sure they are running the AVR off of a 16MHz EXTERNAL crystal? Were the fuses set for a High Frequency crystal/full swing crystal?
The best you can get on a 16MHz crystal with X2 programmed is 57600. Anything higher is out of spec. As already mentioned you can go with a baud friendly crystal, or tailor your application to what reliable speeds can be achieved.
Before moving forward, create a very simple application that echos back to your terminal program what the AVR receives from your terminal program. Once you have that running then you can add the SP module.
Jim
I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie
"The critical shortage here is not stuff, but time." - Johan Ekdahl
"Step N is required before you can do step N+1!" - ka7ehk
"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
I'm allready create simple prog for testing only. On terminal I read info transfered from ATmega16. But there is some problems with transfer info from terminal prog to Atmega16. (Between ESP8266 module and terminal no problems to transfering on 115.2K baud rate). So what cristal value I should use to get 115.2K baud rate between Atmega16 and terminal prog??
So what cristal value I should use to get 115.2K baud rate between Atmega16 and terminal prog??
Teh Datasheet provides plenty of information on this. The one I use is 11.052Mhz, as it gives 0% error.
Darien wrote:
But there is some problems with transfer info from terminal prog to Atmega16.
That can be your crystal frequency, or your code, or both.
Have you programmed the fuses in the AVR for an external crystal? I am thinking yes, but I have nothing to confirm this.
I am not at my PC today with time to write code, but I would suggest you write a simple loopback program that does the following(based on a 16MHz crystal)
USART RX ISR
{
uint8_t data; //local variable
data = UDR0; //get teh data from UDR0
UDR0 = data; //send the received data back to the terminal
}
void main(void)
{
//init the usart
Configure the USART for 8-N-1
Set Baud to 57600 - you will need the x2 enabled for this
Enable the RX interrupt
Enable the RX and TX
sei();
while(1)
{
//hang out here and do nothing until data comes in
}
}
57600 is the fastest the USART can go within error specs for a 16MHz crystal. If everything is in order, anything you type on the terminal should be echoed back to it.
I also don't understand why ISR(USART_RXC_vect) is run when I send from ATmega16 to Terminal data. FUSES can be issue to it?
Fuses have nothing to do with it. And how do you know that the Interrupt fired when you send data? The TX and RX pins are separate entities. Unless your terminal program is sending data at the same time they do not interact with one another.
JIm
I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie
"The critical shortage here is not stuff, but time." - Johan Ekdahl
"Step N is required before you can do step N+1!" - ka7ehk
"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
As written - because you are repeatedly setting all bis of LED_PORT back to 0 in the while(1) then even if RXC fires it should only be momentary but will then be turned off almost immediately anyway. However this is what the mega16 datasheet says about the RXC interrupt flag:
so the read of UDR clears the RXC flag. Otherwise as soon as one interrupt condition occurs it will never clear and the ISR() will simply run over and over again.
As written - because you are repeatedly setting all bis of LED_PORT back to 0 in the while(1) then even if RXC fires it should only be momentary but will then be turned off almost immediately anyway. However this is what the mega16 datasheet says about the RXC interrupt flag:
so the read of UDR clears the RXC flag. Otherwise as soon as one interrupt condition occurs it will never clear and the ISR() will simply run over and over again.
I miss that in datasheet. I try...it won't help. LED fires up and then momentary turned off...but it is enough time to see blink. I assume ISR(USART_RXC_vect) run when I receive data not send. So when I send data LED_PIN1 must be ON not LED_PIN0.
Terminal is out off memory. To meny data to recieve and Terminal shuts down.
You have bigger problems then, and they have nothing to do with the AVR. I ran that code and it works on RealTerm, and Termite3.4.
At this point the world is spinning its wheels. Please try and make up a very basic connection from your PC to your AVR. Make sure all VCC/AVcc pins are connected together and all GND pins are connected together. Bypass caps on all power pins and a .1uf cap on Vref.
Run the AVR at 5v
Connect nothing else to the AVR other than your USB/USART adapter.
I would like to see a link to the USB/USART adapter you are using. I hope you are not connecting RS232 levels to your AVR as that will certainly damage it.
Jim
I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie
"The critical shortage here is not stuff, but time." - Johan Ekdahl
"Step N is required before you can do step N+1!" - ka7ehk
"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
Terminal is out off memory. To meny data to recieve and Terminal shuts down. LED_PIN0 in permanently ON.
When I try to send data from Atmega16 to Terminal (by func) -> Terminal is out off memory. To meny data to recieve and Terminal shuts down. LED_PIN0 in permanently ON.
When I try to send data from Terminal to Atmega16 -> nothing happens.
Did you set the AVR up like I described in #83? Can you post a link to the USART/USB adapter you are using?
Remember I tried the code I posted with the same terminal program you are using and had no issues, so you may have a problem with your software.
Did you create a new, fresh project with the application I posted above? If yes, can you ZIP it up and attach it here so we can see if there is something wrong?
The fact that your Terminal program is shutting down is a red flag that you have something wrong with your PC software.
JIm
I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie
"The critical shortage here is not stuff, but time." - Johan Ekdahl
"Step N is required before you can do step N+1!" - ka7ehk
"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
That tells us NOTHING! WHat are you getting? What are you expecting? As I said, the code was tested on real hardware. Including the same terminal program you are using.
JIm
EDIT:
Use a 16MHz crystal. Baud rate is set for 57600. In your terminal whatever you type will be echoed back.
I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie
"The critical shortage here is not stuff, but time." - Johan Ekdahl
"Step N is required before you can do step N+1!" - ka7ehk
"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
I find out that when I try to get an echoe Terminal shust down -> permanenly get data:
ISR (USART_RXC_vect )
{
uint8_t data;
data = UDR;
// UDR = data; - becouse of this code line. It starts infinite loop for data transfering..I don't know how.
}
You need to go back and re-read the comments made above.
The USART baud rate needs to have an error of less than 2%, or you can easily have serial communications problems, which include wrong data, or no data.
The App AVRCalc by Jack Tidwell is an easy tool for checking Xtal frequencies, baud rates, and error rates (%).
The data sheets often have tables with this information as well.
115200 Baud with either an 8 or a 16 MHz Xtal gives a 7.8 % baud rate error.
That simply won't work.
An 11.0592 MHz Xtal gives a 0 % error for 115.2K Baud.
The PC to ESP connection works because both have an accurate baud rate.
The micro to ESP fails because the baud rate is not accurate with your 16 MHz Xtal.
Get out your soldering iron and change crystal on the board.
JC
Edit: Typo
- Log in or register to post comments
TopNo I did not. I typed I switch to 16MHz extermal crystal but nothig changed.
- Log in or register to post comments
TopHave you changed the baud rate on that configuration to 9600, like Kartman suggested, to rule out the baud rate as the problem?
- Log in or register to post comments
TopI switch to 16MHz external and set settings to 115.2K by set 2.1%.
But I alse set
...with U2X=1 error is 2.1%
But I also set baud rate to 2400 on ATmega16 by
and Termite -> with U2X=1 error is 0.0%
Transfer failed.
- Log in or register to post comments
TopI guess some problem in USART_Init func but I can't find any)
- Log in or register to post comments
TopAnd you changed the denominator in speed calculation back to 16?
I dont know how defines work but if you define something after you use it in a defined calculation does the calculation know what it is?
I don't think I can help any more. Best luck.
- Log in or register to post comments
TopFinally)))Problem was not correct FUSE config on ATmega16. I set LOW Fuse Resister on 0xFF and Termite start to receive correct data) BUT I STRONGLY RECOMMENDED TO READ MANUAL TWICE BEFORE SET FUSES Not correct fuses set may cause microcontroller failed permanently.
I guess ATmega16 will work with 8MHz as well, I will tested it.
- Log in or register to post comments
TopTanks all for help. Some good ideas I will use like 'Circular Buffer ')
- Log in or register to post comments
TopThere's an Arduino Core for the mega16. This implements things like a circular buffer and a system tick which come as part of the Arduino infrastructure. There's plenty of Arduino/esp8266 examples, so this should smooth the path a little.
https://github.com/MCUdude/Might...
- Log in or register to post comments
TopIf you are using avr-gcc why on earth are you doing this? It already comes with a whole suite of eeprom access functions:
https://www.nongnu.org/avr-libc/...
You are just reinventing eeprom_write_byte() in the above. Also note that it's not a good idea to use eeprom_write_byte() (or your function) anyway. If you keep calling the function for the same location with the same data it will write it anyway. Each write eats away at the 100,000 cycle life of the eeprom location. Better is to use eeprom_update_byte() this does a (fast) read before write check and if the location already holds the value to be written it doesn't do it. This can save major amounts of EEPROM wear!
- Log in or register to post comments
TopYes, I know but this is for beter understanding how to work with EEPROM.
I also have some func to work with external EEPROM.
Currently I use EEPROM for the test only to view result data (without LCD).
I don't know how else view data if USART is not available.
- Log in or register to post comments
TopCliff, are the reads and writes for 16 bit words all little endian in the gcc functions? Little endian seems so wrong. The bits are out of order.
- Log in or register to post comments
Top.
http://svn.savannah.gnu.org/viewvc/avr-libc/trunk/avr-libc/libc/misc/eewr_word.S?revision=1979&view=markup
This requires some knowledge of the avr-gcc ABI but basically the first parm (addr) will be in R25:R24 the the second parm (16 bit value to write) will be in R23:R22. The first call will write R22 (low byte) then second writes R23 (high) but what I don't see is the EEAR increment but the must be implied by the write_r18 routine. The whole of avr-gcc does things little endian. I doubt the EEPROM routines would be any different.
.
Hope you are having a good day by the way ;-)
- Log in or register to post comments
TopI will have to be careful where I have written ints big endian using the code examples in the data sheet for reading and writing to EEPROM when I switch over to the gcc functions. The update function is nice, even though my use of EEPROM will probably take 10,000 years to get to 100,000 writes.
Thanks for that. Doing much better. Hope your day is one of the better ones too.
mark
- Log in or register to post comments
TopActually, more like 500 years to get to 100,000 writes with what I am currently doing. I hope to not live that long.
- Log in or register to post comments
TopI'm a little late to the party, so my apologies if the following has been answered already:
Is the OP absolutely sure they are running the AVR off of a 16MHz EXTERNAL crystal? Were the fuses set for a High Frequency crystal/full swing crystal?
The best you can get on a 16MHz crystal with X2 programmed is 57600. Anything higher is out of spec. As already mentioned you can go with a baud friendly crystal, or tailor your application to what reliable speeds can be achieved.
Before moving forward, create a very simple application that echos back to your terminal program what the AVR receives from your terminal program. Once you have that running then you can add the SP module.
Jim
I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie
"The critical shortage here is not stuff, but time." - Johan Ekdahl
"Step N is required before you can do step N+1!" - ka7ehk
"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, RSLogix user
- Log in or register to post comments
TopI'm allready create simple prog for testing only. On terminal I read info transfered from ATmega16. But there is some problems with transfer info from terminal prog to Atmega16. (Between ESP8266 module and terminal no problems to transfering on 115.2K baud rate). So what cristal value I should use to get 115.2K baud rate between Atmega16 and terminal prog??
- Log in or register to post comments
TopAny "magic crystal" (ie multiple of 300Hz)
- Log in or register to post comments
TopTeh Datasheet provides plenty of information on this. The one I use is 11.052Mhz, as it gives 0% error.
That can be your crystal frequency, or your code, or both.
Have you programmed the fuses in the AVR for an external crystal? I am thinking yes, but I have nothing to confirm this.
I am not at my PC today with time to write code, but I would suggest you write a simple loopback program that does the following(based on a 16MHz crystal)
57600 is the fastest the USART can go within error specs for a 16MHz crystal. If everything is in order, anything you type on the terminal should be echoed back to it.
JIm
EDIT:
Heres the config:
I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie
"The critical shortage here is not stuff, but time." - Johan Ekdahl
"Step N is required before you can do step N+1!" - ka7ehk
"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, RSLogix user
- Log in or register to post comments
TopI set LOW fuses as 0xFF.
- Log in or register to post comments
TopYup, thats the proper setting for external crystal.
JIm
I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie
"The critical shortage here is not stuff, but time." - Johan Ekdahl
"Step N is required before you can do step N+1!" - ka7ehk
"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, RSLogix user
- Log in or register to post comments
TopI also don't understand why ISR(USART_RXC_vect) is run when I send from ATmega16 to Terminal data. FUSES can be issue to it?
- Log in or register to post comments
TopFuses have nothing to do with it. And how do you know that the Interrupt fired when you send data? The TX and RX pins are separate entities. Unless your terminal program is sending data at the same time they do not interact with one another.
JIm
I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie
"The critical shortage here is not stuff, but time." - Johan Ekdahl
"Step N is required before you can do step N+1!" - ka7ehk
"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, RSLogix user
- Log in or register to post comments
TopI light LED in USART_TXC_vect and USART_RXC_vect. When I send from ATmega16 LED0 in ON (LED_PIN0).
- Log in or register to post comments
TopWhat crystal is this number for?
JIm
I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie
"The critical shortage here is not stuff, but time." - Johan Ekdahl
"Step N is required before you can do step N+1!" - ka7ehk
"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, RSLogix user
- Log in or register to post comments
Top16MHz -> 38.4K baud rate (I set lover speed) UBRR(dec)=51, U2Xn = 1
- Log in or register to post comments
TopSo your code needs to be:
so the read of UDR clears the RXC flag. Otherwise as soon as one interrupt condition occurs it will never clear and the ISR() will simply run over and over again.
- Log in or register to post comments
TopI miss that in datasheet. I try...it won't help. LED fires up and then momentary turned off...but it is enough time to see blink. I assume ISR(USART_RXC_vect) run when I receive data not send. So when I send data LED_PIN1 must be ON not LED_PIN0.
- Log in or register to post comments
TopDarien,
Try this:
Use a 16MHz crystal. Baud rate is set for 57600. In your terminal whatever you type will be echoed back.
Forget about your LED's etc as we have no idea how your custom board works. Get the AVR to talk to your terminal program. THEN we can move on.
JIm
I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie
"The critical shortage here is not stuff, but time." - Johan Ekdahl
"Step N is required before you can do step N+1!" - ka7ehk
"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, RSLogix user
- Log in or register to post comments
Toppost a link to the USB/RS232 adapter you are using and a schematic of how you are connecting all of this up too.
Jim
I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie
"The critical shortage here is not stuff, but time." - Johan Ekdahl
"Step N is required before you can do step N+1!" - ka7ehk
"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, RSLogix user
- Log in or register to post comments
TopTerminal is out off memory. To meny data to recieve and Terminal shuts down. LED_PIN0 in permanently ON.
- Log in or register to post comments
TopYou have bigger problems then, and they have nothing to do with the AVR. I ran that code and it works on RealTerm, and Termite3.4.
At this point the world is spinning its wheels. Please try and make up a very basic connection from your PC to your AVR. Make sure all VCC/AVcc pins are connected together and all GND pins are connected together. Bypass caps on all power pins and a .1uf cap on Vref.
Run the AVR at 5v
Connect nothing else to the AVR other than your USB/USART adapter.
I would like to see a link to the USB/USART adapter you are using. I hope you are not connecting RS232 levels to your AVR as that will certainly damage it.
Jim
I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie
"The critical shortage here is not stuff, but time." - Johan Ekdahl
"Step N is required before you can do step N+1!" - ka7ehk
"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, RSLogix user
- Log in or register to post comments
TopWhen I try to send data from Atmega16 to Terminal (by func) -> Terminal is out off memory. To meny data to recieve and Terminal shuts down. LED_PIN0 in permanently ON.
When I try to send data from Terminal to Atmega16 -> nothing happens.
- Log in or register to post comments
TopDid you set the AVR up like I described in #83? Can you post a link to the USART/USB adapter you are using?
Remember I tried the code I posted with the same terminal program you are using and had no issues, so you may have a problem with your software.
Did you create a new, fresh project with the application I posted above? If yes, can you ZIP it up and attach it here so we can see if there is something wrong?
The fact that your Terminal program is shutting down is a red flag that you have something wrong with your PC software.
JIm
I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie
"The critical shortage here is not stuff, but time." - Johan Ekdahl
"Step N is required before you can do step N+1!" - ka7ehk
"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, RSLogix user
- Log in or register to post comments
TopI am using PL2303
I create new exetutable C project. My ATmega16 powered by 5V external power supply (not battery). To my AVR connected Atmel-ICE promater (SPI).
Attachment(s):
- Log in or register to post comments
TopOk, that USB adapter is a USB to TTL USART device so no issues there.
Did you connect the AVR the way I explained in #85, and if you did, does the code work properly?
I looked at your ZIP and removed all of your other code, and the project builds. Load this into the AVR and test. Report back what your results are.
JIm
Attachment(s):
I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie
"The critical shortage here is not stuff, but time." - Johan Ekdahl
"Step N is required before you can do step N+1!" - ka7ehk
"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, RSLogix user
- Log in or register to post comments
TopAll check... exept: .1uf cap on Vref.
But code still not working as expected.
- Log in or register to post comments
TopThat tells us NOTHING! WHat are you getting? What are you expecting? As I said, the code was tested on real hardware. Including the same terminal program you are using.
JIm
EDIT:
Use a 16MHz crystal. Baud rate is set for 57600. In your terminal whatever you type will be echoed back.
I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie
"The critical shortage here is not stuff, but time." - Johan Ekdahl
"Step N is required before you can do step N+1!" - ka7ehk
"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, RSLogix user
- Log in or register to post comments
TopI find out that when I try to get an echoe Terminal shust down -> permanenly get data:
And more friendlly to USART use this:
instead of this:
Bot I still don't know why my LED_PIN0 is blinking when I send data from ATmega16 to Terminal.
I tested all code on real hardwere: different testing boards + different ATmega16 chips.
- Log in or register to post comments
TopPages