Re: [nbdev] Re: CND with bare metal target: module + netbeans modifications

[Jan Breuer <ja...@jaybee.cz>]

Hello Emilian,
thank you, I will repost it to apache incubator.

I have patched version of NetBeans 7.4 but all patches are ugly. It does
not run with clean NetBeans. I have also ported it to 8.2 without problems
but it remains the same ugly patches. I need to do it right and probably
push something upstream.

> Sounds like you need some API based on GdbDebuggerImpl? How did things
work before?
Some API will be nice. I had heavily modified version of GdbDebuggerImpl.

> This sounds like isRemote() to me, although communication is not via SSH.
Mainly yes, but it is not true in all cases. It is few years I have done
the patching of GdbDebuggerImpl and cnd.makeproject so it may be better in
recent versions. I must investigate it.

> PS: I assume you heard of https://en.wikipedia.org/wiki/Sleepycat_Software
It was school project so the name was not important. Now, I can rename it,
because of this colision.

--Jan

2017-04-03 13:47 GMT+02:00 Emilian Bold <em...@gmail.com>:

> Jan, NetBeans is becoming part of Apache so it would be best to
> (cross-)post on dev@netbeans.incubator.apache.org
>
> It seems to me that right now everything runs without patching NetBeans
> 7.4?
>
> So the problem is that your existing hooks no longer work? (They probably
> never were and official API, no?)
>
> Even if you have to patch NetBeans, open-sourcing the tool + patches +
> modules seems valuable.
>
> I haven't worked on the cnd modules but I'll throw my 2c:
>
>  > Crosscompilation to bare metal - platform: There are many checks in the
> source if the target platform is right (Linux, Windows). This is not an
> issue for bare metal compilation, because it will produce same result on
> all platforms.
>
> If it's not an issue, it shouldn't matter. You could either use
> PlatformTypes. PLATFORM_GENERIC or the default platform, etc.
>
> > Program loading (Run button): [...] Executing the application on bare
> metal is something between isLocal() and isRemote() in sense of NetBeans
> CND.
>
> This sounds like isRemote() to me, although communication is not via SSH.
>
> > Debugger [...]
>
> Sounds like you need some API based on GdbDebuggerImpl? How did things
> work before?
>
> PS: I assume you heard of https://en.wikipedia.org/wiki/Sleepycat_Software
>
> --emi
>
>
> On Mon, Apr 3, 2017 at 12:29 PM, Jan Breuer <ja...@jaybee.cz> wrote:
>
>> Hello,
>> I have developed a SCIDE <http://pck338-242.feld.cvut.cz/scide/>, the
>> development environment for bare metal ARM Cortex devices. It was designed
>> for my students at the university but now, I'm still using this IDE and my
>> colegues enjoy it also so I decided to upgrade the old base from NetBeans
>> 7.4 to NetBeans 8 (or 9).
>> I would like to do it right now and open the source. And possibly
>> separate it to the standalone module for NetBeans in the future.
>> Unexpectedly, there are many blockers now in NetBeans sources. Currently,
>> it is bad hack of many cnd and dlight modules.
>>
>> What I need is to provide seamless build, run and debug experience
>> without configuring paths to tools and running external tools manualy.
>> I can provide some patches to CND to support this usage but I would like
>> to do it right.
>>
>> There are these issues for me:
>>
>> Crosscompilation to bare metal - platform:
>> There are many checks in the source if the target platform is right
>> (Linux, Windows). This is not an issue for bare metal compilation, because
>> it will produce same result on all platforms.
>> (e.g. in cnd.makeproject/src/org/netbeans/modules/cnd/makeproject/con
>> figurations/ConfigurationMakefileWriter.java)
>> What is the right way to solve this? Introduce new platform in
>> org.netbeans.modules.cnd.makeproject.api.configurations.Platforms? How
>> to correctly force this platform in new project? Can I introduce new
>> platform in module and inject it using OpenIDE?
>>
>> Program loading (Run button):
>> It is not possible to run the compiled code directly, but the code must
>> be loaded to target device. There is no SSH or so. Program loading is done
>> by flash tool. Remote platform dialog is completely useless for this. I
>> would like to provide flash tool in a module, so user should just select
>> correct tool and not path to it.
>> It seems like extending of org.netbeans.modules.nativeexecution.api.NativeProcess
>> and org.netbeans.modules.nativeexecution.api.ExecutionEnvironment is
>> good idea, but they are so tightly coupled to SSH... Executing the
>> application on bare metal is something between isLocal() and isRemote() in
>> sense of NetBeans CND.
>> How to correctly hook to "Run" event and execute the loader? Using own
>> ExecutionEnvironment? How to force own ExecutionEnvironment in the CND
>> project?
>>
>> Debugger:
>> Again, it is something between local and remote debuging in sense of
>> NetBeans CND. I'm using OpenOCD as "gdb remote" but it is possible to run
>> it using pipes, not tcp ports.
>> OpenOCD is executed by the IDE so no need to run anything manually. Just
>> press "debug button".
>> In conjuction with OpenOCD, some commands are missing. E.g. it is not
>> possible to execute gdb command "-exec-run", but instead, just
>> "-exec-continue" is supported.
>> There is need to chain some commands to standard debug commands e.g.
>> "monitor reset run", "monitor reset halt", ...
>> There is also need to preload the program to the device by external
>> command before debug (same as running the code)
>> How to correctly hook to these events without changing or reimplementing
>> org.netbeans.modules.cnd.debugger.gdb2.GdbDebuggerImpl?
>>
>> Any ideas are welcome.
>>
>> Best regards,
>> Jan Breuer
>>
>>
>>
>

Re: [nbdev] Re: CND with bare metal target: module + netbeans modifications

[Vladimir Voskresensky <Vl...@oracle.com>]

Hello Jan,

I think for prototyping your approach could be fine, but for the 
production you should introduce new project type and new debugger 
modules instead.
Debugger module could be based on cnd.debugger.common2 APIs
All other parts of CND (including code assistance and refactorings) will 
work as soon as you implement NativeProjectProvider in your project's 
Lookup.
This is the recommended way comparing and was successfully used i.e. by 
https://dzone.com/articles/nb-microchip. Btw, targeting bare metal as well.

Hope it helps,
Vladimir.


On 04/ 3/17 03:15 PM, Jan Breuer wrote:
> Hello Emilian,
> thank you, I will repost it to apache incubator.
>
> I have patched version of NetBeans 7.4 but all patches are ugly. It does
> not run with clean NetBeans. I have also ported it to 8.2 without problems
> but it remains the same ugly patches. I need to do it right and probably
> push something upstream.
>
>> Sounds like you need some API based on GdbDebuggerImpl? How did things
> work before?
> Some API will be nice. I had heavily modified version of GdbDebuggerImpl.
>
>> This sounds like isRemote() to me, although communication is not via SSH.
> Mainly yes, but it is not true in all cases. It is few years I have done
> the patching of GdbDebuggerImpl and cnd.makeproject so it may be better in
> recent versions. I must investigate it.
>
>> PS: I assume you heard of https://en.wikipedia.org/wiki/Sleepycat_Software
> It was school project so the name was not important. Now, I can rename it,
> because of this colision.
>
> --Jan
>
> 2017-04-03 13:47 GMT+02:00 Emilian Bold <em...@gmail.com>:
>
>> Jan, NetBeans is becoming part of Apache so it would be best to
>> (cross-)post on dev@netbeans.incubator.apache.org
>>
>> It seems to me that right now everything runs without patching NetBeans
>> 7.4?
>>
>> So the problem is that your existing hooks no longer work? (They probably
>> never were and official API, no?)
>>
>> Even if you have to patch NetBeans, open-sourcing the tool + patches +
>> modules seems valuable.
>>
>> I haven't worked on the cnd modules but I'll throw my 2c:
>>
>>   > Crosscompilation to bare metal - platform: There are many checks in the
>> source if the target platform is right (Linux, Windows). This is not an
>> issue for bare metal compilation, because it will produce same result on
>> all platforms.
>>
>> If it's not an issue, it shouldn't matter. You could either use
>> PlatformTypes. PLATFORM_GENERIC or the default platform, etc.
>>
>>> Program loading (Run button): [...] Executing the application on bare
>> metal is something between isLocal() and isRemote() in sense of NetBeans
>> CND.
>>
>> This sounds like isRemote() to me, although communication is not via SSH.
>>
>>> Debugger [...]
>> Sounds like you need some API based on GdbDebuggerImpl? How did things
>> work before?
>>
>> PS: I assume you heard of https://en.wikipedia.org/wiki/Sleepycat_Software
>>
>> --emi
>>
>>
>> On Mon, Apr 3, 2017 at 12:29 PM, Jan Breuer <ja...@jaybee.cz> wrote:
>>
>>> Hello,
>>> I have developed a SCIDE <http://pck338-242.feld.cvut.cz/scide/>, the
>>> development environment for bare metal ARM Cortex devices. It was designed
>>> for my students at the university but now, I'm still using this IDE and my
>>> colegues enjoy it also so I decided to upgrade the old base from NetBeans
>>> 7.4 to NetBeans 8 (or 9).
>>> I would like to do it right now and open the source. And possibly
>>> separate it to the standalone module for NetBeans in the future.
>>> Unexpectedly, there are many blockers now in NetBeans sources. Currently,
>>> it is bad hack of many cnd and dlight modules.
>>>
>>> What I need is to provide seamless build, run and debug experience
>>> without configuring paths to tools and running external tools manualy.
>>> I can provide some patches to CND to support this usage but I would like
>>> to do it right.
>>>
>>> There are these issues for me:
>>>
>>> Crosscompilation to bare metal - platform:
>>> There are many checks in the source if the target platform is right
>>> (Linux, Windows). This is not an issue for bare metal compilation, because
>>> it will produce same result on all platforms.
>>> (e.g. in cnd.makeproject/src/org/netbeans/modules/cnd/makeproject/con
>>> figurations/ConfigurationMakefileWriter.java)
>>> What is the right way to solve this? Introduce new platform in
>>> org.netbeans.modules.cnd.makeproject.api.configurations.Platforms? How
>>> to correctly force this platform in new project? Can I introduce new
>>> platform in module and inject it using OpenIDE?
>>>
>>> Program loading (Run button):
>>> It is not possible to run the compiled code directly, but the code must
>>> be loaded to target device. There is no SSH or so. Program loading is done
>>> by flash tool. Remote platform dialog is completely useless for this. I
>>> would like to provide flash tool in a module, so user should just select
>>> correct tool and not path to it.
>>> It seems like extending of org.netbeans.modules.nativeexecution.api.NativeProcess
>>> and org.netbeans.modules.nativeexecution.api.ExecutionEnvironment is
>>> good idea, but they are so tightly coupled to SSH... Executing the
>>> application on bare metal is something between isLocal() and isRemote() in
>>> sense of NetBeans CND.
>>> How to correctly hook to "Run" event and execute the loader? Using own
>>> ExecutionEnvironment? How to force own ExecutionEnvironment in the CND
>>> project?
>>>
>>> Debugger:
>>> Again, it is something between local and remote debuging in sense of
>>> NetBeans CND. I'm using OpenOCD as "gdb remote" but it is possible to run
>>> it using pipes, not tcp ports.
>>> OpenOCD is executed by the IDE so no need to run anything manually. Just
>>> press "debug button".
>>> In conjuction with OpenOCD, some commands are missing. E.g. it is not
>>> possible to execute gdb command "-exec-run", but instead, just
>>> "-exec-continue" is supported.
>>> There is need to chain some commands to standard debug commands e.g.
>>> "monitor reset run", "monitor reset halt", ...
>>> There is also need to preload the program to the device by external
>>> command before debug (same as running the code)
>>> How to correctly hook to these events without changing or reimplementing
>>> org.netbeans.modules.cnd.debugger.gdb2.GdbDebuggerImpl?
>>>
>>> Any ideas are welcome.
>>>
>>> Best regards,
>>> Jan Breuer
>>>
>>>
>>>