Donation

[TimVosch]

Hey navnavnav,

Thanks for the project.

Bloom just helped me fix a bug on the attiny1616 and I am sure I am gonna use Bloom more in the future.
Is there a way I can buy you a coffee :)?

[navnavnav]

Hi Tim!

It's really good to hear that Bloom helped you. It makes my day.

RE donations; Thank you! That's very kind of you, but I don't have any means to receive donations ATM. And in all honesty, I would prefer that you just keep using Bloom and help spread the word about it. The more users we have, the better Bloom will become. I really appreciate users who report issues or provide suggestions and feedback. That information is invaluable to me.

So if you know any other embedded engineers who use (or wish to use) Linux as their development platform, feel free to introduce them to Bloom 😃

Thanks,
Nav

[TimVosch]

Not having to run microchip studio on a separate windows VM is amazing. I've already introduced my co-worker to Bloom ;)

I haven't walked into any bad bugs yet, but if I find anything I'll let you know. Keep up the awesome work.

Cheers,
Tim

[septatrix]

Out of curiosity: Is this just some project you work on in your free time or do you need this for work and get to track it as company time? It seems like you are investing a good chunk of time into Bloom and I am incredibly grateful for it :D

[navnavnav]

Hi @septatrix

I only work on Bloom in my spare time. This is why development can be a bit slow at times. It's a passion project for me - I really enjoy working on it so I choose to spend most of my free time on it.

The goal is to serve the Linux community by filling a void that has been a void for far too long. As a long-time Linux user, I find it increasingly frustrating when I'm told to "just use Wine" or "just use a VM" by others. Both solutions are frequently inadequate and frustrating. I suspect that, because of this, Linux (as a development platform) isn't a popular choice for many embedded engineers. For me, changing this would be a dream come true.

I hope that at some point, Bloom will serve as the go-to option for debugging embedded systems on a Linux development platform. There's still a way to go, but I feel like it's moving in the right direction.

I should also add that Bloom wouldn't be possible without the documentation published by Atmel and now Microchip. IMO it's a practice that should be encouraged, as everyone benefits. Let's hope they publish the MPLAB ICE 4 protocol documentation soon 😄. I'm looking forward to implementing that driver.

Thanks,

[septatrix]

The goal is to serve the Linux community by filling a void that has been a void for far too long. As a long-time Linux user, I find it increasingly frustrating when I'm told to "just use Wine" or "just use a VM" by others. Both solutions are frequently inadequate and frustrating. I suspect that, because of this, Linux (as a development platform) isn't a popular choice for many embedded engineers. For me, changing this would be a dream come true.

Yes I feel your frustration. Our struggle with existing solutions is the bad support for remote development.
The implementation in Microchip Studio is abysmal... It is implemented synchronously in the rendering/main thread so even with small latency it is very sluggish and a connection drop simply freezes the IDE. Apart from that atbackend.exe still has to run on a windows host so this is unusable for e.g. a small Raspberry Pi with a debug probe attached.
MPLAB X IDE has a remote plugin which apparently has a server part which can run on Linux but you have to buy a license to use that plugin.

I hope that at some point, Bloom will serve as the go-to option for debugging embedded systems on a Linux development platform. There's still a way to go, but I feel like it's moving in the right direction.

In the AVR space you are definitely getting there! ARM boards mostly have good tooling with OpenOCD et al though for AVR there was nothing for a long time apart from AVaRICE which is not really developed anymore. So I view Bloom as a spiritual successor to that.