Author Topic: code::blocks::embedded  (Read 33588 times)

Offline etg

  • Multiple posting newcomer
  • *
  • Posts: 15
code::blocks::embedded
« on: September 21, 2010, 07:01:55 pm »

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: code::blocks::embedded
« Reply #1 on: September 21, 2010, 09:13:13 pm »
www.embtechgroup.eu/cbe.jpg
...what do you want to tell us with this? Where is the official page, is it Open Source, does this "product" comply with GPL?
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline etg

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: code::blocks::embedded
« Reply #2 on: September 21, 2010, 09:35:26 pm »
Rather I want to know how can post modifications required for me to be included in future C::B releases ? Do you have some comittee that approves these changes or better to create new branch ?

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: code::blocks::embedded
« Reply #3 on: September 21, 2010, 09:46:41 pm »
if you have changes, improvements, bug fixes, new features, you can provide them as a patch, together with an explanation on the what/how/why.
Preferably in little packets, which are easy to grasp. And if we agree, we will merge it into our code base. All contributions are very welcome.

Offline etg

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: code::blocks::embedded
« Reply #4 on: September 21, 2010, 09:54:16 pm »
any my changes was based on C::B 8.2 release. Bit old.

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: code::blocks::embedded
« Reply #5 on: September 21, 2010, 09:56:05 pm »
that's indeed a bit problematic. Do you think you could redo them on the current svn versions ?

Maybe for starters could you list the things you changed/enhanced, so we have an idea.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: code::blocks::embedded
« Reply #6 on: September 21, 2010, 09:59:09 pm »
Do you have some comittee that approves these changes or better to create new branch ?
The committee are we (the developers and the community). A new branch like the debugger branch is possible, whenever it makes sense. E.g. modifications of the core or core plugins where everybody would benefit.

In this case I think creating a branch from trunk would heavily conflict with the debugger branch. I would therefore suggest you contact the "maintainer" of the debugger branch, namely "oBFusCATed" (http://forums.codeblocks.org/index.php?action=profile;u=1071) and you try to combine both approaches. Otherwise it will be very hard to merge the two approaches in the end. What do you think? Are you aware of that branch? What's the base of your code (is it trunk or the debugger branch already)?!
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline etg

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: code::blocks::embedded
« Reply #7 on: September 21, 2010, 10:06:44 pm »
Base of code for C::B(SDK) was source full package 8.2. Debugger is quite different approach - does not uses GDB.EXE

mariocup

  • Guest
Re: code::blocks::embedded
« Reply #8 on: September 21, 2010, 10:22:03 pm »
Hi etg,

I had a look at your screenshot and it looks like a great improvement for embedded programming. I hope that some of the modifications could be integrated in the current version.


Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: code::blocks::embedded
« Reply #9 on: September 21, 2010, 10:25:32 pm »
So you've written a new plugin?
What is based on?
Does it work on linux/mac (can it be ported)?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline etg

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: code::blocks::embedded
« Reply #10 on: September 21, 2010, 10:29:32 pm »
Screenshot is nice but it is from very weak development version. It takes some time yet to get it stable. For now if you want I can provide more screenshots until code will be released.

Offline etg

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: code::blocks::embedded
« Reply #11 on: September 21, 2010, 10:32:06 pm »
Plugin is not portable for now and is running on Windows only.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: code::blocks::embedded
« Reply #12 on: September 21, 2010, 10:34:51 pm »
It is better to provide some code in the beginning, so we can see the direction you're going.
Reviewing large patches is hard and error prone.

What debugger you're using?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline etg

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: code::blocks::embedded
« Reply #13 on: September 21, 2010, 10:39:22 pm »
libgdbXXX.dll XXX - mean target CPU variant abbreviation

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: code::blocks::embedded
« Reply #14 on: September 21, 2010, 10:51:03 pm »
Where do you get that lib?
As far as I know it is old and not supported gdb subproject.
The official and supported way to communicate with GDB is through the GDB/mi command line protocol.

Please take a look at the debuggers branch, there the sdk is improved in regard to the debugger.
Most of the GUI is extracted from the plugin debuggergdb and, so all debuggers can use it.
It is not finished and patches, and suggestions are warmly welcomed, especially about the API.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline etg

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: code::blocks::embedded
« Reply #15 on: September 21, 2010, 11:01:38 pm »
simply get the GDB source package and you develop until you get something usable. So if want to get output from command e.g. "info locals" you can split it into several libgdbXXX.dll calls create you own API and use it for your plugin. Solutions which parsing some output from other processes does not like for me and much more in case of debugger.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: code::blocks::embedded
« Reply #16 on: September 21, 2010, 11:07:33 pm »
So this is your independent lib based on the sources of gdb?

I don't like this parsing, too, but it is the only long term solution for using gdb.
The llvm's debugger will be lib based which is good :)
« Last Edit: September 21, 2010, 11:10:10 pm by oBFusCATed »
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline etg

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: code::blocks::embedded
« Reply #17 on: September 21, 2010, 11:14:24 pm »
libgdbXXX.dll + libAPI.dll + C::B related work = debugger plugin
also usable as the libgdbXXX.dll + stub  = GDB.EXE

Upon target device selection for a project can in future use different variants of libgdbXXX.dll as ARM, MIPS, SUPERH etc.

I agree that in open world is quite hard to maintain such kind of code

Offline etg

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: code::blocks::embedded
« Reply #18 on: September 21, 2010, 11:49:26 pm »
I just want to ask how far is the time when your C::B turns into commercial edit ?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: code::blocks::embedded
« Reply #19 on: September 21, 2010, 11:58:16 pm »
What exactly do you ask?

1. If some company will buy C::B and thus C::B becomes a proprietary software?
2. If C::B will catch the commertial IDEs (like VStudio)?

1. never
2. it depends on the user's contrubution I think :), btw in some areas it is ages in front of VStudio, in some it is quite behind...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline etg

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: code::blocks::embedded
« Reply #20 on: September 22, 2010, 12:05:18 am »
1. sounds line SOCIALISM past 20 years in eastern EUROPE where nobody owned nothing
2. incomparable motivation  :(
3. what are then the DONATIONS on your C::B page ?

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7582
    • My Best Post
Re: code::blocks::embedded
« Reply #21 on: September 22, 2010, 04:19:49 am »
I just want to ask how far is the time when your C::B turns into commercial edit ?

I suggest you read up an the GPL; turning an GPL program into an commercial program is not easy/legal/possible by anyone but the copyright owner.
And, with the copyright being owned by multiple people is likely impossible.
http://en.wikipedia.org/wiki/Gpl

And, since it is an open source license; there would be a fork by any developer/user who wanted to fork it.

Tim S.
« Last Edit: September 22, 2010, 04:24:42 am by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline etg

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: code::blocks::embedded
« Reply #22 on: September 22, 2010, 08:00:03 am »
On what conditions can be plugins kept closed source ?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: code::blocks::embedded
« Reply #23 on: September 22, 2010, 11:51:32 am »
etg: It was communism not socialism :)

I think the license for the SDK is GPL 3, so if you distribute the plugin you should provide
the source to the person your are distributing the plugin (he/she can pay you for plugin, it is not forbidden by the license).

Probably this could shed some light: http://www.gnu.org/licenses/gpl-faq.html
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: code::blocks::embedded
« Reply #24 on: September 22, 2010, 01:01:56 pm »
etg: It was communism not socialism :)

I think the license for the SDK is GPL 3, so if you distribute the plugin you should provide
the source to the person your are distributing the plugin (he/she can pay you for plugin, it is not forbidden by the license).

Probably this could shed some light: http://www.gnu.org/licenses/gpl-faq.html

The license on the CB SDK is not GPL 3. Its LGPL 3, which allows commercial ownership and distribution.

Code
/*
 * This file is part of the Code::Blocks IDE and licensed under the GNU Lesser General Public License, version 3
 * http://www.gnu.org/licenses/lgpl-3.0.html

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7582
    • My Best Post
Re: code::blocks::embedded
« Reply #25 on: September 22, 2010, 03:56:40 pm »
Per Pecan, Since Code::Blocks uses the LGPL 3 making an close source plugin for Code::Blocks allowed.
Note: The close source plugin (Binary) for Code::Blocks must NOT contain static linked code compiled from GPL or LGPL source code(Without permission from Copyright Owner); it can link to the Code::Blocks SDK (Since it is Licensed under LGPL).

I am not a lawyer; and I am not an expert on Code::Blocks or the GPL/LGPL. But, I have read discussions on both.

« Last Edit: September 22, 2010, 05:05:24 pm by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline etg

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: code::blocks::embedded
« Reply #26 on: September 22, 2010, 05:01:39 pm »
Who is aware of any commercial derivatite of C::B or plugin for C::B ?
I think would be better not to allow fully closed source but everybody should provide some useful part not whole (depends) from code for future integration in C::B in case commercial onwership of such release.

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7582
    • My Best Post
Re: code::blocks::embedded
« Reply #27 on: September 22, 2010, 05:13:06 pm »
There was about two years back an Site that was using Code::Blocks as the IDE for their embedded hardware; not sure if it counts as an commercial product. Edit: I think they are selling it; do not really read the website enough to confirm it.
I think they was including Code::Blocks for free. They might have had some custom plugins for C::B.

I can not remember their name right now.
Found a possible match
http://imagecraft.wordpress.com/2009/10/20/next-gen-ide-codeblocks-pre-alpha/

Tim S
« Last Edit: September 22, 2010, 07:18:09 pm by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline pfong

  • Multiple posting newcomer
  • *
  • Posts: 14
Re: code::blocks::embedded
« Reply #28 on: September 22, 2010, 06:25:21 pm »
Does code::blocks use the GDB mi interface in the debugger branch?  This would probably be better than the current stdin/stdout redirection method since it let's you interact with GDB while the debugee is running and you can stop individual threads.

Also, I think it is better to use a separate GDB rather than a custom library.  This way you can build/get GDB for whatever target you are using rather than trying to adapt and recompile a custom library.

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7582
    • My Best Post
Re: code::blocks::embedded
« Reply #29 on: September 22, 2010, 07:20:17 pm »
Also, I think it is better to use a separate GDB rather than a custom library.  This way you can build/get GDB for whatever target you are using rather than trying to adapt and recompile a custom library.

I do NOT use debugger; but, I believe Code::Blocks has always used a separate GDB.

Edit: @pfong, you do realize this this thread is about an outside developer creating a project using parts of Code::Blocks.

Tim S.
« Last Edit: September 22, 2010, 07:28:45 pm by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: code::blocks::embedded
« Reply #30 on: September 22, 2010, 07:41:06 pm »
Does code::blocks use the GDB mi interface in the debugger branch?  This would probably be better than the current stdin/stdout redirection method since it let's you interact with GDB while the debugee is running and you can stop individual threads.
No, it uses the normal interface. I've a plugin that uses the MI interface but it is not very usable at the moment.
Also the MI interface is using the same stdin/out redirection.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline etg

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: code::blocks::embedded
« Reply #31 on: September 22, 2010, 08:39:03 pm »
I will provide the C::B::E + DEBUGGER PLUGIN for ARM NXP CORTEX M3 family development for download at right time when will be sure it is stable for user. The C::B::E (SRC+BIN) will of course free for everyone and about DEBUGGER PLUGIN not decided at this moment. The demonstration package will run DEBUG TARGET - ARM V7 SIMULATOR (not included in neither official GDB distribution). Other target requires real ARM V7 hardware debugger available via ETG site.
Significant difference of DEBUGGER PLUGIN is that allows download multiple executables (ELF) into target.
If we decide to not provide DEBUGGER PLUGIN for FREE certainly we will provide useful source parts of DEBUGGER PLUGIN which can be turn into C::B DEBUGGER PLUGIN style. Interfacing piece of e.g. MEMORY window seems easy for me.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: code::blocks::embedded
« Reply #32 on: September 23, 2010, 07:45:11 am »
I just want to ask how far is the time when your C::B turns into commercial edit ?
Basically it can't, as we setup the license not to allow this.

1. sounds line SOCIALISM past 20 years in eastern EUROPE where nobody owned nothing
[...]
3. what are then the DONATIONS on your C::B page ?
1.) ??? I don't get what you mean by that.
3.) They are for e.g. server costs etc.. Not everything is for free, you know. We have quite some traffic and webspace / content which needs to be paid as we are running a dedicated server for this. And I can assure you that the donations are not even enough for that. :(

I will provide the C::B::E + DEBUGGER PLUGIN for ARM NXP CORTEX M3 family development for download at right time when will be sure it is stable for user.
That sounds reasonable. Without looking at it it'll be hard to say how easy it can be integrated.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline martind

  • Multiple posting newcomer
  • *
  • Posts: 47
Re: code::blocks::embedded
« Reply #33 on: October 01, 2010, 12:25:47 am »
Going to gdb/mi would be better for embedded targets. In my cbmcu plugin I have to issue a "halt" command via openOCD to halt execution. I have not found a way to do this via the current exec method.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: code::blocks::embedded
« Reply #34 on: October 01, 2010, 08:41:22 am »
There is a gdb/mi plugin in the works...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline pfong

  • Multiple posting newcomer
  • *
  • Posts: 14
Re: code::blocks::embedded
« Reply #35 on: October 01, 2010, 09:19:46 pm »
Going to gdb/mi would be better for embedded targets. In my cbmcu plugin I have to issue a "halt" command via openOCD to halt execution. I have not found a way to do this via the current exec method.
oBFusCATed has fixed things in the debugger branch so that you can halt remote targets on Windows.  He has it send a console break event to the gdb console process.