Forum Replies Created
-
Posts
-
I am resurrecting this topic as VisualGDB has become an option again due to the latest 5.2 update. 3 or 4 years ago we investigated VisualGDB to replace the IAR + Eclipse solution we were using for development. There were 2 hanging items that caused us not to switch:
- VisualGDB only seems to fully support GCC. We need it to support IAR. This is a requirement; we cannot switch to GCC. There is not an issue with the compiler itself, but rather the crappy LD linker that GNU seems to use. IAR allows code objects to be placed inside non contiguous memory regions whereas LD requires you to explicitly place the objects by hand. This is a non negotiable feature in our development process as we are working on MCUs with non contiguous memory. Changes to the output memory map happen when each person compiles a new feature into the code base, and at times we have up to 10 developers working on the same code base, each with their own test setup. Imagine coordinating RAM memory placement across non contiguous memory with that many people. The IAR linker does this automatically – just tell the linker the memory regions and boom, its done.
- You could not specify per file / folder build options. For example, I want to exclude files / folders from specific build configurations for the build. It looks like this has changed with the migration to MSBuild; however, it does not look like you can do per folder options. This is not a breaking feature in the decision; we can work around that.
We would really like to get away from Eclipse as our development IDE, because its got a massive number of issues that the developers seem to plainly ignore. Visual Studio would be ideal, because its just awesome. However, we require IAR support.
Now, I am wondering if it is possible to put IAR support into VisualGDB manually by just building some of our own command line tools that can pre process the command line options being passed into and written out of the tools such as the compiler, assembler, and linker – basically ‘convert’ the gcc command lines to iar ones. Do you think this is possible or can you give me a place to start?
Also is IAR support planned at all?
I apologize: I just looked in eclipse, and it looks like Eclipse supports 2 levels of nesting and not 3 from what I can see. If you implement the 2nd level of nesting in the UI, I think that would be OK for us.
Here is a screenshot I just took of the Eclipse register view and layout I am comparing to. At the top level you have the “register set”. At the 2nd level you have the hardware register, and at the third level you have the bit fields. The view is very fluid, because all you have to do to go to a nested level is click the little tree expand arrow.
From what I can see, you are almost there with the feature set we would “like”. Now, I am not saying you have to go further than you have. We can probably work within what you have implemented. However, a nice feature would be arbitrary levels of nesting, or several more levels of nesting.
From what I see, you support 2 levels of nesting: GPIOC -> MODER -> bit1, or RCC -> AHBPENR -> USBCLKEN (bit 1) for example. If we take a queue from eclipse, eclipse supports at least 3 levels of nesting. For example: GPIO -> GPIOA, GPIOB, GPIOC, etc.. -> MODER -> bit1. Furthermore, you do not seem to have a UI yet for your second level of nesting. We would like to request that the 2nd level of nesting ‘at least’ be implemented in the UI.
I am not quite sure I understand how you are planning on displaying the 2nd level of nesting. It seems complicated to put that inside a combo box for the bit fields. If you want, I can provide a screenshot of how Eclipse does the nesting and displays all the register data in the view. In my opinion, Eclipse has a very nice register view where you can easily view the registers at each level of the nesting.
This is an interesting feature. I am assuming this is undocumented?
I don’t want to nag, and this feature would almost be complete. If I was going to implement such a feature, I would do it in a similar way. HOWEVER!
I am not clear if this xml file supports nesting for the hardware register definitions. Don’t get me wrong. I hate Eclipse with a passion, but it is what we develop with. The debugger is so – so. Eclipse IAR does though have a nice register view layout (while it may be buggy). For each MCU, the register modules are grouped. You can drill down into those groups and get at the data. For example, for a GPIO module, the group would be GPIOA. You then click on this group and you drill down to ODR, IDR, etc.. Another one might be the RCC module. At the lowest level, the view even gives you the register bits for that particular register.
So, is it possible to nest the register definitions into multiple nodes / groups? What about bit fields? If I have a 32 bit peripheral register, bit 0 might represent enabling clock A. Bit 20 might represent that a timer timed out. Eclipse IAR has these type of bit field views at the lowest level.
Again, let me emphasize that if you cannot do this and or do not plan on supporting such functionality in the register view, we have no problem whatsoever making our own register view that has such functionality. This was my intention in the first place.
Writing the name of the register in the watch window is not at all desirable. That is simply one step above writing the direct address of the register in a memory view; it is a sprinkle of sugar. We want the entire package of sugar, not a sprinkle. Every time we have to debug the registers, we don’t want to have to remember the name of the register and type it in. A peripheral register view is desirable and a basic component of embedded bare metal debugging (which we must do). IAR Eclipse provides this functionality.
I am not asking the Visual GDB team to implement this feature, I am simply asking how we could proceed in writing our own simple viewer.
After doing a little more research, it seems like I was correct. All you should need to do is format the compiler output strings in a format visual studio understands, and they will automatically be picked up by the error and warning windows.
I am going to check out makefile theory, because I am not familiar with them: I am a windows guy 😛
Yes, IAR for ARM produces ELF files compatible with GDB. We use the JLink tool from segger, which takes as input our ELF files.
This would be extremely cool if we could use IAR with visual GDB. I am assuming I am going to have to heavily modify the makefile so that it uses the IAR compiler and puts in the proper command switches. I think that after we produce a few of the make files, it will all just be copy and paste anyways.
Now, there is only one issue to be resolved. I know for a fact the IAR compiler output is not in gcc format. However, I also understand that in order to populate the warning / error windows in visual studio you need to follow a certain output format for the output strings. If we simply parse the IAR output for strings from the compiler with a build step after running the compiler and put the strings in the proper format, will that populate the error / warning lists? Will we be able to click on an error / warning and be brought to the source file containing the item?
Thanks
As far as I know, IAR for ARM produces ELF files that are in the same exact format as what the gcc toolchain produces. On top of that, you guys already support debugging with Segger Jlink. Many companies use IAR + Jlink. It would be a very awesome feature if you guys supported IAR as well.
I am not sure if you were responding to his particular post with regards to the MSP430 series, but a huge number of IAR customers use ARM, which produces ELF files from the compiler.
I for one would buy this product if IAR was supported for ARM.
