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 <emilian.b...@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 <jan.bre...@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
