Discussion:
NuttX and IAR IDE
(too old to reply)
avyhovanec@yahoo.com [nuttx]
2016-03-11 07:07:48 UTC
Permalink
Hi, All. I'm partially ported Nuttx v7.14 in IAR IDE for ARM v7.40.
In project based on the configuration stm3220g-eval/nsh2 now working network and nuttshel.
Someone interested in this job?
I'm sorry my English, I using yandex translate.



https://drive.google.com/file/d/0BwWkRX5KWlOybG92eUg1YXM3R0k/view?usp=sharing https://drive.google.com/file/d/0BwWkRX5KWlOybG92eUg1YXM3R0k/view?usp=sharing
canhkha@gmail.com [nuttx]
2016-03-12 15:13:31 UTC
Permalink
Hi avyhovanec,

I found this really interesting.
I use IAR at work and it's really good. I built yours project successfully and I'm going to test the build on my custom STM32F2xx board.
Btw, could you please give some more details on how to convert from nuttx .config to IAR project. I tried to run your python script but got some message (I'm not very good at Python).
Another point that IMO, the export scripts should be put at /tools so that Greg could agree to incorporate if it's good enough.


Thanks,
Kha Vo
avyhovanec@yahoo.com [nuttx]
2016-03-13 07:38:04 UTC
Permalink
Hi, Kha Vo


I think, it is too early to give it to Greg.


I have done the following steps:
1) Configure and compiling NuttX used Cygwin;
2) Clean NuttX, and make redirect out in "in.txt" file;
make clean
make >> in.txt
3) Move "in.txt" to "convert_make2file_list.py";
4) In Cygwin Terminal execute "python3 convert_make2file_list.py";
Script generate new file "out.txt";
The file "out.txt" contains absolute paths to the sorce files:

/cygdrive/d/8_projects/ak100/k103/soft/nuttx/sched/init/os_start.c
/cygdrive/d/8_projects/ak100/k103/soft/nuttx/sched/init/os_bringup.c
...

/cygdrive/d/8_projects/ak100/k103/soft/nuttx/arch/arm/src/board/stm32_nsh.c
5) Create empty project in IAR IDE

6) Set in "add_source_in_iar.py" line 10 var "proj_file" project file name (.ewp)
7) In Cygwin Terminal execute "python3 add_source_in_iar.py"
8) Open project in IAR IDE
9) Compile and get more than 20000 errors :-) I will continue later


Clean asm code and removed hacks
https://drive.google.com/file/d/0BwWkRX5KWlOyUFlyRUJkNUozdlk/view?usp=sharing https://drive.google.com/file/d/0BwWkRX5KWlOyUFlyRUJkNUozdlk/view?usp=sharing
avyhovanec@yahoo.com [nuttx]
2016-03-14 06:13:33 UTC
Permalink
Continued


First problem IAR EW it's file names in IDE must not match. I'm not found better solution than to rename the files manually.
I rename files:
"apps/builtin/builtin.c" as "builtin_app.c";
"nuttx/arch/arm/src/board/stm32_spi.c" as "stm32_selectspi.c";
"nuttx/libc/signal/sig_pause.c" as "sig_pause_libc.c".


Next, IAR uses construction __sfb(".bss") and __sfe(".bss") for definition begin and end sections. Full syntax:
#pragma section = ".bss"
__sfb(".bss") // begin
__sfe(".bss") // end
__sfs(".bss") // size


Last, directive #define in asm not equivalent in c.
"IAR Assembler guide: You must not mix assembler language and C-style preprocessor directives.
Conceptually, they are different languages and mixing them might lead to unexpected
behavior because an assembler directive is not necessarily accepted as a part of the C
preprocessor language."
In stm32_vectors.s definition of disclosed in the manual.


Question: what is fp (frame pinter) in file "nuttx\arch\arm\src\armv7-m\vfork.s" line 124.
This definition is equivalent to the r11 register?
spudarnia@yahoo.com [nuttx]
2016-03-14 14:54:32 UTC
Permalink
Post by ***@yahoo.com [nuttx]
First problem IAR EW it's file names in IDE must not match. I'm not found better solution than to rename the files manually.
"apps/builtin/builtin.c" as "builtin_app.c";
"nuttx/arch/arm/src/board/stm32_spi.c" as "stm32_selectspi.c";
"nuttx/libc/signal/sig_pause.c" as "sig_pause_libc.c".
This is just the tip of the iceberg. For example,

$ find configs -name stm32_spi.c
configs/cloudctrl/src/stm32_spi.c
configs/fire-stm32v2/src/stm32_spi.c
configs/hymini-stm32v/src/stm32_spi.c
configs/maple/src/stm32_spi.c
configs/mikroe-stm32f4/src/stm32_spi.c
configs/nucleo-f303re/src/stm32_spi.c
configs/nucleo-f4x1re/src/stm32_spi.c
configs/nucleo-l476rg/src/stm32_spi.c
configs/olimex-stm32-p107/src/stm32_spi.c
configs/olimexino-stm32/src/stm32_spi.c
configs/shenzhou/src/stm32_spi.c
configs/spark/src/stm32_spi.c
configs/stm3210e-eval/src/stm32_spi.c
configs/stm3220g-eval/src/stm32_spi.c
configs/stm3240g-eval/src/stm32_spi.c
configs/stm32f3discovery/src/stm32_spi.c
configs/stm32f429i-disco/src/stm32_spi.c
configs/stm32f4discovery/src/stm32_spi.c
configs/stm32f746g-disco/src/stm32_spi.c
configs/stm32ldiscovery/src/stm32_spi.c
configs/stm32_tiny/src/stm32_spi.c
configs/viewtool-stm32f107/src/stm32_spi.c

Nothing will be contributed upstream until all ARM configurations build correctly. There is are some test files in https://groups.yahoo.com/neo/groups/nuttx/files in test-files.zip. The script doarm.sh in the ZIP file would have to execute without error before anything is incorporated upstream.
Post by ***@yahoo.com [nuttx]
#pragma section = ".bss"
__sfb(".bss") // begin
__sfe(".bss") // end
__sfs(".bss") // size
I do not permit explicit #pragmas anywhere in the code. Similar, I don't permit GCC-isms in the common code (although I have allowed them in ARM code). And specific compiler differences should be defined in include/nuttx/compiler.h

Other differences in assembler pseudo-operations can be handled with C pre-processor macros (see below)
Post by ***@yahoo.com [nuttx]
Last, directive #define in asm not equivalent in c.
"IAR Assembler guide: You must not mix assembler language and C-style preprocessor directives.
Conceptually, they are different languages and mixing them might lead to unexpected
behavior because an assembler directive is not necessarily accepted as a part of the C
preprocessor language."
In stm32_vectors.s definition of disclosed in the manual.
That is not really true. The C preprocessor has its own syntax and can be used with any file. The NuttX and GCC convention is the files ending with .S are assembly language files that must first be run through the C pre-processor. Files ending in lower case .s are pure assembly language files. NuttX uses all .S files and will continue to do so.

If you use the GCC compiler to assemble .S files, it will automatically run the C pre-processor, generate the .s file, then assembly that. But that is just a convenience built into GCC; You can use the C pre-processor and .S file with any assembler.

For example, look at the z8 code at arch/z80/src/z8. That uses the ZiLOG toolchain and certain does not use .S files directly. Rahter it just adds another target. To assemble and assembly language file, this target is used:

$(AOBJS) $(HEAD_OBJ): %$(OBJEXT): %$(ASMEXT)
$(call ASSEMBLE, $<, $@)

where ASMEXT will be .asm for that machine (vs .s for GCC). But some of the assembly language files are .S files:

$ find . -name *.S
./z8/z8_head.S
./z8/z8_restorecontext.S
./z8/z8_saveusercontext.S
./z8/z8_vector.S

Those get assembled with an intermediate step that runs the C-preprocessor and converts the .S file to a .asm file:


$(HEAD_GENSRC) $(GENSRCS) : %$(ASMEXT): %.S
$(Q) $(CPP) $(CPPFLAGS) $< -o $@.tmp
$(Q) cat $@.tmp | sed -e "s/^#/;/g" > $@
$(Q) rm $@.tmp

This is a good thing for you. Most of the time, I see separate assembly language files for GCC and IAR tools. But with .S files, you can define assembler differences in a header file (like include/nuttx/assembler.h). Then just include that at the beginning of the .S file:

#include <nuttx/assembler.h>

And in that file you can define compiler differnces like:

#ifdef __GCC__
# define __SBSS .bss
# define __EBSS
#else
# define __SBSS \
#pragma section = ".bss"
__sfb(".bss") // begin
# define __EBSS \
__sfe(".bss")
#endif

And in the .S file you can replace .bss with __SBSS then the .S file should compile with both GCC and IAR.
Post by ***@yahoo.com [nuttx]
Question: what is fp (frame pinter) in file "nuttx\arch\arm\src\armv7-m\vfork.s" line 124.
This definition is equivalent to the r11 register?
Yes, fp is a standard ARM alias for r11.

Greg
canhkha canhkha@gmail.com [nuttx]
2016-03-28 04:43:39 UTC
Permalink
Dear Greg, avyhovanec,
Post by ***@yahoo.com [nuttx]
Post by ***@yahoo.com [nuttx]
First problem IAR EW it's file names in IDE must not match. I'm not
found better solution than to rename the files manually.
Post by ***@yahoo.com [nuttx]
"apps/builtin/builtin.c" as "builtin_app.c";
"nuttx/arch/arm/src/board/stm32_spi.c" as "stm32_selectspi.c";
"nuttx/libc/signal/sig_pause.c" as "sig_pause_libc.c".
This is just the tip of the iceberg. For example,
$ find configs -name stm32_spi.c
By separating source code in to small libraries, we could overcome this
file name issue.

I've updated avyhovanec's script to export IAR projects that map the way
we build it by gcc.
The script works properly for me on STM32F2xx.
But the limitation is that you have to edit the asm files manually for IAR.
Post by ***@yahoo.com [nuttx]
Post by ***@yahoo.com [nuttx]
Next, IAR uses construction __sfb(".bss") and __sfe(".bss") for
#pragma section = ".bss"
__sfb(".bss") // begin
__sfe(".bss") // end
__sfs(".bss") // size
I do not permit explicit #pragmas anywhere in the code. Similar, I
don't permit GCC-isms in the common code (although I have allowed them
in ARM code). And specific compiler differences should be defined in
include/nuttx/compiler.h
Other differences in assembler pseudo-operations can be handled with C
pre-processor macros (see below)
Post by ***@yahoo.com [nuttx]
Last, directive #define in asm not equivalent in c.
"IAR Assembler guide: You must not mix assembler language and
C-style preprocessor directives.
Post by ***@yahoo.com [nuttx]
Conceptually, they are different languages and mixing them might
lead to unexpected
Post by ***@yahoo.com [nuttx]
behavior because an assembler directive is not necessarily accepted
as a part of the C
Post by ***@yahoo.com [nuttx]
preprocessor language."
In stm32_vectors.s definition of disclosed in the manual.
That is not really true. The C preprocessor has its own syntax and can
be used with any file. The NuttX and GCC convention is the files
ending with .S are assembly language files that must first be run
through the C pre-processor. Files ending in lower case .s are pure
assembly language files. NuttX uses all .S files and will continue to
do so.
If you use the GCC compiler to assemble .S files, it will
automatically run the C pre-processor, generate the .s file, then
assembly that. But that is just a convenience built into GCC; You can
use the C pre-processor and .S file with any assembler.
For example, look at the z8 code at arch/z80/src/z8. That uses the
ZiLOG toolchain and certain does not use .S files directly. Rahter it
just adds another target. To assemble and assembly language file, this
$(AOBJS) $(HEAD_OBJ): %$(OBJEXT): %$(ASMEXT)
where ASMEXT will be .asm for that machine (vs .s for GCC). But some
$ find . -name *.S
./z8/z8_head.S
./z8/z8_restorecontext.S
./z8/z8_saveusercontext.S
./z8/z8_vector.S
Those get assembled with an intermediate step that runs the
$(HEAD_GENSRC) $(GENSRCS) : %$(ASMEXT): %.S
This is a good thing for you. Most of the time, I see separate
assembly language files for GCC and IAR tools. But with .S files, you
can define assembler differences in a header file (like
include/nuttx/assembler.h). Then just include that at the beginning of
#include <nuttx/assembler.h>
#ifdef __GCC__
# define __SBSS .bss
# define __EBSS
#else
# define __SBSS \
#pragma section = ".bss"
__sfb(".bss") // begin
# define __EBSS \
__sfe(".bss")
#endif
And in the .S file you can replace .bss with __SBSS then the .S file
should compile with both GCC and IAR.
Regarding the asm cross compilers, I'm currently use the alter version
for IAR in avyhovanec's post :(
I may not help much on this.

I'm planing to update script to generate the project for Keil also.
I think it's worth to make Nuttx friendly to IAR and Keil users. These
IDEs help much on understanding and debugging nuttx. Btw, building is
faster and output binary is much smaller than gcc.


I attach the export script and template project for IARs on STM32F2xx in
case you find it interesting.

Regards,
Kha Vo
spudarnia@yahoo.com [nuttx]
2016-03-28 14:17:09 UTC
Permalink
I am not sure what I could do with these files. Perhaps you could create a directory in the Files area NuttX Embedded RTOS https://groups.yahoo.com/neo/groups/nuttx/files

https://groups.yahoo.com/neo/groups/nuttx/files

NuttX Embedded RTOS https://groups.yahoo.com/neo/groups/nuttx/files Nuttx is a real-time embedded operating system (RTOS). It has a small footprint that is usable in micro-controller environments. It is fully scalable from tin...



View on groups.yahoo.com https://groups.yahoo.com/neo/groups/nuttx/files
Preview by Yahoo





And make IAR support available there?


Greg
canhkha canhkha@gmail.com [nuttx]
2016-03-28 15:22:28 UTC
Permalink
Dear Greg,

Thank you for quick replying!
Post by ***@yahoo.com [nuttx]
I am not sure what I could do with these files
I'm sorry for confusing you on this.
iar_exporter.py may be put to nuttx/tools, other template files could be
put in the the board config directory.

It's too early to put these files upstream and say that nuttx support
IAR. I'm dealing with porting asm files to IAR and this may not be
finished it soon.
We will give a pull request or patch when we got a property working
version, until that time you may fell free to ignore posts in this thread.

Regards,
Kha Vo
avyhovanec@yahoo.com [nuttx]
2016-03-29 06:11:50 UTC
Permalink
Hi Kha Vo. Wow! Cool job.
I fork NuttX repository for make IAR support. You can join.
https://bitbucket.org/AVyhovanec/nuttx/commits/branch/iar https://bitbucket.org/AVyhovanec/nuttx/commits/branch/iar

Sorry, this is my firts experience with NuttX, GCC, Git and Bitbucket and I can make serious mistakes. And i'm busy on a project with very tight deadlines. But, I want to help NuttX.
avyhovanec@yahoo.com [nuttx]
2016-03-30 18:22:47 UTC
Permalink
Thanks, Greg. It become clearer. Greg, i now launching custom board based on STM32F207 and find minor errata in sources.
How best to send you patches?
spudarnia@yahoo.com [nuttx]
2016-03-30 20:31:01 UTC
Permalink
Best to send patches either to this list or to my personal email. Since we are breaking new ground, I will need to review how things fit into the overall build system.


Greg
avyhovanec@yahoo.com [nuttx]
2016-04-02 10:44:43 UTC
Permalink
Hi, Greg.

Here are the files that I changed to successfully compile NuttX in IAR EW.


---In ***@yahoogroups.com, <***@...> wrote :

Best to send patches either to this list or to my personal email. Since we are breaking new ground, I will need to review how things fit into the overall build system.


Greg
spudarnia@yahoo.com [nuttx]
2016-04-02 14:20:19 UTC
Permalink
I have committed these changes into the NuttX repository. I did have to move a few things around for compatibility with the GNU toolchain. Here is what I did:


1. All of the STM32 assembly language files are now in iar/ or gnu/ sub-directories
2. All of the ARMv7-M assembly language files are now in iar/ or gnu/ sub-directories.
3. I added configuration options to select the IAR toolchain in the configuration. This is now required to use the IAR toolchain.
4. I modified arch/arm/src/Makefile to add with the iar/ or the gnu/ sub-directories to the VPATH based on the toolchain selection.


I have only build one STM32 configuration to verify this. There could still be lurking build bugs. Of course, I did not build any IAR configurations. Can you please try that?


Greg
spudarnia@yahoo.com [nuttx]
2016-04-02 14:32:44 UTC
Permalink
Also...


I did not commit the .icf files. I presume those would go in a board linker script directory. Is that true.


And wasn't there supposed to be some Python script that goes in the tools/ directory?


Greg
canhkha@gmail.com [nuttx]
2016-04-08 09:11:48 UTC
Permalink
Hi Greg,

I'm sending you a bundle of patches that help to EXPORT nuttx to use with IAR and uVision:
Now, it's really easy to use nuttx with these IDEs.


Please help to review and apply the patchs one by one:


01_port_up_testset.S_for_iar.patch
-> Port up_testset.S to iar asm


02_fix_ip_h_empty_structure.patch
-> fix empty structures ip.h when both IPv4 and IPv6 are not enable. IAR does not allow empty structure.


03_add_export_info_README.patch
-> Some guides for how to use the exporter stuff.


04_add_exporter_tool.patch
-> The exporter script.


05_stm3220g-eval-template.patch
-> Sample template projects for stm32F2 mcu (include iar ld script from avyhovanec)


06_stm3220g-eval_nsh_sample_projects.patch
-> Output of the exporter (IAR and uVision workspace)


07_add_stm32f429i_disco_templates.patch
-> Sample template projects for stm32F4 mcu


08_add_stm32f429i_disco_ltcd_sample_project.patch

-> Output of the exporter (IAR and uVision workspace)



Since this stuff do not touch the nuttx source (except ip.h) so you may not worry much about the regression.
I've tested and these sample workspaces work properly so do the Cygwin make.


There are some TODO things:
1. C++ for IAR :
nuttx c++ uses some g++ extension so they need to port back to IAR. I'm not familiar to these so I leave it here and hope there are some others could help.
2. uVision with armcc toolchain:
I got troubles with armcc inline asm in irq.h. It needs to revise the irq.h inline asm to work with armcc
3. Add template projects for others configurations.


Anyone finds this interesting please fell free to update and send patch directly to Greg for incorporating.


Thanks and regards,
Kha Vo


---In ***@yahoogroups.com, <***@...> wrote :

Also...


I did not commit the .icf files. I presume those would go in a board linker script directory. Is that true.


And wasn't there supposed to be some Python script that goes in the tools/ directory?


Greg
spudarnia@yahoo.com [nuttx]
2016-04-08 12:34:11 UTC
Permalink
Thanks! I have the patches and I will review and incorporated them later today. Right now, the repository is a mess and I need to focus on getting that straighten up before I commit more.


Sorry about the delay.


Greg
spudarnia@yahoo.com [nuttx]
2016-04-08 21:01:56 UTC
Permalink
Hi, Kha Vo,


Everything has been committed. That was a big effort! Those project files are huge. I wonder what is the best to handle such things in the long run?


Today has been very hectic and one of those days where one comes to believe he/she is incompetent. Please verify the commits to make sure tht I did not screw those up too!


Thanks,
Greg
canhkha canhkha@gmail.com [nuttx]
2016-04-09 01:53:52 UTC
Permalink
Hi Greg,
Post by ***@yahoo.com [nuttx]
Please verify the commits to make sure tht I did not screw those up too!
Thanks you! The commits are OK (but it's so sad that others history are
gone).
Post by ***@yahoo.com [nuttx]
Those project files are huge. I wonder what is the best to handle
such things in the long run?
We could keep one template per one core/mcu family only instead of put
it into board config.
It's easy create these templates by creating a new blank project from
the IDE. Other users who have IDEs and boards may want to try and put
them upstream.

The sample output workspaces could be omitted since users could generate
them from the script.

Regards,
Kha Vo
avyhovanec@yahoo.com [nuttx]
2016-05-17 06:21:31 UTC
Permalink
Hi all.

After the break, returned to nuttx. I missed him :).
Now made a NAND support for STM32F2. Will upload the files after optimization.

Trying to get IAR to generate a relocatable ELF file to load the modules. It's not out yet :(.


Additionally, post the file wfi.mac. It should be copied into the directory with the IAR project. Then set it to "Options -> Debugger -> Setup macro file(s)". This will allow debugging via JTAG when calling the WFI instruction.
spudarnia@yahoo.com [nuttx]
2016-05-17 12:46:24 UTC
Permalink
I added wfi.mac to the repository. You did not say exactly which directory it belongs in. I assume configs/stm3220g-eval/ide/nsh/iar


Greg
avyhovanec@yahoo.com [nuttx]
2016-05-17 19:23:06 UTC
Permalink
Hi, Greg
Post by ***@yahoo.com [nuttx]
I assume configs/stm3220g-eval/ide/nsh/iar
It's good.


Greg, question:
File \nuttx\sched\module\mod_verify.c line 97 and file \nuttx\binfmt\libelf\libelf_verify.c line 105 text
Post by ***@yahoo.com [nuttx]
if (ehdr->e_type != ET_REL)
Why check ET_REL flag instead ET_EXEC?
avyhovanec@yahoo.com [nuttx]
2016-06-07 12:24:55 UTC
Permalink
Hi Greg.


I compile nuttx 7.16 in iar ide and get the following errors:


sig_set.c
Error[Pe042]: operand types are incompatible ("void (*)(int)" and "void *") \nuttx\libc\signal\sig_set.c 125
Error[Pe513]: a value of type "void *" cannot be assigned to an entity of type "_sa_handler_t" \nuttx\libc\signal\sig_set.c 128
Error[Pe042]: operand types are incompatible ("_sa_handler_t" and "void *") \nuttx\libc\signal\sig_set.c 138
Error[Pe513]: a value of type "void *" cannot be assigned to an entity of type "_sa_handler_t" \nuttx\libc\signal\sig_set.c 150


Here is a small patch that fixes the problem
spudarnia@yahoo.com [nuttx]
2016-06-07 12:56:24 UTC
Permalink
Committed. Thanks!


Greg
avyhovanec@yahoo.com [nuttx]
2016-08-24 11:33:25 UTC
Permalink
Hi Greg.

Add STM32F1xx vectors. Tested on STM32F103RB and STM32F107RC


Please apply the attached patch.
spudarnia@yahoo.com [nuttx]
2016-08-24 16:10:29 UTC
Permalink
Also commited. Thanks.
avyhovanec@yahoo.com [nuttx]
2017-01-07 18:23:49 UTC
Permalink
Hi, Greg.

NuttX has macro packed_struct. IAR uses the __packed keyword.

The problem is that the keyword __packed placed before the definition of the structure, and macro packed_struct after.

For example:
__packed struct adc_msg_s
{
uint8_t am_channel; /* The 8-bit ADC Channel */
int32_t am_data; /* ADC convert result (4 bytes) */
} packed_struct;

I propose to add to compiler.h another macro in this case. But I can not offer a suitable name for it.

Please suggest a name for the macro, and I will prepare the pull request.



Thanks.
spudarnia@yahoo.com [nuttx]
2017-01-08 16:40:01 UTC
Permalink
I don't have any great names. We change the packed_struct macro to post_packed_struct, then pre_packed_struct would be natural. Would there be a lot of references to packed_struct that would have to be changed? I don't think there are many.


Greg
spudarnia@yahoo.com [nuttx]
2017-01-08 16:48:06 UTC
Permalink
or maybe begin_packed_struct and end_packed_struct.
canhkha canhkha@gmail.com [nuttx]
2017-01-09 05:46:15 UTC
Permalink
hi all,

mbed uses this, you may want somethings similar:


#ifndef MBED_PACKED
#if defined(__ICCARM__)
#define MBED_PACKED(struct) __packed struct
#else
#define MBED_PACKED(struct) struct __attribute__((packed))
#endif
#endif

Examples:
MBED_PACKED(struct) TestAttrPackedStruct1 {
char a;
int x;
};

typedef MBED_PACKED(struct) {
char a;
int x;
} TestAttrPackedStruct2;

Regards,
Kha Vo
Post by ***@yahoo.com [nuttx]
or maybe begin_packed_struct and end_packed_struct.
spudarnia@yahoo.com [nuttx]
2017-01-09 14:50:54 UTC
Permalink
I like the way mbed did that a LOT better. I have already accepted the PR for begin_packed_struct/end_packed_struct change, however. If someone is motivated to make this more mbed-like, I was accept yet-another-PR.


Greg

avyhovanec@yahoo.com [nuttx]
2016-04-02 17:19:36 UTC
Permalink
Post by ***@yahoo.com [nuttx]
I have committed these changes into the NuttX repository. I did have to move a few things around for
compatibility with the GNU toolchain
Greg, I do not propose to modify the existing build system using GNU toolchain. She is beautiful and
I believe that support for IAR compiler it does not need. The thing is that IAR Embedded Workbench (IAR EW) provides all necessary infrastructure from the editor and ending with a powerful debugger C-SPY. All this is tightly integrated in the IDE. IAR EW users do not use the console in their everyday work.
I think that at this stage would be perfect just to have the assembler files for IAR EW in separate directories. This will allow to understand the direction in which to develop a Python script for export to the IAR EW.
Post by ***@yahoo.com [nuttx]
I have only build one STM32 configuration to verify this. There could still be lurking build bugs. Of course, > I did not build any IAR configurations. Can you please try that?
Yes, I can check it out, but I would have to get out of your comfort zone into the console. I need that time to "gather courage" :-). Where can I find the source code for the test?
Loading...