Embitz is coming back soon

[splin]

The Code::Blocks based IDE Embitz is one I rather like because it is lightning fast in comparison to Eclipse based products. It supports quite a variety of ARM devices but I have only used it for ST devices. The main problem is that it is developed by one man with other work commitments so although he was very responsive on the forums, new releases stalled.

Unfortunately the server, www.embitz.org went down a year or so ago when it was being updated and apparantly all backups were lost including all the forum posts.     

However the good news is that I just found that V2.0 is supposed to be coming soon and better still the source code is to be released: https://github.com/EmBitz

The source for EBlink, a replacement for the GDBServer has already been released. This has the advantage over GDBServer that is a lot faster and it supports live memory/variable watches.

[poorchava]

I have used it in the past and indeed, is was very fast. On the downside it has some weird quirks, like the fact that I could never get the 'go to definition', ' go to declaration' or 'find usages' to work to any meaningful degree (and I am usign those functions alot).

Also, the support list of chips was quite poor. Actually most free/open source/entry range IDEs have this problem. One notable exception to thise seems to be VisualGDB, which was adding support for new chips pretty fast.

Unfortunately, unless you are paying big bucks for something like Keil, Rowley, IAR etc, and want to use latest and greatest chips (i often have to in my field of work) you are bound to use manufacturer's IDE (unless they don;t have one, in which case you don't use their stuff)

[nctnico]

Why would you need 'support for a new chip'. A new chip just uses a bunch of header files which you can copy into your project. Maybe add the memory settings to a config file for programming but that is it. No need to rely on vendor IDEs at all.

[tszaboo]

I've met the guy behind Embitz. Dutch guy, he worked for us as a consultant briefly. Probably one of the big mistake we made to use that IDE for our projects. The guy doesnt believe in RTOSes and therefore it is not really supported in Embitz. Other weird stuff. My suggestion is to stay clear.

[poorchava]

Why would you need 'support for a new chip'. A new chip just uses a bunch of header files which you can copy into your project. Maybe add the memory settings to a config file for programming but that is it. No need to rely on vendor IDEs at all.

That would be true, if you wrote software using registers only. We actually rely heavily on code generation tools for the microcontrollers we use, and operate on registers only when it is necessary. Also, cobbling together toolchains from bits, some headers from the internet, tools from different providers etc universally generates weird problems.

In principle you could use Notepad++ to write code, command line to compile using gcc, debug in console using OpenOcd or whatever and write it in assembly. But you don't and use more advanced tools to save time. If IDEis missing support for something we need supported, we don't that IDE because we don;t want to spend time on fiddling, but on producing useful code.

[MT]

I've met the guy behind Embitz. Dutch guy, he worked for us as a consultant briefly. Probably one of the big mistake we made to use that IDE for our projects. The guy doesnt believe in RTOSes and therefore it is not really supported in Embitz. Other weird stuff. My suggestion is to stay clear.

Interrupts can be seen as a simple RTOS. Strange that people should stay clear from a tool that cost zero dullars!?

Support of new chips i recall reading the forum back then was sometimes a ST Link issue as people asked for being able to create support for new chips them selfs when Gerard didnt have time for it.

[SiliconWizard]

An RTOS for MCUs is also basically a library; I'm not sure what specifics you would need in an IDE to support it.
I guess this is also about automatic code generation or something.

So regardless of the relevance itself of using code generation tools, if you need one embedded in your IDE, obviously said IDE would need one. If not, then, you guessed it... So yeah that doesn' make it useless or to stay away from. That just makes it a tool that wouldn't fit someone's specific requirements.

[Mr. Scram]

Interrupts can be seen as a simple RTOS. Strange that people should stay clear from a tool that cost zero dullars!?

Support of new chips i recall reading the forum back then was sometimes a ST Link issue as people asked for being able to create support for new chips them selfs when Gerard didnt have time for it.

A tool costing "zero dullars" can be very expensive.

[SiliconWizard]

A tool costing "zero dullars" can be very expensive.

Maybe. My "dullars" are more expensive than yours. There!

[poorchava]

I think the original phrase was 'Linux is free is your time is worth zero'.

For hobby ise, if writing code from scratch is the goal in itself - it's fine. For commercial use -no.

What's the point of having free IDE for STM32, if STM32 has specific IDE that is full of features and is free. Also STM32 are one of the most cost effective end extensive uC families out there. Maybe Gigadevice or Nuvoton are cheaper, but from mainstream brands STM32 are the best overall (IMO, having tried AVR, Atmel ARMs, different PICs, C2000, MSP430, Cypress). Also the management loves full featured tools that are dedicated and free and they don't have to book time for cobbling toolchain together.

[nctnico]

Why would you need 'support for a new chip'. A new chip just uses a bunch of header files which you can copy into your project. Maybe add the memory settings to a config file for programming but that is it. No need to rely on vendor IDEs at all.

That would be true, if you wrote software using registers only. We actually rely heavily on code generation tools for the microcontrollers we use, and operate on registers only when it is necessary. Also, cobbling together toolchains from bits, some headers from the internet, tools from different providers etc universally generates weird problems.

I never said to gobble something together. In my experience it is often quicker to get a piece of proven code (library) in place OR write to the registers directly (create my own driver). The latter also depends on which manufacturer you are using. ST is big mess where it comes to consistency between the various devices. Relying on code from vendor tools often means debugging/understanding someone else's code and wasting even more time. And under the hood most vendors use GCC (or the more modern equivalent) so in the end you don't really gain much by paying for an IDE. Same tools with some sauce on top. Over the past decades I have used many vendor provided IDEs. Most where just annoying and none managed to impress me the slightest. But even if you want to use a vendor specific IDE the device definitions usually can be edited / added somehow in a configuration file. Been there / done that.

[tszaboo]

I've met the guy behind Embitz. Dutch guy, he worked for us as a consultant briefly. Probably one of the big mistake we made to use that IDE for our projects. The guy doesnt believe in RTOSes and therefore it is not really supported in Embitz. Other weird stuff. My suggestion is to stay clear.

Interrupts can be seen as a simple RTOS. Strange that people should stay clear from a tool that cost zero dullars!?

Support of new chips i recall reading the forum back then was sometimes a ST Link issue as people asked for being able to create support for new chips them selfs when Gerard didnt have time for it.

Well, 100% of our firmware people were unsatisfied with it, and decided to change the IDE.
Free is very expensive if you have to spend time on it.

[MT]

Well, 100% of our firmware people were unsatisfied with it, and decided to change the IDE.
Free is very expensive if you have to spend time on it.

Yeah, but "stay clear" might mean if your a company do better research into the tools your intended to use before investing in it then later discover the tool is not suitable then more for e.g hobbyists etc. Would someone invest in IAR tools sets as e.g hobbyist? Obviously not , they go for free and cheap and spend in this case EMbitz zero time as its so simple.

If the goal is to hit nails in a plank one uses a decent hammer not a all "options" Swiss army knife!

[tszaboo]

Well, 100% of our firmware people were unsatisfied with it, and decided to change the IDE.
Free is very expensive if you have to spend time on it.

Yeah, but "stay clear" might mean if your a company do better research into the tools your intended to use before investing in it then later discover the tool is not suitable then more for e.g hobbyists etc. Would someone invest in IAR tools sets as e.g hobbyist? Obviously not , they go for free and cheap and spend in this case EMbitz zero time as its so simple.

If the goal is to hit nails in a plank one uses a decent hammer not a all "options" Swiss army knife!

They went with other free tools. I've seen the guy's code, he was paid to write it, quite decently.
I've also seen other people's reaction to his code, generally it was:  "WTF is this bullshit". Embitz is made by this guy, If he spends so much effort coding this, you will run into unexplained errors, and backwards thinking.

Honestly, I dont give a damn about which toolset you or others use, I said what I wanted. I'll go back and design PCBs, because software is boring anyway. Good day!

[rsjsouza]

A couple of years ago I tried to use Embitz, but it was way too simple for my taste. I tend to stick with the vendor tools and work with them in fixing issues - some are more open to suggestions than others.

Cobbling up together the tools can be quite daunting for the beginner and reminds me of the early days (1990s) of trying to get Linux working - I used to spend more time with the OS than with doing work. Over the years, however, it gets a lot easier. However, the mess can still be a problem - just look at Dave's USB supply for an example.

[MT]

They went with other free tools.

Yet another bad corporate decision!

I've seen the guy's code, he was paid to write it, quite decently. I've also seen other people's reaction to his code, generally it was:  "WTF is this bullshit". Embitz is made by this guy, If he spends so much effort coding this, you
will run into unexplained errors, and backwards thinking.

Yet again corporate decisions at fault not the dude who made it.

Honestly, I dont give a damn about which toolset you or others use, I said what I wanted. I'll go back and design PCBs, because software is boring anyway. Good day!

The angry reaction to the free tool problem! 

A couple of years ago I tried to use Embitz, but it was way too simple for my taste. I tend to stick with the vendor tools and work with them in fixing issues - some are more open to suggestions than others.

Cobbling up together the tools can be quite daunting for the beginner and reminds me of the early days (1990s) of trying to get Linux working - I used to spend more time with the OS than with doing work. Over the years, however, it gets a lot easier. However, the mess can still be a problem - just look at Dave's USB supply for an example.

Are you accusing DAVE J for being a sloppy engineer?

This thread have derailed, from being "horray EmBitz back" to "Embitz is sour grapes"! lol..

[edigi]

I'm surprised to see so many negative comments that Embitz is back.

It's a great tool for the hobbyists. Fast and free (it's so much faster than Eclipse based products). If you're a hobbyist, give it a chance.
Surely not for everybody, definitely not for professional use (who do this kind of SW development for a living) as it may lag support for the latest and more powerful HW.
It can be used via Wine in Linux as well, however it requires running the GDB server separately (you need to tick the "don't start the GDB server automatically" option and set IP/port).
I'm very thankful for the autor that it's still not abandoned after the unfortunate server failure.
I'm definitely in the hooray EmBitz back camp (despite that STM is not much in my focus).

[splin]

A couple of years ago I tried to use Embitz, but it was way too simple for my taste.

'way too simple' is a pretty strong level of dissatisfaction; do you mind me asking what were the major shortcomings for your needs? It does have many bugs, quirks and limitations but I'm not sure I'd describe them as 'way too simple' but that probably reflects my lack of exposure to full featured commercial products. I'm guessing that configuration management is a problem area?

[EmBlocks]

I've met the guy behind Embitz. Dutch guy, he worked for us as a consultant briefly. Probably one of the big mistake we made to use that IDE for our projects. The guy doesnt believe in RTOSes and therefore it is not really supported in Embitz. Other weird stuff. My suggestion is to stay clear.

No, I don't believe that you need a RTOS in every project. However, RTOS can be useful that's why I made a OS debug plugin which supports FreeRTOS and CHhibOS, because I used them for some projects. Very weird indeed 

Well, 100% of our firmware people were unsatisfied with it, and decided to change the IDE.
Free is very expensive if you have to spend time on it.

Yip that was the very cooperative mood over there.  Cadence was not good, it should be Altium. The color of the multimeter was not good, the scope was not good. Even the country sucks. 

They went with other free tools. I've seen the guy's code, he was paid to write it, quite decently.
I've also seen other people's reaction to his code, generally it was:  "WTF is this bullshit". Embitz is made by this guy, If he spends so much effort coding this, you will run into unexplained errors, and backwards thinking.

   (p.s. the only working product of IMT finished in time)

Honestly, I dont give a damn about which toolset you or others use, I said what I wanted. I'll go back and design PCBs, because software is boring anyway. Good day!

Man, this is deep isn't it. What an emotion

Well, to be honest. I made the tool for my self and let others enjoy. If they don't like it, totally fine. Install Eclipse (also GCC) and you are up and running in less than an hour. No excuse that it would cost you a lot of money. If you have the time to read and write in this forum, then time is no problem.

Apparently, Embitz is appealing to some people because I still get a lot of  requests by email. If Siemens is using it by their tutors and the DLR for some projects then I guess that some parts are working.

I also wrote a new GDB server with squirrel scripting support https://github.com/EmBitz/EBlink. Perhaps something for IMT?

EDITED TO REMOVE PERSONAL INFO

[Marchello]

Hello EmBlocks!

Thanks so much for your work!

Do not listen to grunts, you have a great tool!
We use EmBlocks for professional development (for a hobby, too) and have no serious problems with this.

We look forward to the new version.

Good luck!
Mark

[LogicalDave]

I've met the guy behind Embitz. Dutch guy, he worked for us as a consultant briefly. Probably one of the big mistake we made to use that IDE for our projects. The guy doesnt believe in RTOSes and therefore it is not really supported in Embitz. Other weird stuff. My suggestion is to stay clear.

I respectfully, but completely disagree.  I have been using EmBitz for several years and it is rock solid and lightning fast.  I am not using it with an RTOS, but for bare-metal C it rocks.  The author was very responsive (before his site went down) and the product is excellent, I am anxiously awaiting the 2.0 product and will most certainly purchase it.

[Bud]

Did not know what embitz is, typed in google, followed the first link that took me to embitz.org. There was Nothing there saying What embitz is,  just that a new version is available. That was weird, i think the author could spend 0.1 min writing a line on the web page as to What that thing is.

[LogicalDave]

I agree, it is a little strange that he hasn't updated his web page even with a static page, but he provides this for free and is just one person with a day job, so totally understandable.  You can still download the latest version (1.11) from the home page www.embitz.org (the links says 1.10 but the downloadis 1.11.zip).

EmBitz is a fork of Code::Blocks.  It is a fast, lightweight C/C++ IDE that is meant for embedded development.  What makes it so appealing (besides being fast, solid, and intuitive), are

• Project wizards which can help new users get up and running quickly
• Excellent GDB and STLinkV2 integration

 
If you are new to STM32, STLinkV2 is a very low cost (less than $10) USB hardware debug interface that allows you to program your target hardware easily and do source-level debugging (setting breakpoints, stepping through code, examining variables, etc.).  EmBitz integrates all of this functionality smoothly (using GDB without EmBitz is much less pleasant).

It has many smaller features that are also very useful such as a text debug interface that allows you to send print statements over the debug interface without using a serial port.  If you do much embedded development on the STM32 platform (or the other supported platforms), EmBitz is the smoothest IDE I've found and it's well worth checking it out.

[hryu]

Hello EmBlocks!

Thank you very much for EmBitz!
I am using it for 3 years already, I have used a lot of other tools before (IAR, Keil, Eclipse-based from different MCU manufacturers), but your EmBitz is the best one and free! I am waiting for the new version already and hope to support your work after getting it.
EmBitz is the fastest IDE ever and has all things I need for development. Maybe just better FreeRTOS and SVD support could improve it.

Thank you for your work!

[Psi]

+1 person using emBitz.

It was the first IDE i found that was
A) Free
B) Worked on a STM32 discovery board right out of the box without having to mess with makefiles.
(not saying there aren't others, but it was the first one i found that worked well, so i stuck with it)