I would like to use the mPython in my project. I use STM32F429 and compiler IAR studio.
So, the question is: what is the way of porting the Project to another compiler?
How to compile the Project in IAR studio for STM32F429
Re: How to compile the Project in IAR studio for STM32F429
I guess you'd have to try it, see what doesn't work and report back?
I believe that most of the developers are using gcc, so it really depends on whether (or how many) gcc-isms have crept into the code.
I believe that most of the developers are using gcc, so it really depends on whether (or how many) gcc-isms have crept into the code.
Re: How to compile the Project in IAR studio for STM32F429
Sorry for reviving this old thread. But did you get it done?
I have the same problem: I want to port MicroPython to the IAR C compiler. So I would appreciate if you can tell me if you was successful..
I have the same problem: I want to port MicroPython to the IAR C compiler. So I would appreciate if you can tell me if you was successful..
Re: How to compile the Project in IAR studio for STM32F429
I have the same problem,iar can use gcc as it's core compile.but it's difficult to gen qstr
Re: How to compile the Project in IAR studio for STM32F429
I have the same problem with Greenhills compiler and the qstr gen.
Because the preprocessor output not match exactly to this lines: https://github.com/micropython/micropyt ... efs.py#L26.
I tried a little but no working solution, yet.
Maybe someone had the same problem and can help?
Maybe you can configure IAR to execute a post-exec/script at first. To execute the python scripts for the qstr gen.
Because the preprocessor output not match exactly to this lines: https://github.com/micropython/micropyt ... efs.py#L26.
I tried a little but no working solution, yet.
Maybe someone had the same problem and can help?
Maybe you can configure IAR to execute a post-exec/script at first. To execute the python scripts for the qstr gen.
-
- Posts: 54
- Joined: Wed Jan 31, 2018 3:10 pm
Re: How to compile the Project in IAR studio for STM32F429
Hi,
Another revival of this old thread.
I (think I) worked around the problem mentioned above by first compiling for stm32f4 under normal linux and then copy the generated files.
Cheating i know but if the generated stuff does not change much it is "workable".
However that is not the end of the road to misery.
\examples\embedding\README.md naively/optimistically mentions:
a) You would need to use C99 standard (you're using this 15+ years old standard already, not a 25+ years old one, right?).
Well IAR is a C99 standard compiler, unfortunately GCC is not and working around the nonstandard used by micropython is proving to be 'quite' challenging.
So far I have encountered:
- usage in flexible array initialization
- usage of alloca
- the trick with the emitnative.c (still not sure how that compiles actually under GCC/makefiles, as the N_THUMB/... are just defined and are not given a value but in the C file there are tests like (MICROPY_EMIT_THUMB && N_THUMB) which needs them to be a value and not just as being defined)
- in nativeglue, a reference is taken from nlr_push and nlr_pop without a prototype being present for the functions ? Including the h file does not work because they are being defined there (under certain conditions) io of a prototype. Again one for the not sure how this can compile in the original code.
- vmentrytable.h: Getting desperate here:
static const void *const entry_table[256] = {
[0 ... 255] = &&entry_default,
[MP_BC_LOAD_CONST_FALSE] = &&entry_MP_BC_LOAD_CONST_FALSE,
[MP_BC_LOAD_CONST_NONE] = &&entry_MP_BC_LOAD_CONST_NONE,
[MP_BC_LOAD_CONST_TRUE] = &&entry_MP_BC_LOAD_CONST_TRUE,
( and probably some minor ones which i have already suppressed )
Regards
Bram
Another revival of this old thread.
I (think I) worked around the problem mentioned above by first compiling for stm32f4 under normal linux and then copy the generated files.
Cheating i know but if the generated stuff does not change much it is "workable".
However that is not the end of the road to misery.
\examples\embedding\README.md naively/optimistically mentions:
a) You would need to use C99 standard (you're using this 15+ years old standard already, not a 25+ years old one, right?).
Well IAR is a C99 standard compiler, unfortunately GCC is not and working around the nonstandard used by micropython is proving to be 'quite' challenging.
So far I have encountered:
- usage in flexible array initialization
- usage of alloca
- the trick with the emitnative.c (still not sure how that compiles actually under GCC/makefiles, as the N_THUMB/... are just defined and are not given a value but in the C file there are tests like (MICROPY_EMIT_THUMB && N_THUMB) which needs them to be a value and not just as being defined)
- in nativeglue, a reference is taken from nlr_push and nlr_pop without a prototype being present for the functions ? Including the h file does not work because they are being defined there (under certain conditions) io of a prototype. Again one for the not sure how this can compile in the original code.
- vmentrytable.h: Getting desperate here:
static const void *const entry_table[256] = {
[0 ... 255] = &&entry_default,
[MP_BC_LOAD_CONST_FALSE] = &&entry_MP_BC_LOAD_CONST_FALSE,
[MP_BC_LOAD_CONST_NONE] = &&entry_MP_BC_LOAD_CONST_NONE,
[MP_BC_LOAD_CONST_TRUE] = &&entry_MP_BC_LOAD_CONST_TRUE,
( and probably some minor ones which i have already suppressed )
Regards
Bram