Problem: No AVR support and path issues on windows #5
Conversation
| # known 8-bit MCU families | ||
| list(APPEND MICROCHIP_FAMILIES_8 | ||
| PIC12F | ||
| PIC16F | ||
| PIC18F | ||
| ATtiny | ||
| ATxmega |
There was a problem hiding this comment.
I do not have any test hardware for ATmega. I can add it, but untested.
|
|
||
|
|
||
| function(avr_obj2hex target) | ||
| find_program(AVR_OBJ2HEX |
There was a problem hiding this comment.
I think it would be better to name it AVR_OBJCOPY as it's more descriptive.
There was a problem hiding this comment.
Hmmm, since there is already a MicrochipBin2Hex.cmake it feels for me more suitable.
On the other hand, since I do not develop our MCU software, but manage the CI and test final hardware, this naming is a little helper, that this function gives the files for program the device ;) I know... weak arguments ^^
OBJCOPY directly fits to the called avr program, so there is a better connection for typical developer...
At the end, I found this cmake file once somewhere, it is from the owner of this Repository, and I think it would be nice, if we can discuss the naming with him (and hopefully also other users)
Modules/AVRObj2Hex.cmake
Outdated
| add_custom_command( | ||
| TARGET ${target} POST_BUILD | ||
| WORKING_DIRECTORY ${dir}/$<CONFIG> | ||
| COMMAND "${AVR_OBJ2HEX}" -O ihex "${in_f}$<$<CONFIG:DEBUG>:${CMAKE_DEBUG_POSTFIX}>.elf" "${out_f}" |
There was a problem hiding this comment.
To make it easier to customize consider adding a variable AVR_OBJCOPY_FLAGS (AVR_OBJ2HEX_FLAGS) and maybe appropriate target property for more complex projects.
There was a problem hiding this comment.
Uff, feel free ;) This is behind my knowladge of AVR_OBJCOPY ;)
| elseif(MICROCHIP_MCU MATCHES "^(AT)(tiny|xmega)([a-zA-Z0-9]+)$") | ||
| set(MICROCHIP_MCU_FAMILY "${CMAKE_MATCH_1}${CMAKE_MATCH_2}") | ||
| set(MICROCHIP_MCU_MODEL "${MICROCHIP_MCU}") | ||
| if(MICROCHIP_MCU_FAMILY IN_LIST MICROCHIP_FAMILIES_8) |
There was a problem hiding this comment.
Building a test program to check if the compiler actually supports the CPU would make error messages nicer - i.e. a descriptive error during configure instead of during compile (though still descriptive).
There was a problem hiding this comment.
This idea sounds good. but as above: feel free :)
I can try to manage a configuration test, but i will need some time for it. I want to use this toolchain for some of our components and I just want to share my adaptions, which I made to fit my purposes, so a configuration test is currently not on my way :)
|
If current function This current project state is used since one year for massive CI generated firmware roll outs based on ATxmega256 and ATtiny1627 and XC 2.3x and 2.40 (XC 2.40 should be prefered with this both MCU since a couple of API corrections are made by Microchip in last 2 years). With these changes our resulting hex files are now automaticly flashed to the hardware. |
|
Hey @argltuc, Since this repo seems to be more or less unmaintained I am happy to take this change into my fork: https://github.com/enbyted/cmake-microchip If you're okay with that please open a PR there, against xc8-cc branch. |
|
Hi @enbyted, |
Solution:
Tested against: