EMbitz IDE lebt? Kommt bald neue Version 2.0!

[Besorgter Bitzer (Gast)]

Hallo zusammen,

stimmt es, dass es bald eine neue Version von EMBitz gibt? (2.0)?

auf deren Seite steht:

New Embitz 2.0 is coming soon, highlights:

    Hotplug menu, connect running target without stopping (and inspect 
with live variables and OS tools)
    New debug interface engine with flash erase and program menu's
    The GDB server is replaced by EBlink, already downloadable EBlink 
win32 and Linux_x86-64
    Latest GCC toolchain


https://www.embitz.org/

[Peter (Gast)]

Davon Träume ich schon lange.

Jedenfalls sind alle "Unterseiten" mal wieder erreichbar, das war über 
Wochen nicht der Fall.

Besser wäre es sowieso wenn alle Erkenntnisse und Änderungen zu 
CodeBlocks zurück fliessen würden. Dann würde es nicht wieder 2 IDE 
geben sondern nur eine die man Pflegen müsste. Bei CodeBlocks gibt es 
einiges was ich vermisse, was EMblitz aber kann. Nur als Beispiel der 
Program RESET unter dem Debugger.

Von mir aus dürfte der Typ hinter EMblitz seine Plugins ja weiter Closed 
lassen nur es sollte mal weiter gehen.

[Peter (Gast)]

Achtung!!!

Seit ca. 3 Stunden ist der Code Online!

Ich kann den nur nicht selber prüfen.

[A. F. (artur-f)]

Besorgter Bitzer schrieb:
> stimmt es, dass es bald eine neue Version von EMBitz gibt?

Was ist Embitz besser als an Atollic? Sorry, kenne mich mit der IDE 
nicht aus.

[Peter (Gast)]

Atollic kenne ich persönlich nicht, aber das wird auch eine IDE sein wie 
viele Andere auch. Mal muss man bezahlen mal nicht, mir sind die freien 
nur immer lieber. Auch wenn ich IAR & Keil Systeme habe.

EMbitz kommt aus den Quellen von CodeBlocks uns ist eine recht guter 
Editor.
Dazu kommt ein gutes Debugger verhalten.
Es wird bestimmt noch bessere geben, aber mir persönlich gefällt der 
sehr gut. Ist halt immer Ansichtssache.

[Frank M. (ukw) (Moderator)]

A. F. schrieb:
> Was ist Embitz besser als an Atollic?

Embitz braucht wesentlich weniger Resourcen als die auf Eclipse 
aufsetzende Atollic-IDE. Auch auf schwächeren PCs ist Embitz innerhalb 
weniger Sekunden gestartet und man kann direkt loslegen. Von der 
Funktionalität vollkommen ausreichend. Der Editor ist in weiten Teilen 
konfigurierbar und unterstützt auch bei der Auswahl von bereits 
definierten Symbols.

[A.D.K. (Gast)]

Frank M. schrieb:
> Embitz braucht wesentlich weniger Resourcen als die auf Eclipse
> aufsetzende Atollic-IDE

Meinst Du generell, dass Eclipse nicht so gut zum Programmieren geeignet 
ist?

[Klaus (Gast)]

Eclipse ist mit eine der schlimmsten Programmierumgebungen die es gibt
Fett, langsam und umständlich.
Gut das ist meine Meinung.
Muss mich an der Arbeit damit quälen!

Emblitz ist ganz gut,  aber es gibt auch noch andere die gut sind.

[A. F. (artur-f)]

Klaus schrieb:
> Eclipse ist mit eine der schlimmsten Programmierumgebungen die es gibt
> Fett, langsam und umständlich.
> Gut das ist meine Meinung.
> Muss mich an der Arbeit damit quälen!

Kann ich nicht bestätigen, habe auf Arbeit ein HP Notebook 4 Jahre alt 
Atollic läuft schnell und gut. Starten natürlich nicht so schnell wie 
Notepad++ :). Starte es eher aber nur am Monatg und der Rechner läuft 
bis Freitag durch.

[Peter (Gast)]

Ich glaube das  Frank M. und Klaus mehr damit meinen das die ganzen 
Eclipse basierenden Systeme je nach PC etwas langsamer sind und auch 
teilweise kompliziert ist neue Funktionen dazu zu laden.

Ich selber kenne Eclipse auch gut und kann die ganzen Probleme auch sehr 
gut nachvollziehen. Viele Hersteller nehmen das halt und basteln Ihre 
Plugins und Skins dafür, dann wird ein Paket daraus gemacht und man hat 
etwas "eigenes".

Aber wenn schon was JAVA basierent dann NetBeans, ist sehr schnell und 
kann recht viel. Aber ist nicht für alles geeignet.

Aber für mich und viele andere ist EMbitz halt ein gutes System und wir 
würden es vermissen. Darum warten wir auf eine neue Version.

[A.D.K. (Gast)]

A. F. schrieb:
> Starten natürlich nicht so schnell wie
> Notepad++

Ich habe mal geschaut - kann man bei dem Notepad ++ auch 
Hexadezimaldateien angucken?

[Thommy (Gast)]

>Ich habe mal geschaut - kann man bei dem Notepad ++ auch
>Hexadezimaldateien angucken?

Ja, es gibt da ein Hex-Editor Plugin für Notepad++

[Name (Gast)]

Die Veröffentlichung von EmBitz 2.0 ist verzögert.
Vor ein paar Tagen gab es jedoch ein Update 
https://www.embitz.org/forum/thread-12.html

[Frank M. (ukw) (Moderator)]

Name schrieb:
> Die Veröffentlichung von EmBitz 2.0 ist verzögert.
> Vor ein paar Tagen gab es jedoch ein Update
> https://www.embitz.org/forum/thread-12.html

Das sieht mir eher nach einem Update eines Users aus, nicht nach einem 
Update vom EMBitz-Autor.

[Anderer Bitzer (Gast)]

Ich mach hier mal weiter...

Ist das ganze Projekt noch als seriös zu erachten?

Bei einer (neuen) Version von EBLink schlägt VirusTotal an:
https://www.virustotal.com/gui/file/c8b120440c199045915e0fe9bbb85d2277e415e7996268b5255b5d23a34f6711/detection

Ich würde ja gerne den Autor direkt darauf hinweisen, aber die Website 
hat ja kein Impressum...

[Ben S. (bensch123)]

Darf ich nur so aus OT Neugierde fragen, was die Existenzberechtigung 
und das allgemeine Interesse für diese IDE ist?

STM: STM32CubeIDE
Atmel: Atmel Studio
PIC: Name fällt mir greade nicht ein, kann die inzwischen auch AVR?
TI: Code Composer
C8051: simplicity studio

Warum soll ich da noch irgendwas von dritten zusammengeschustertes 
nutzen?

[Chris D. (myfairtux) (Moderator)]

Ben S. schrieb:
> Darf ich nur so aus OT Neugierde fragen, was die Existenzberechtigung
> und das allgemeine Interesse für diese IDE ist?
>
> STM: STM32CubeIDE
> Atmel: Atmel Studio
> PIC: Name fällt mir greade nicht ein, kann die inzwischen auch AVR?
> TI: Code Composer
> C8051: simplicity studio

Da steckt vermutlich schon eine Teilantwort drin: vier verschiedene IDEs 
für im Prinzip ein und dieselbe Sache.

Dazu kommt, dass EmBitz auch unter Linux läuft.

[Ben S. (bensch123)]

Chris D. schrieb:
> vier verschiedene IDEs
> für im Prinzip ein und dieselbe Sache.

Und wo ist da das Problem? Installiere ich halt alle vier - ist ja nicht 
so, dass ich im Minutentakt wechseln muss.

Chris D. schrieb:
> Dazu kommt, dass EmBitz auch unter Linux läuft.

Dazu kannich nichts sagen, aber laufen nicht inzwischen viele IDEs unter 
Linux? Z.B. die STM32 IDE? Die PIC IDE baut doch auf netbeans auf?

[Chris D. (myfairtux) (Moderator)]

Ben S. schrieb:
> Chris D. schrieb:
>> vier verschiedene IDEs
>> für im Prinzip ein und dieselbe Sache.
>
> Und wo ist da das Problem? Installiere ich halt alle vier - ist ja nicht
> so, dass ich im Minutentakt wechseln muss.

Jede fühlt sich aber anders an, wird anders bedient usw.
Das möchte man vermeiden, wenn es geht.

> Chris D. schrieb:
>> Dazu kommt, dass EmBitz auch unter Linux läuft.
>
> Dazu kannich nichts sagen, aber laufen nicht inzwischen viele IDEs unter
> Linux?

Manche? Ja - Alle? Nein

[Jan K. (jan_k)]

Warum zum Henker sollte ich mir 4 verschiedene IDEs antun wollen?

[jo mei (Gast)]

Ben S. schrieb:
> Warum soll ich da noch irgendwas von dritten zusammengeschustertes
> nutzen?

Sagen wir so: du benutzt weiterhin die IDE deiner Wahl und bist
glücklich, und ich verwende weiterhin das existierende EmBitz
und wenn was Neues kommt, das neue EmBitz.

Warum das so ist kannst du eventuell selbst herausfinden indem
du es ausprobierst und ggf. deine Sympathie dafür findest, oder
auch nicht.

Es soll aber auch Dumpfbacken geben die in der Verwendung von
EmBitz als IDE keinerlei Vorteile sehen bzw verspüren. Nun, die
muss es auch geben ....

[Jan K. (jan_k)]

Naja, ich habe EMBitz ausprobiert und finde es nicht schlecht.

Nutze aber sonst tatsächlich VSCode, für eben alles (auch für Python, 
für GIT, für Docker usw). Auf der Arbeit wo es nicht anders geht 
µVision.

Ob deine IDE/(oder schlauer) Editor jetzt EMBitz, Eclipse, VSCode, µV, 
VIM, was auch immer heißt ist ja egal. Ich behaupte aber mal, dass man 
einiges an Zeit braucht, bis man seine Tools wirklich beherrscht.

Und daher ergibt in meinen Augen das IDE hopping zwischen den (und das 
ist auch noch ein Punkt - der Hersteller kann machen was er will und 
lustig eigene Standards bauen) herstellerabhängigen IDEs keinen Sinn

[Peter (Gast)]

Um das hopping ein zu schränken einfach codeblocks für den Rest nehmen. 
Mehr braucht man nicht.

[Johannes S. (Gast)]

Bei den speziellen IDE der Hersteller ist das Debugging idR deutlich 
einfacher. Die Einrichtung ist meist plug & play weil nötige Treiber 
installiert werden. Bei universellen IDE muss man deutlich mehr mit den 
unzähligen Variationen aus gdbservern, OOCD, pyocd, BMP oder 
proprietären Lösungen kämpfen. Bei den Eclipse Paketen der Herstellern 
ist auch die Toolchain enthalten, das ist eine one click Installation 
wie es sich viele Einsteiger wünschen.
EmBitz hatte ich auch mal angesehen, ist sicher einfach, aber von der 
Entwicklung her eine one man show und das ist nicht gut. Es ist nicht 
Open Source und bei der rasanten Entwicklung in der µC Welt ist so ein 
Einzelkämpfer Projekt wenig zukunftssicher. Das hat jemand angefangen 
als er noch Zeit dafür hatte, jetzt muss er vermutlich Geld verdienen 
und das geht mit der 'muss kostenlos sein' Mentalität nicht mehr. Und 
alles aus der Hand geben will er auch nicht, dadurch ist sowas für mich 
keine Alternative.

Edit:
Quellen schein es doch zu geben : https://git.embitz.org/Embitz/IDE
aber nach Aktivität sieht das nicht aus.

[Gerard Z. (Gast)]

"Quellen schein es doch zu geben : https://git.embitz.org/Embitz/IDE
aber nach Aktivität sieht das nicht aus."

Hi,

Despite the fact that it looks like everything is quite, it's the silent 
before the storm. A lot of work is done in the past few months. One of 
the key thing was to finish EBlink first because that will be the 
de-facto debugger for EB. It will still be possible to use other 
GDB-servers but a lot of features are disabled such as live-variables 
and "one-click hot-plugging" where you can connect to a running target 
without stopping it and watch the live variables as it happens (also 
possible in EB 1.11 but not as one click).

The new version will be shipped with the latest Launchpad GCC and no 
longer with the EmBitz tailored GCC.

The debugger plugin is currently rewritten to support the new EBlink and 
that will be the last task before publishing.

But everything is done in spare time, so ...

[Karl (Gast)]

Wann der mal fertig wird steht noch in den Sternen, aber einen Zwischen 
Schritt gibt es immer hin. Auch wenn der ganze Teil von Hand rein 
kopiert werden muss.

Ich hoffe aber das die neue Version noch besser wird, auch wenn mir 
eigentlich nur die ganzen GCC und Prozessor Parameter fehlen. Mit dem 
Update bin ich jetzt aber schon wieder fast komplett mit meinen Wünschen 
durch.

Welche IDE ist die beste? -> Immer noch die, die man dafür hält!
Und das kann für unterschiedliche Prozessoren oder Betriebssystemen halt 
was anderes nimmt liegt halt dran das es nicht die Allgemeine IDE gibt 
die alles kann. Leider!

Ich nutze auch für fast alles CodeBlocks, aber AVR Debuggen ist damit 
echt lästig gegenüber dem Studio. PC Kram ist damit ja wieder einfach.
Für ARM Sachen dann EMblitz weil es super läuft und ich mich nichtmal an 
eine Andere IDE gewöhnen muss. Klar habe ich auch andere.

Um auf EMbitz zurück zu kommen, abwarten und die aktuelle Version 
nutzen.

[Christopher J. (christopher_j23)]

Gerard Z. schrieb:
> One of the key thing was to finish EBlink first because that will be the
> de-facto debugger for EB.

Klingt für mich so, als wöllte der Mann in Zukunft mit Segger 
konkurrieren und über seinen Debug-Adapter seine Brötchen verdienen. Ob 
das klappt? Ich habe da meine Zweifel.

[Peter (Gast)]

So weit ich das sehe läuft der segger genauso wie die st-link Teile.
Da jetzt neue Hardware zu machen lohnt sich für niemanden. Ich denke der 
würde zerrissen werden wenn man plötzlich nur noch seine Hardware 
benutzen könnte.

[Gerard Z. (Gast)]

@Christopher J
Than you definitely don't understand what this is all about :) And just 
write for the writing.

EBlink sounds as J-link and there ends the whole comparison. EBlink is a 
bit like openOCD but with a total different approach and different 
features needed for live-variable debugging and fast flashing from 
IDE's. EBlink needs hardware probes from third parties such as STlink or 
CMSIS-dap.

I understand you biasing for the German based Segger but with a 
STlink/V3 you don't need them anymore for the speed.

P.s. perhaps own hardware is not profitable but your own firmware in 
that hardware definitely is. That's why we have Ulink,STlink and so on. 
That's why CMSIS-DAP/v2 could get momentum (I hope) and to be extended 
with nice features. Something I'm very anxious to start with as soon as 
I have the time.

[Christopher J. (christopher_j23)]

Gerard Z. schrieb:
> I understand you biasing for the German based Segger but with a
> STlink/V3 you don't need them anymore for the speed.

I'm not biased towards Segger. In fact I do not use any Segger products 
at home for my hobby projects and the reason for this is that I want to 
use tools (preferably open source) that anyone can use. That's why I'm 
perfectly happy with ST-Link and BMP.

Gerard Z. schrieb:
> EBlink sounds as J-link and there ends the whole comparison. EBlink is a
> bit like openOCD but with a total different approach and different
> features needed for live-variable debugging and fast flashing from
> IDE's.

Sorry for the misunderstanding. I was just curious if you wanted to 
monetize Embitz the way Segger does (through the sales of debug 
adapters). As I see you already mentioned that EBlink is just a 
GDB-server. What I do not understand though, is why we need another 
GDB-Server since we can have live variable/register views with OpenOCD 
as well (since everything is "just memory").

[jo mei (Gast)]

EmBitz wird wieder etwas aktiver, und die Aussagen auf der
Homepage lassen hoffen dass es weiter geht, dass es mehr gibt.
Also ich würde mich sehr freuen, ist für mich doch diese IDE
das Beste was ich für meine Arbeiten finden konnte, und der
Editor mit seiner Konfigurierbarkeit und seinem Syntax-
Highlighting ohne wirkliche Konkurrenz (ausgenommen vielleicht
teuere käufliche Tools).

Auch die Forums-Page ist wieder da. Erster Einrtag etwa vom
August, aktuelle Einträge vom Dezember ...

https://www.embitz.org/forum/

[Besorgter Bitzer (Gast)]

Hallo!

freut mich, dass es da weiter geht. Wäre sonst schade um das schöne 
Tool.

lg,

[Til S. (Firma: SEGGER) (til_s)]

Gerard Z. schrieb:
> I understand you biasing for the German based Segger but with a
> STlink/V3 you don't need them anymore for the speed.

Is ST-Link V3 actually that much faster than ST-Link V2?
At least the ST-Link V2 was much slower compared to a J-Link, 35 sec 
against 2 sec, see "Flash Programming Speed" in 
https://www.segger.com/products/debug-probes/j-link/technology/flash-download/

Anyhow, I am looking forward to give EmBitz a try once it's available.
If someone has boredom in the meantime he could give Embedded Studio a 
try, https://www.segger.com/products/development-tools/embedded-studio/. 
It's free for non-commercial use and can be used with any GDB server.

[Karl (Gast)]

Hi Til,

I am actually a commercial segger customer, but why do you promote 
segger products in a totally unrelated thread?

Also: my jlink does not make any relevant difference compared to a 
stlink V2 in my day to day debugging experience. If any, jlink is less 
stable.

Your products are ok, but it is quite annoying that you can't keep that 
to related threads.

Bye, Karl

[Til S. (Firma: SEGGER) (til_s)]

Hi Karl,

sorry, I didn't want to annoy you although I don't think it was 
unrelated. It's not that easy to separate my personal opinion from my 
job. For example I like Embedded Studio and I already did back then when 
it was Rowley Crossworks and I was not yet a SEGGER employee. I could 
just register myself here so that everyone can clearly see where I work.

Karl schrieb:
> Also: my jlink does not make any relevant difference compared to a
> stlink V2 in my day to day debugging experience.

Yes, I fully agree although it depends on what your are actually doing. 
If you e.g. have a small application the flash download speed is not 
that important. In the end none of the nowadays debug tools are 
bad...everything is better than writing applications with just printf() 
debug outputs :-).

Best regards,
Til

[Ingo Less (Gast)]

ST-Link V3 allows 24MHz SWD-Frequency, yes its much faster than V2

[Johannes S. (Gast)]

Til S. schrieb:
> At least the ST-Link V2 was much slower compared to a J-Link, 35 sec
> against 2 sec, see "Flash Programming Speed" in

I've seen such slow flash programming with STLink V2, about how many 
Megabytes are you talking? Or comparing the oldest STLink against the 
newest J-Link?

[Til S. (Firma: SEGGER) (til_s)]

Johannes S. schrieb:
> about how many Megabytes are you talking?

I just took the values from here:
https://www.segger.com/products/debug-probes/j-link/technology/flash-download/

>All tests have been performed by placing a 512 KB program into the flash
>memory of a blank STM32F417IG microcontroller connected via SWD interface.
>The SWD speed has been selected at the maximum possible for each debug probe.

Maybe that table needs to be updated regarding ST-Link V3 to be fair.

[Buzzwang (Gast)]

2.0 scheint jetzt raus zu sein.

https://www.embitz.org/
https://www.embitz.org/feature-list

[Frank M. (ukw) (Moderator)]

EmBitz schrieb:
> @Frank
> Well, is was a tough birth but 2.0 is there.

Congratulations!

> It ticks your list:
>
> - Mink's updates in the wizard
> - EBlink is tightly integrated

Thank you very much, I read it in the following thread 
Beitrag "EMbitz IDE lebt? Kommt bald neue Version 2.0!" a few days before.

> The integration of EBlink went very well, if I may say so myself.

I tested EBlink a few weeks ago and had to conclude:

- Debugging with China ST-Link works
- Debugging with original STM32 Nucleo board (ST-Link on board) does not 
work.

I will now install EmBitz 2.0 and also test EBlink again with the Nucleo 
board.

It is probably better to discuss EMBITZ 2.0 in the future in thread 
Beitrag "EMbitz IDE lebt? Kommt bald neue Version 2.0!" . Therefore I will 
cross-post my post there.

FollowUp to Beitrag "EMbitz IDE lebt? Kommt bald neue Version 2.0!"

[m.n. (Gast)]

Frank M. schrieb:
> - Debugging with original STM32 Nucleo board (ST-Link on board) does not
> work.

Mit einem Original ST-LINK/V2 (am STM32H750) gibt es keine Probleme. 
Allerdings habe ich Probleme mit dem Live-Watch siehe hier: 
Beitrag "Re: emBitz 2.0 verfügbar"
Ich hatte insgeheim gehofft, daß jemand eine Lösung kennt.

[Klaus S. (skibby)]

Hallo m.n.,
schon mal im Forum gestöbert ?
https://www.embitz.org/forum/index.php

[m.n. (Gast)]

beo bachta schrieb im Beitrag #6867847:
> Du hast nicht insgeheim gehofft sondern deine Hoffnung
> ganz öffentlich zum Ausdruck gebracht.

In diesem Forum hoffe ich immer nur. Sieh Dir Deine Antwort an.

Klaus S. schrieb:
> schon mal im Forum gestöbert ?

Ja. Ist das eine Fangfrage? Hätte ich mit 'nein' antworten müssen?

[Klaus S. (Gast)]

Wieso Fangfrage ?
Ich denke im Forum zu emBitz wird man eher eine Lösung finden als hier.
Zumal man ja gezielt auch den Entwickler ansprechen kann.

[EmBitz (Gast)]

Hi

I will chime in in English despite it is a German board.

The conclusion that EBlink works with clones and not with original is a 
bit short stated I guess. I self don't have any clones and about 70 
different Nucleo boards (thanks to many donations) and several STlink V2 
(iso) and V3 probes. So I only test it with original's. If it doesn't 
work, is it with a particular device or is outdated stlink firmware? 
What are the problems?

E.g. For the F030 was a typo error in a script
https://www.embitz.org/forum/thread-69.html

About live variables, well if you can debug with EBlink in EmBitz then 
you will have live variables. There is not something special about it to 
enable it.

Reminder: The system view is never live. Why not? Because reading 
registers can clear flags (e.g. interrupts) or values and we won't 
interfere with the target.

If you want to watch certain registers in the system area live then you 
need to add an expression as watch. That watch can be switched to live 
(press 'L' ). So if you know your timer instance just use that to access 
the counter in the watch window. Or if you know the counter address, use 
it in the memory viewer and turn the live updates on of the memory 
viewer.

Or if you access the timer counter in your code, highlight the phrase in 
the editor and keep your mouse on it. A live vartip will popup with real 
time values. If you need an other presentation e.g. binary or hex of the 
vartip, select this in the editor context menu "Vartip base...".

So there are a lot of ways which would lead you to watch the content 
live but the system viewer is not one of them.

[EmBitz (Gast)]

to continue the live variables..

EmBitz access all the variables through GDB because GDB knows where they 
are and what they are. So to make a variable visible then it must be a 
real variable known by GDB.

If you use "TIM3" most likely this is a #define with some timer base 
definition and some offset stuff and is not known by GDB because it is 
not a real instance.

You can easily test this. Add a watch as "TIM3" in the watch window and 
if you get the red error text 'No symbol "TIM3" in current context' then 
you know that it is not a real variable. For STmicro, often you need an 
handle with a .Instance which is initialized with, in this case, TIM3. 
That handle.Instance is a real variable and would lead you to the 
content of that peripheral.

[m.n. (Gast)]

Nun gut, dann läßt sich für mich die Live-Watch Funktion nicht sinnvoll 
gebrauchen. Man kann zwar die eff. Adresse der Peripherie eingeben, 
müßte aber nach jedem Programmstart alles wiederholen.

TIM3->CNT war ja nur ein einzelnes Beispiel. Wichtig sind vielfach auch 
die Capture-/Compare-Register, DMA, ...
Vielleicht installiere ich in einiger Zeit noch einmal eine aktuelle 
Version.

[EmBitz (Gast)]

You can try later on a different version but what you want will never 
happen. It's just out of the scope of any debugger.

You are mixing up compiler preprocessing with actual code/symbol 
generation in an .ELF file.

[900ss (900ss)]

EmBitz schrieb:
> It's just out of the scope of any debugger

When you are using Eclipse with GDB you don`t have live variables but 
the name resolution in e.g. the watch or variables window is working 
including structure members.

[EmBitz (Gast)]

900ss D. schrieb:
> EmBitz schrieb:
>> It's just out of the scope of any debugger
>
> When you are using Eclipse with GDB you don`t have live variables but
> the name resolution in e.g. the watch or variables window is working
> including structure members.

Sure, but that's not the same as #define is it? So what's your point?

Every debugger which uses GDB has structures in the watches, that's 
something that GDB is doing for you.

[900ss (900ss)]

EmBitz schrieb:
> So what's your point?

You wrote

EmBitz schrieb:
> It's just out of the scope of any debugger.

Thats not the case. And that has nothing todo with #define as of course 
a debugger do not know anything of defines but symbols as you also 
wrote.

EmBitz schrieb:
> Every debugger which uses GDB has structures in the watches, that's
> something that GDB is doing for you.

If e.g. TIM3 is really a define, than no Debugger knows it, yes. I'm not 
100% sure at the moment but I think Eclipse is translating the define 
and using the address to show the content in the watch window.
Maybe I misunderstsnd you.

But please don't get me wrong, I don't want to say anything against your 
debugger. No!

[EmBitz (Gast)]

No sweat, it's not about the IDE but all about the fundamentals of how 
the toolchains are working.

[Guest (Gast)]

EmBitz 2.10

The most important changes:

- Debug session saving redesigned
- Memory view has now a lock possibility to prevent accidental address 
change by e.g. mouse wheel (like uVision)
- Latest debug plugin (bug solved for MI parsing)
- Latest EBmonitor plugin (bug solved for stdin)
- EBlink 4.5[4] (with support additional STlinkV3 and bug fixes)
- Bug fix debug settings saving
- Bug fix doxygen settings saving
- Added additional GCC 9 switches to compiler options
- Menu item "delete all watches" bug fix
- A lot of minor bug fixes and small updates...

[Peter (Gast)]

Hello,
can the IDE also be used to program and debug the STM32H7 dual core?


I have the problem that I have the 1.11 and now wanted to install the 
2.0 (2.1 in a few minutes) in parallel.
But when I start I always get the message that the version of EBlink is 
too old. But I don't remember ever installing a version of it.

[Guest (Gast)]

Yes, EBlink supports dual core.

- Launch EBlink separately (e.g. windows context menu or "EBlink -S 
stm32-auto -G" )
- As you can see in the terminal of EBlink, there are two targets with 
two GDB servers on two different ports.
- Configure your two EmBitz as remote and select the tcp ports for 
correct corse.

You could install a fresh one, if you already have one installed, it 
will recognize that.

For support
https://Embitz.org/forum

[Balder (Gast)]

When trying to start a debug session, STLinkV2.1 ,V2J39M27, 
Embitz2.30,STM32F334K it says: "Target voltage 0.01V is to low for 
reliable connection". Tried to set the voltage in EBlink manu to 3.3V 
but still no change. It also complains source project to old Embitz 1.11 
needs conversion etc etc.

[Johannes S. (Gast)]

you need to connect VTarget to the STLink, did you?

[Peter (Gast)]

Hi,
are you sure the forum still exists?

Under the specified link is nothing and there is no link on the page to 
a forum.
It was there and I had already read something.
Today I wanted to sign up and report some mistakes.

1. Emblitz 1.11 could still convert Em:Blocks2.20 projects The 2.x can 
not do that anymore
2. Under XP (yes, the most of my tools is not running under Win 7/10) 
the EBlink is not recognized
3. I have read that XP / Win7/8 soon will not support anymore, with XP I 
can understand that, but Win 7/8?