Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
EmBitz pros and cons
#1
EmBitz is great for fast development of embedded projects but there are some shadows...

I compared EmBitz with Code::Blocks-16.01 and GnuMcuEclipse and found some good and some weak points:

First the good ones:
+ It is very fast. Loads a lot faster then C::B and Eclipse and project build is faster then GnuMcuEclipse
+ Very good support for many embedded plattforms compared to C::B. GnuMcuEclipse also has good Cortex-M support
+ Good integration of embedded debugging compared to C::B. GnuMcuEclipse also has good embedded debugging support

And now the shadows:
- The compiler is totally outdated.
- The support of different compilers is very bad compared to C::B
- It seems that the development is stalled



It would be nice to merge the strength of C::B (Compiler-Support) and EmBitz(plattform-support and debugger-integration)  to get a better version of EmBitz. And i think with a move to soucreforge or github there would be a chance to get more developers for active development.
Greetings from Berlin

Jan Ingwer Baer
Reply
#2
- The compiler is totally outdated.

Why is 5.4 Jun 2016 totally outdated???

- The support of different compilers is very bad compared to C::B

All these features of different compilers is removed from E::B because it was a mesh under the hood. E::B isn't C::B. If you want a Swiss knife? Grab C::B. If you want a more-or-less out of the box embedded IDE then take E::B.

C::B and E::B also will never merge because they are totally different under the hood. The E::B project is much more than only the IDE. Also GDB is totally tailored (e.g. live variables, placing the PC at source line ).
Reply
#3
compiler-version:
  current version of gcc-arm-embedded is 6.3.1 Jun 2017. for me 1 year is outdated.

support for different compilers:
  what i miss in E::B is :
  - the option to define additional compilers to use different version of gcc or alternative clang/llvm
  - the option to edit the compiler-options like the compiler-settings in C::B
Greetings from Berlin

Jan Ingwer Baer
Reply
#4
(29-07-2017, 03:12 PM)jibaer Wrote: EmBitz is great for fast development of embedded projects but there are some shadows...

I compared EmBitz with Code::Blocks-16.01 and GnuMcuEclipse and found some good and some weak points:

First the good ones:
+ It is very fast. Loads a lot faster then C::B and Eclipse and project build is faster then GnuMcuEclipse
+ Very good support for many embedded plattforms compared to C::B. GnuMcuEclipse also has good Cortex-M support
+ Good integration of embedded debugging compared to C::B. GnuMcuEclipse also has good embedded debugging support

And now the shadows:
- The compiler is totally outdated.
- The support of different compilers is very bad compared to C::B
- It seems that the development is stalled



It would be nice to merge the strength of C::B (Compiler-Support) and EmBitz(plattform-support and debugger-integration)  to get a better version of EmBitz. And i think with a move to soucreforge or github there would be a chance to get more developers for active development.

(29-07-2017, 06:36 PM)jibaer Wrote: compiler-version:
  current version of gcc-arm-embedded is 6.3.1 Jun 2017. for me 1 year is outdated.

support for different compilers:
  what i miss in E::B is :
  - the option to define additional compilers to use different version of gcc or alternative clang/llvm
  - the option to edit the compiler-options like the compiler-settings in C::B

For me, using it for consultancy projects, 1 year is not old and I don't switch easily from chain number without knowing the implications first. I don't want to struggle with tools if I'm doing a job that's why I started this whole project in the first place.

E::B tries to give a sort of uVision/workbench user experience  and not  a C::B experience, that's why the name changed from EmBlocks to Embitz.
For those users who need C::B features it's better actually to use C::B, I think. C::B is aiming a different type of audience.
Reply
#5
I am totally with Gerard in this. Reliability and predictability are must requirements. Let somebody else find the bugs in the new versions and new drivers before using them in any serious work. I would like to say "it just works" and "it works very fast".
Cheers, Ollie
Reply
#6
I must say, I join ranks w. Gerard and Ollie.
The latest is NOT the greatest. There are tons of FW and boot loaders that don't build reliable w. gcc > 4.8
We are doing embedded stuff, not a new Linux Kernel, hence reliability will always be our primary focus.
LLVM is of cause very desirably. but until one can build a working FW for airspy or a Maple Mini Boot Loader for a trivial STM32F103xB,
then gcc 4.8.4 as packed with E::B 0.42 will remain my first choise

Sincerely / 73 es dx
Tim / OZ4GA
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)