[Chris]

Hi,

I just wanted to know if there are any news regarding the support of custom boards with Analyzer2go.

Regards,
Chris

[Chris]

Tank you very much for reply.
No presssure, just me beeing curious.

[Chris]

Hi,

again, any news? Just me beeing a little nosy here 🙂

[Chris]

Hi,

any news on this?

[Chris]

Hello,

 

today I tried v5.4R2 of VisualGDB.
Now VisaulGDB does accept the changes made to the compiler. At least within the ProjectProperties.
But regardless, the system seems to switch back to use GCC_ARM compiler in the background.

Although I configured a new project, refering to an already checked out mbed-os, utilizing ARMCC compiler, during the project initialization I receive the following output:

Checking if any source files need uploading…
[Warning] D:\###\MbedProject1::: Compiler version mismatch: Could not detect version; expected version >= 6.0.0 and < 7.0.0
Building project MbedProject1 (NUCLEO_F746ZG, GCC_ARM)
Scan: MbedProject1
Scan: mbed-os_v51100
Compile [ 0.1%]: main.cpp
System.OperationCanceledException: The operation was canceled.
at n51.l(String a)
at n51.c_2()
at zz.m()
Checking if any source files need uploading…
[Warning] D:\###::: Compiler version mismatch: Could not detect version; expected version >= 6.0.0 and < 7.0.0
Building project ### (NUCLEO_F746ZG, GCC_ARM)
Scan: demo_BACnet4Mbed_vs
Scan: mbed-os_v51100
Compile [ 0.1%]: main.cpp
Saved the code model to D:\###\VisualGDBCache\###-Debug-NUCLEO_F746ZG\BuildCommandLines.txt

The actual build of the project then again seems to be handled via ARMCC toolchain, acording to output:

—— Build started: Project: demo_BACnet4Mbed_vs, Configuration: Debug NUCLEO_F746ZG ——
VisualGDB: Run “C:\Python27\python.exe D:\mbed-os_v51100\tools\make.py -t ARM -m NUCLEO_F746ZG –profile D:/mbed-os_v51100/tools/profiles/debug.json –source . –source D:\mbed-os_v51100 –build Build/NUCLEO_F746ZG/Debug” in directory “D:\demo_BACnet4Mbed_vs” on local computer
Building project demo_BACnet4Mbed_vs (NUCLEO_F746ZG, ARM)
Scan: demo_BACnet4Mbed_vs
Scan: mbed-os_v51100
Compile [ 0.1%]: mbed_tz_context.c
[…]
Compile [100.0%]: us_ticker.c
Link: ###
Elf2Bin: ###
| Module | .text | .data | .bss |
|—————————|—————|————-|—————|
| [lib]\c_w.l | 11207(+11207) | 16(+16) | 348(+348) |
| [lib]\cpprt_w.l | 76(+76) | 0(+0) | 0(+0) |
| [lib]\fz_wm.l | 18(+18) | 0(+0) | 0(+0) |
| [lib]\m_wm.l | 48(+48) | 0(+0) | 0(+0) |
| anon$$obj.o | 32(+32) | 0(+0) | 256(+256) |
| main.o | 120(+120) | 0(+0) | 28(+28) |
| mbed-os_v51100\cmsis | 1093(+1093) | 0(+0) | 0(+0) |
| mbed-os_v51100\components | 199(+199) | 0(+0) | 0(+0) |
| mbed-os_v51100\drivers | 1114(+1114) | 0(+0) | 152(+152) |
| mbed-os_v51100\features | 1150(+1150) | 12(+12) | 12868(+12868) |
| mbed-os_v51100\hal | 4712(+4712) | 39(+39) | 240(+240) |
| mbed-os_v51100\platform | 5248(+5248) | 108(+108) | 561(+561) |
| mbed-os_v51100\rtos | 13029(+13029) | 2554(+2554) | 4560(+4560) |
| mbed-os_v51100\targets | 16106(+16106) | 32(+32) | 1108(+1108) |
| Subtotals | 54152(+54152) | 2761(+2761) | 20121(+20121) |
Total Static RAM memory (data + bss): 22882(+22882) bytes
Total Flash memory (text + data): 56913(+56913) bytes

Image: Build/NUCLEO_F746ZG/Debug\###.bin
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

 

Is this intended behaviour?

[Chris]

Srry for the doublepost. For some reason I couldn’t modify my first post.

Attachments:

You must be logged in to view attached files.

[Chris]

Hi,

thank you for your considerations towards my suggestion.
I hope, I will find the time during the next few days to have a look at your solution.

Thanks,
Chris

[Chris]

Hi,

any news on this?

[Chris]

Hello,

first, please excuse my late reply.

If it would be possible to implement this, it would be a tremendous improvement to our current workflow and maybe I could pursue my collegues to give VisualGDB another try. (In regards to MbedOS)

 

Best regards,
Chris

[Chris]

We have checked the internals of cmake-cli and will contribute an exporter module that will construct a VisualGDB project (similar to what it does for IAR projects) if the mbed community is OK with this.

Are there already any news on this?

[Chris]

That would be great!

As much as I like to work with mbed for it’s simplicity in regards to choosing an MCU and mostly without further addo getting down to business, I dislike it’s stiffness in regards on how to implement mebd for any non “online ARM mbed compiler” .

[Chris]

The problem with treating the mbed-cli projects as normal editable VisualGDB projects is that it would depend on the internal format of the files generated by mbed-cli and will stop working each time the format changes.

That would certainly be true for project-files like thos for KEIL’s µVision5 or any other IDE, but what aboutr makefile-projects?

Wouldn’t it be possible to temporarily create a makefile-project, extract the needed settings / information and then move those to a VisualGDB Project?

As I already mentied earlier, this would reduce the comfort of VisualGDB while creating projects (MCU/Board not necissarily know by VGDB beforehand), but would drasticaly increase the flexibility regarding mbed-projects with VisualGDB.

 

 

Regardles if this would be possible or not thanks for your POV on this topic and some insights.

Greetings,

Chris

[Chris]

Yes, sure I could do that, same thing as with any other makefile.

But I can’t help but feel, this would defeat the advantage of using the VisualGDB Extension, which I’d actually would love to use in combination with the mbed-cli.

 

But still, thank you for your support.

[Chris]

You can try using our mbed BSP generator to build a first-class BSP that will be fully synchronized with Visual Studio, although it may need some adjustment due to changes to mbed codebase since the release it officially supports.

While that would be a possibility, I’m actually not too keen on pushing time into additional software, just to start a project.

The mbed-cli tool actualy does everything I need, just not in a form which VisualGDB understands right now.

 

I was in hope there would be a build-in option to rather easily transfer the information the mbed-cli deliveres to VGDB. The ‘project.py’ located within the tools folder of the mbed-os sources actualy delivers a necessary information.

Lets say mbed-os is located at C: a soon to be established project is placed at C:\project\ and mbed-os itself is located at C:\mbed-os\. The most simple way to start an empty mbed project for a mbed-supported toolchain would be to set your command-line to C:\project\ and execute: “..\mbed-os\tools\project.py -m NUCLEO_F767ZI -i uvision5 –source . –source ..\mbed-os”.

This then would create a Project-File for (in this case) KEIL µVision5, ready to be used, all necessary information about the mbed-board already set and all necessary mbed-os files set up in the project.

I admit this is practically the exact opposite way of creating a project as a VGDB BSP would do, since it requires to choose a controller/board by hand, knowing what to choose, without selcting one from a precompiled list. Certainly it is possible to pick the necessary information from such a project and move it to VGDB, but that takes time and includes the risk of easily done mistakes.

But still, it is the probably easiest and fastest way to deal with rapid mbed-os updates without relying on, to be frank, waaaaay outdated VGDB BSP’s.

 

If it would be possible to implement a mechanic in VGDB to diretly use the mbed-cli from the project-wizard it would be possible to easily upgrade to a new mbed-os release without relying on a BSP without having to ue the BSPGenerator, which altough it’s a great tool, is rather inflexible when it comes to the fast and sometimes unpredctable changes of mbed-os. Especialy regarding the upcoming changes in mbed-os 5.5.

[Chris]

Thanks, I will try that.

[Author]

Posts