Tiny AVR / PIC Bootloader + is the AVR BootLoader both correspondence and PIC.
It seems to have been published at the end of January of 2013, but did not know until today.
PIC is the center Judging from the support situation, PIC32MX also longer supported.
GUI or uploader that runs on Windows, the source of the microcomputer are also disclosed all.
Because there is such as a circuit diagram and the hardware configuration, please use the person you are interested.
AVR microcontrollers and PIC Micro's available from the same tool it is nice.
Me
The Ri Do introduce the Tiny AVR / PIC Bootloader, thank you very much.
My name is Dan of the support member.
For part of AVR(ATTINY) of Tiny AVR / PIC Bootloader, will be supplementary explanation slightly.
Difference between PIC version
Interrupt vector to the PIC will start at 0x0004, but it starts from 0x0001 in AVR(ATTINY).
Fortunately, program memory area the AVR(ATTINY) Since it has circulated to the lowest address from the most significant address, one word RJMP instruction by letting size minute jump of the bootloader in the negative direction from the reset vector 0x0000 in I have made it possible to jump to the bootloader.
To Force copy in four words the beginning of the boot loader area of 0x0000 ~ 0x0003 source code, it had been the outlet of the boot loader This is a PIC version, boot loader so as to meet the one 3 AVR(ATTINY) supports the following code at the outlet of the changes.
(1) 0x0000 If the instruction RJMP
Replace the IJMP instruction by analyzing the jump destination of RJMP instruction. (3 words)
(2) 0x0000 If the instruction RCALL
Replace the ICALL instruction by analyzing the jump destination of RCALL instruction. (3 words) then jump to 0x0001 Force (1 word)
(3) Instruction Other
Then copy code from 0x0000 (one word), then jump to 0x0001 Force (3 words)
With or without the interrupt used by the PIC version, you had to write the jump code to the user program in a region of 0x0000 ~ 0x0003 source code, by substitution of the above code, you do not have this restriction in AVR(ATTINY) .
2. Processing of EEP file
If the EEPROM write Tiny AVR / PIC Bootloader is checked, it is written to EEPROM contents of the EEP file.
Host will write the EEPROM is considered the contents of the EEP file has been placed (of PIC16F) from 0x2100.
Mr. Dan, nice to meet you. And, Thank you for the interesting commentary.
To take advantage of the Bootloader, it is necessary to write the firmware once, programmer of AVR and PIC is required.
In this site, we place the tools available to such writing.
Some it is determined that there is a portion out of the GPL, is limited to trial.
those that intent is not understood Many, I am regret.
I think the thing that Dan's has been addressed, that you have to understand its features and attractive is important.
I think "Tiny AVR / PIC Bootloader" and he characterized to be able to use the BootLoader any MCU that it does not take into account the use of BootLoader, but are listed below the desired personal.
In the tool PC side, I realize writing itself BootLoader.
The information of Fuse AVR (This is the information you will need to program creation) that you can check.
3. Enhance Support MCU (USB built-in MCU and Mega also supported).
4. If you can also write EEPROM in the [Write Flash] button, [Write] button is appropriate.
5. To allow the registration of Hex File in the drop of HEX file.
To enable the HEX file specified from Command line (Wildcard characters support).
7. Add the Help function.
8. Of the start button Terminal software (In order to make efficient use of COM port)
Many of these is the ability to avrdude-GUI version of YCIT is equipped.
---
In Japan, it can be seen that there are those who participate in sourceforge tools microcomputer-related, it became very happy.
Given that have a large number of users of the Arduino also those who do not know the AVR microcontroller, completeness of the tool is very important, it is the matter of mandatory to spread.
In the future, please efforts to enhance the degree of completion.
I am paying attention to the trend.
Best regards,
Dan
Last edit: Dan 2013-07-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks a lot for the informations! These are good news as it seems that "Tiny AVR/PIC Bootloader" is utilised by other people than just you and me ;-)
I've read the enhancements Pr. Senshu has told you about:
1- It could be done by using a programmer (like "Pickit3") with command line from "Tiny AVR/PIC Bootloader". But, is it really usefull?
2- I'm not sure to have understood. Does it mean to display the AVR fuses or program them? If it's programming them, don't you think that people can destroy the bootloader by changing clock source, PLL, etc...?
3- I do agree. I plan USB connection for PIC32, but not for other PIC as the bootloader firmware size will be very big. I'm doing some tests with a PIC32MX460F512L, but I've got a bug that I really don't understand :-(
4- It's done. [Write Flash] is became [Write Device]
5- Very good idea. I'll try to do this.
6- Command line already exists in "Tiny AVR/PIC Bootloader", but it's a good idea to use wildcards.
7- Yes we must... or at least finish the documentation.
8- I really don't understand.
I've seen that you've planned to create bootloader for ATmega... Good luck ;-) But don't spend too much time if you don't plan to use ATmega for your own need.
Best reagrds,
Edorul
PS: in the "about" tab of the PC program how do you want I mention your name? "Dan", "Bequest333", your real name, etc...? And do you want I mention your e-mail, web-site, etc...?
PS2: I'll shortly post a new version with your new firmwares.
PS3: Thanks again for the AVR support as it's a great improvement to "Tiny (PIC) Botloader" :-)
Last edit: edorul 2013-07-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm sorry but I disagree with you, because you're far more than just a support member: you've developped firmwares for more than 50 devices (amont them, devices without UART - I was believing that it was impossible) and you've ported TinyBootloader to AVR! So I consider you as co-developper of "Tiny AVR/PIC Bootloader".
But, if you really want I mention you as a "support member", I'll do it.
Don't you want I put your web site address as it could help some japanese readers?
About Pr. Senshu commentaries:
- I've added drag and drop capability.
- PIC32 bootloader firmware with USB transfert is now working, but it's very big (24kB!).
Best regards,
Edorul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think that the EEPROM problem come from the PC side, because "TinyBootloader+" doesn't even try to write the ".eep" file. In "transfertHexToArray" function the "picEEPROM" array isn't filled by ".eep" values, because it's only done when address is superior to Max Flash Memory. But for ATmega368P Flash=0x4000w=0x8000B and in the code there is:
if (selectedPicInfos.eepromflag == EEP_FILE_EXISTS)
address = 2*address + 0x4200;
which is lower than the ATmega368P Max Flash Memory (0x8000).
You may need to do something like:
if ((selectedPicInfos.eepromflag == EEP_FILE_EXISTS)&&(selectedPicInfos.family == "#A"))
address = 2*address + 0x4200;
if ((selectedPicInfos.eepromflag == EEP_FILE_EXISTS)&&(selectedPicInfos.family == "#B")) // for ATmega family
address = 2*address + 0x8200; // 0x8200 is just an example, as I don't know the real EEPROM address for ATmega
I've thought about something else: we will have a problem with the remaining free "ID codes" for new devices. So when a "device check" is done at the start of the bootloading, the microcontroler could send "0xID_code 0xFamily" instead of "0xID_code 0x4B". By this way we could have 256 different devices for every family.
Do you think it's usefull to do this, or we have enough free "ID codes"?
Best regards,
Edorul
PS: I've uploaded a new version of "TinyBootloader" in case you need to do some modifications for ATmega devices.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Changing the ID code from the host side claudiu.chiculita was implemented,
I think that it is inconvenient because the user is required to distinguish each time the PIC / AVR.
My suggestion is a revival of IdSoftVer that are commented out in the source of the PIC bootloader.
Changed to 16 bytes only ID code of the AVR.
Upon receiving the code for AVR, the host receives a 1-byte extra.
IdTypePIC: ----> Distinction between AVR and PIC
IdSoftVer: ----> The name change to IdTypeAVR
For example, if you fixed to the 0xF1 IdTypePIC the AVR
+------------+------------+------------+
| Device | IdTypePIC | IdTypeAVR |
+------------+------------+------------+
| 10F322 | 0x11 | |
+------------+------------+------------+
| TINY13A | 0xF1 | 0xF1 |
+------------+------------+------------+
| TINY2313A | 0xF1 | 0xF2 |
+------------+------------+------------+
Efficient, to embed the IdTypeAVR without resize easy code of AVR.
Best regards,
Dan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I knew that ATmega won't resist you! Congratulations :-) orn (<- I like this, thanks for the discover ;-) )
About free ID codes, I haven't well explained my thoughts: I don't want to add an extra byte, but just replace 0x4B (='K') by the family letter.
Here is an example coming from PIC16F886:
original code:
;wait for computer
call Receive
sublw 0xC1 ;Expect C1
skpz
goto way_to_exit
SendL IdTypePIC ;PIC type
;SendL IdSoftVer ;firmware ver x
MainLoop
clrf STATUS ;bank0
SendL 'K'
mainl
clrf crc
; etc...
modified code:
;wait for computer
call Receive
sublw 0xC1 ;Expect C1
skpz
goto way_to_exit
SendL IdTypePIC ;PIC type
;SendL IdSoftVer ;firmware ver x
MainLoop
clrf STATUS ;bank0
SendL 'B' ; send 'B' and not 'K' because it's for a "B" family device
mainl
clrf crc
; etc...
But, AVR families' name must be modified in order to be only one char long. "#A" and "#B" will become "1" and "2", so to determine if it's an AVR or PIC device:
if (selectedPicInfos.family.Contains("#")) // then it's AVR family
if (!selectedPicInfos.family.Contains("#")) // then it's PIC family
will become:
if (selectedPicInfos.family < "A") // then it's AVR family
if (selectedPicInfos.family >= "A") // then it's PIC family
Furthermore, "K" must never be used for a family name. By this way, we won't need to modify old bootloader firmwares! When a device answer for example 0x26 0x4B (old type answer):
// in "checkPIC" function
serBuffer[0] = (byte)serialPort.ReadByte(); // ID code
serBuffer[1] = (byte)serialPort.ReadByte(); // Family
if (serBuffer[1] == 0x4B) // old firmware type, 'K' instead of 'family'
if (serBuffer[0] < 0x40)
selectedPicInfos.family = "B"
else if (serBuffer[0] < 0x70)
selectedPicInfos.family = "C"
else.................
else // new firmware type
selectedPicInfos.family = Char.ConvertFromUtf32(serBuffer[1]);
I hope you like this solution ^_^
Best regards,
Edorul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Check Device...
Open COM1 serial port
Device answer: no answer...
Device answer: no answer...
Device answer: no answer...
Device answer: 0xFF 0x32='2'
byte OK, now check ID-code and Family...
idCode = $17
family = 2
description = ATMEGA 328P
flash mem = 32768 bytes
EEPROM mem = 2048 bytes
Bootloader size = 264 bytes
Transfert block size = 128 bytes
Found: ATMEGA 328P
Close COM1 serial port
Check Device...
Open COM1 serial port
Device answer: no answer...
Device answer: no answer...
Device answer: no answer...
Device answer: 0x17 0x32='2'
byte OK, now check ID-code and Family...
idCode = $17
family = 2
description = ATMEGA 328P
flash mem = 32768 bytes
EEPROM mem = 2048 bytes
Bootloader size = 264 bytes
Transfert block size = 128 bytes
Found: ATMEGA 328P
Close COM1 serial port
3.However, errors out with PIC12F752 you are using the same number.
Check Device...
Open COM1 serial port
Device answer: no answer...
Device answer: no answer...
Device answer: 0x17 0x4B='K'
no answer...
Close COM1 serial port
I have no preference. You can use ID code and notations you feel the more convenient for you, I trust you. But remember, if you use "$Fx -> $1x+'1'" you'll need to modify your previous AVR firmwares (send '1' instead of 'K').
Best regards,
Edorul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear Edorul. and All.
Mr.Senshu Professor of Japan was please to introduce a bulletin board of their own.
It is the exchange at that time.
Because it is thought to be a reference in the future, it will be posted.
Original page
http://www-ice.yamagata-cit.ac.jp/forum/viewtopic.php?t=1112
Mr.Senshu (Professor at yamagata-cit.ac) wrote.
Tiny AVR / PIC Bootloader + is the AVR BootLoader both correspondence and PIC.
It seems to have been published at the end of January of 2013, but did not know until today.
PIC is the center Judging from the support situation, PIC32MX also longer supported.
GUI or uploader that runs on Windows, the source of the microcomputer are also disclosed all.
Because there is such as a circuit diagram and the hardware configuration, please use the person you are interested.
AVR microcontrollers and PIC Micro's available from the same tool it is nice.
Me
The Ri Do introduce the Tiny AVR / PIC Bootloader, thank you very much.
My name is Dan of the support member.
For part of AVR(ATTINY) of Tiny AVR / PIC Bootloader, will be supplementary explanation slightly.
Interrupt vector to the PIC will start at 0x0004, but it starts from 0x0001 in AVR(ATTINY).
Fortunately, program memory area the AVR(ATTINY) Since it has circulated to the lowest address from the most significant address, one word RJMP instruction by letting size minute jump of the bootloader in the negative direction from the reset vector 0x0000 in I have made it possible to jump to the bootloader.
To Force copy in four words the beginning of the boot loader area of 0x0000 ~ 0x0003 source code, it had been the outlet of the boot loader This is a PIC version, boot loader so as to meet the one 3 AVR(ATTINY) supports the following code at the outlet of the changes.
(1) 0x0000 If the instruction RJMP
Replace the IJMP instruction by analyzing the jump destination of RJMP instruction. (3 words)
(2) 0x0000 If the instruction RCALL
Replace the ICALL instruction by analyzing the jump destination of RCALL instruction. (3 words) then jump to 0x0001 Force (1 word)
(3) Instruction Other
Then copy code from 0x0000 (one word), then jump to 0x0001 Force (3 words)
With or without the interrupt used by the PIC version, you had to write the jump code to the user program in a region of 0x0000 ~ 0x0003 source code, by substitution of the above code, you do not have this restriction in AVR(ATTINY) .
2. Processing of EEP file
If the EEPROM write Tiny AVR / PIC Bootloader is checked, it is written to EEPROM contents of the EEP file.
Host will write the EEPROM is considered the contents of the EEP file has been placed (of PIC16F) from 0x2100.
Since We have provided a forum to http://sourceforge.net/p/tinypicbootload/discussion/, you would appreciate by, for example, request boot loader development, bug reports.
Mr.Senshu (Professor at yamagata-cit.ac) wrote.
Mr. Dan, nice to meet you. And, Thank you for the interesting commentary.
To take advantage of the Bootloader, it is necessary to write the firmware once, programmer of AVR and PIC is required.
In this site, we place the tools available to such writing.
Some it is determined that there is a portion out of the GPL, is limited to trial.
those that intent is not understood Many, I am regret.
I think the thing that Dan's has been addressed, that you have to understand its features and attractive is important.
I think "Tiny AVR / PIC Bootloader" and he characterized to be able to use the BootLoader any MCU that it does not take into account the use of BootLoader, but are listed below the desired personal.
In the tool PC side, I realize writing itself BootLoader.
The information of Fuse AVR (This is the information you will need to program creation) that you can check.
3. Enhance Support MCU (USB built-in MCU and Mega also supported).
4. If you can also write EEPROM in the [Write Flash] button, [Write] button is appropriate.
5. To allow the registration of Hex File in the drop of HEX file.
7. Add the Help function.
8. Of the start button Terminal software (In order to make efficient use of COM port)
Many of these is the ability to avrdude-GUI version of YCIT is equipped.
---
In Japan, it can be seen that there are those who participate in sourceforge tools microcomputer-related, it became very happy.
Given that have a large number of users of the Arduino also those who do not know the AVR microcontroller, completeness of the tool is very important, it is the matter of mandatory to spread.
In the future, please efforts to enhance the degree of completion.
I am paying attention to the trend.
Best regards,
Dan
Last edit: Dan 2013-07-18
Hello Dan!
Thanks a lot for the informations! These are good news as it seems that "Tiny AVR/PIC Bootloader" is utilised by other people than just you and me ;-)
I've read the enhancements Pr. Senshu has told you about:
1- It could be done by using a programmer (like "Pickit3") with command line from "Tiny AVR/PIC Bootloader". But, is it really usefull?
2- I'm not sure to have understood. Does it mean to display the AVR fuses or program them? If it's programming them, don't you think that people can destroy the bootloader by changing clock source, PLL, etc...?
3- I do agree. I plan USB connection for PIC32, but not for other PIC as the bootloader firmware size will be very big. I'm doing some tests with a PIC32MX460F512L, but I've got a bug that I really don't understand :-(
4- It's done. [Write Flash] is became [Write Device]
5- Very good idea. I'll try to do this.
6- Command line already exists in "Tiny AVR/PIC Bootloader", but it's a good idea to use wildcards.
7- Yes we must... or at least finish the documentation.
8- I really don't understand.
I've seen that you've planned to create bootloader for ATmega... Good luck ;-) But don't spend too much time if you don't plan to use ATmega for your own need.
Best reagrds,
Edorul
PS: in the "about" tab of the PC program how do you want I mention your name? "Dan", "Bequest333", your real name, etc...? And do you want I mention your e-mail, web-site, etc...?
PS2: I'll shortly post a new version with your new firmwares.
PS3: Thanks again for the AVR support as it's a great improvement to "Tiny (PIC) Botloader" :-)
Last edit: edorul 2013-07-18
Dear Edorul.
Although it is review the Credit
by Edorul(edorul@free.fr)
Support members
Dan(Japan)
How about in this.
I hope that the support members increase future.
Best reagrds,
Dan
Hello Dan!
I'm sorry but I disagree with you, because you're far more than just a support member: you've developped firmwares for more than 50 devices (amont them, devices without UART - I was believing that it was impossible) and you've ported TinyBootloader to AVR! So I consider you as co-developper of "Tiny AVR/PIC Bootloader".
But, if you really want I mention you as a "support member", I'll do it.
Don't you want I put your web site address as it could help some japanese readers?
About Pr. Senshu commentaries:
- I've added drag and drop capability.
- PIC32 bootloader firmware with USB transfert is now working, but it's very big (24kB!).
Best regards,
Edorul
Dear Edorul.
I started the evaluation of ATMEGA at (v0.7.0.2).
I created a beta version of ATMEGA328P based on the source of ATTINY2313A.
I can write to the flash, but can not write to the EEPROM.
Transfer to the EEPROM does not seem to be done. (Please refer to the log files.)
Difference of ATMEGA328P and ATTINY2313A.
ATTINY2313A FLASH=0x0400,EEPROM=128
ATMEGA328P FLASH=0x4000,EEPROM=1024
I am sure that can be done successfully writing to the EEPROM of up to 512 bytes in ATTINY861A.
Best reagrds,
Dan
PS,
I respect your feelings.
Although I was good if I can use the "C" a little more... orz
Let's go in France Japan collaboration. (^_^;)
Hello Dan!
This will be a great collaboration :-)
I think that the EEPROM problem come from the PC side, because "TinyBootloader+" doesn't even try to write the ".eep" file. In "transfertHexToArray" function the "picEEPROM" array isn't filled by ".eep" values, because it's only done when address is superior to Max Flash Memory. But for ATmega368P Flash=0x4000w=0x8000B and in the code there is:
if (selectedPicInfos.eepromflag == EEP_FILE_EXISTS) address = 2*address + 0x4200;which is lower than the ATmega368P Max Flash Memory (0x8000).
You may need to do something like:
if ((selectedPicInfos.eepromflag == EEP_FILE_EXISTS)&&(selectedPicInfos.family == "#A")) address = 2*address + 0x4200; if ((selectedPicInfos.eepromflag == EEP_FILE_EXISTS)&&(selectedPicInfos.family == "#B")) // for ATmega family address = 2*address + 0x8200; // 0x8200 is just an example, as I don't know the real EEPROM address for ATmegaI've thought about something else: we will have a problem with the remaining free "ID codes" for new devices. So when a "device check" is done at the start of the bootloading, the microcontroler could send "0xID_code 0xFamily" instead of "0xID_code 0x4B". By this way we could have 256 different devices for every family.
Do you think it's usefull to do this, or we have enough free "ID codes"?
Best regards,
Edorul
PS: I've uploaded a new version of "TinyBootloader" in case you need to do some modifications for ATmega devices.
Dear Edorul.
Thank you very much for reply.
Problem with the remaining free ID codes
Changing the ID code from the host side claudiu.chiculita was implemented,
I think that it is inconvenient because the user is required to distinguish each time the PIC / AVR.
My suggestion is a revival of IdSoftVer that are commented out in the source of the PIC bootloader.
Changed to 16 bytes only ID code of the AVR.
Upon receiving the code for AVR, the host receives a 1-byte extra.
IdTypePIC: ----> Distinction between AVR and PIC
IdSoftVer: ----> The name change to IdTypeAVR
For example, if you fixed to the 0xF1 IdTypePIC the AVR
+------------+------------+------------+
| Device | IdTypePIC | IdTypeAVR |
+------------+------------+------------+
| 10F322 | 0x11 | |
+------------+------------+------------+
| TINY13A | 0xF1 | 0xF1 |
+------------+------------+------------+
| TINY2313A | 0xF1 | 0xF2 |
+------------+------------+------------+
Efficient, to embed the IdTypeAVR without resize easy code of AVR.
Best regards,
Dan
Dear Edorul.
Thank you for advice very accurate.
I was successful in ATMEGA !!!
Test program was also operate normally.
There was an 0x10200 to account for ATMEGA64 address.
I attach the log and the modified Form1.cs.
I have shown in the "//@n" changes to my. (8 places)
$FF, #B, ATMEGA 328P, $8000, 1024, 264, 128,
I have tested under the above conditions.
There is no change of the bootloader.(132byte)
Many thanks.
Best regards,
Dan
Last edit: Dan 2013-07-21
Hello Dan!
I knew that ATmega won't resist you! Congratulations :-) orn (<- I like this, thanks for the discover ;-) )
About free ID codes, I haven't well explained my thoughts: I don't want to add an extra byte, but just replace 0x4B (='K') by the family letter.
Here is an example coming from PIC16F886:
original code:
;wait for computer call Receive sublw 0xC1 ;Expect C1 skpz goto way_to_exit SendL IdTypePIC ;PIC type ;SendL IdSoftVer ;firmware ver x MainLoop clrf STATUS ;bank0 SendL 'K' mainl clrf crc ; etc...modified code:
;wait for computer call Receive sublw 0xC1 ;Expect C1 skpz goto way_to_exit SendL IdTypePIC ;PIC type ;SendL IdSoftVer ;firmware ver x MainLoop clrf STATUS ;bank0 SendL 'B' ; send 'B' and not 'K' because it's for a "B" family device mainl clrf crc ; etc...But, AVR families' name must be modified in order to be only one char long. "#A" and "#B" will become "1" and "2", so to determine if it's an AVR or PIC device:
if (selectedPicInfos.family.Contains("#")) // then it's AVR family if (!selectedPicInfos.family.Contains("#")) // then it's PIC familywill become:
Furthermore, "K" must never be used for a family name. By this way, we won't need to modify old bootloader firmwares! When a device answer for example 0x26 0x4B (old type answer):
// in "checkPIC" function serBuffer[0] = (byte)serialPort.ReadByte(); // ID code serBuffer[1] = (byte)serialPort.ReadByte(); // Family if (serBuffer[1] == 0x4B) // old firmware type, 'K' instead of 'family' if (serBuffer[0] < 0x40) selectedPicInfos.family = "B" else if (serBuffer[0] < 0x70) selectedPicInfos.family = "C" else................. else // new firmware type selectedPicInfos.family = Char.ConvertFromUtf32(serBuffer[1]);I hope you like this solution ^_^
Best regards,
Edorul
Dear Edorul.
The very good if this method, changes in the source code, so need a minimum indeed.
Compatible with the firmware of the conventional PIC will also be guaranteed.
I agree to a method of your proposal.
Best regards,
Dan
Dear Edorul.
There was a mistake in the previous post two.
ATMEGA256 existed.
0x40200 is adequate EEPROM address of ATMEGA.
Correct to apologize.
Best regards,
Dan
Hello Dan!
It's OK. But I've changed "0x40200" to "0x100200", if one day there will be 512kB or even 1MB ATmega (who knows?).
I've also modified everything I told you about previously (look at the readme.txt).
Attached to this post the new PC software, if you want to test it.
Have a good week :-)
Edorul
Dear Edorul.
Thank you very much v0.8.0.
There is a slight bug, I Fixed.(//@1,//@2)
I have tested in ATMEGA328P.
1.ID=$EE,$32
$FF, 2, ATMEGA 328P, $8000, 1024, default, default,
Operate normally.
Check Device...
Open COM1 serial port
Device answer: no answer...
Device answer: no answer...
Device answer: no answer...
Device answer: 0xFF 0x32='2'
byte OK, now check ID-code and Family...
idCode = $17
family = 2
description = ATMEGA 328P
flash mem = 32768 bytes
EEPROM mem = 2048 bytes
Bootloader size = 264 bytes
Transfert block size = 128 bytes
Found: ATMEGA 328P
Close COM1 serial port
2.ID=$17,$32
$17, 2, ATMEGA 328P, $8000, 1024, default, default,
Operate normally.
Check Device...
Open COM1 serial port
Device answer: no answer...
Device answer: no answer...
Device answer: no answer...
Device answer: 0x17 0x32='2'
byte OK, now check ID-code and Family...
idCode = $17
family = 2
description = ATMEGA 328P
flash mem = 32768 bytes
EEPROM mem = 2048 bytes
Bootloader size = 264 bytes
Transfert block size = 128 bytes
Found: ATMEGA 328P
Close COM1 serial port
3.However, errors out with PIC12F752 you are using the same number.
$17, 2, ATMEGA 328P, $8000, 1024, default, default,
$17, B, 12F 752, $800, 0, 232, 32,
Check Device...
Open COM1 serial port
Device answer: no answer...
Device answer: no answer...
Device answer: 0x17 0x4B='K'
no answer...
Close COM1 serial port
Best regards,
Dan
Last edit: Dan 2013-07-22
Hello Dan!
Thanks for the tests!!!
I've modified the bug with the PIC12F752 (it was a problem with a null string).
I've modified //@2 a little for future firmwares of PIC devices.
Best regards,
Edorul
Dear Edorul.
I went all well !!!
Thanks a lot.
Sample program of the two will also operate normally.
I want to change the ID code of AVR boot loader,
Are you sure you want it as follows?
$F1 -> $11+'1'
$F2 -> $12+'1'
$F3 -> $13+'1'
$F4 -> $14+'1'
$F5 -> $15+'1'
$F6 -> $16+'1'
$FF -> $2X+'2'
I think consideration, ATmega other have been examined,
but now you want to notation as follows.
;$21, B, 16F w/1Kw flash & 0B EEPROM, $800, 0, default, default,
;$21, B, 16F w/1Kw flash & 64B EEPROM, $800, 64, default, default,
;$21, B, 16F w/1Kw flash & 128B EEPROM, $800, 128, default, default,
;$21, B, 16F w/2Kw flash & 0B EEPROM, $1000, 0, default, default,
;$21, B, 16F w/2Kw flash & 64B EEPROM, $1000, 64, default, default,
;$21, B, 16F w/2Kw flash & 128B EEPROM, $1000, 128, default, default,
;$21, B, 16F w/2Kw flash & 256B EEPROM, $1000, 256, default, default,
;$21, B, 16F w/4Kw flash & 0B EEPROM, $2000, 0, default, default,
;$21, B, 16F w/4Kw flash & 128B EEPROM, $2000, 128, default, default,
;$21, B, 16F w/4Kw flash & 256B EEPROM, $2000, 256, default, default,
;$21, B, 16F w/8Kw flash & 0B EEPROM, $4000, 0, default, default,
;$21, B, 16F w/8Kw flash & 256B EEPROM, $4000, 256, default, default,
Best regards,
Dan
Last edit: Dan 2013-07-22
Hello again!
I have no preference. You can use ID code and notations you feel the more convenient for you, I trust you. But remember, if you use "$Fx -> $1x+'1'" you'll need to modify your previous AVR firmwares (send '1' instead of 'K').
Best regards,
Edorul