Wish Support for using Arduino 2.0 + Debug function

Version 2.0 of Arduino has come out of the testing phase and is finally available for use in production
Among other novelties it includes a function that I consider essential for comfortable and safe development, the Debug function
Allows you to set one or more breakpoints where the program stops and the operator can analyze the variables or change their value
It is possible to advance the code step-by-step allowing to control the functioning with precision and assuring the developer that what is expected is actually what is being performed
It is a function that I consider absolutely fundamental in a work environment that can be defined as 'professional'
As demonstrated by the fact that various tools have been created that include the possibility of step-by-step debugging as an alternative to the Arduino environment
I believe that this feature can greatly increase the community of developers who will use the B4R environment for developing code on embedded devices

Arduino IDE 2.0 debugging is limited to boards that use the SAMD architecture, so for me (I mainly use ESP8266 but mainly ESP32) it's a complete waste of time. I believe that the Arduino Zero is SAMD, but I could be incorrect on that. I would personally prefer for Anywhere Software get upgrade B4R to work in conjunction with Arduino IDE V2.0. Downgrading isn't an option for me, I wouldn't downgrade any B4X tools and the same for all the software on my development machines.

Peter Simpson said:

Arduino IDE 2.0 debugging is limited to boards that use the SAMD architecture, so for me (I mainly use ESP8266 but mainly ESP32) it's a complete waste of time. I believe that the Arduino Zero is SAMD, but I could be incorrect on that. I would personally prefer for Anywhere Software get upgrade B4R to work in conjunction with Arduino IDE V2.0. Downgrading isn't an option for me, I wouldn't downgrade any B4X tools and the same for all the software on my development machines.

Click to expand...

You think debug-related features are unimportant, while I think they are essential, to the point that the absence of these features is preventing me from using the B4R environment (as well as the Arduino IDE before 2.0), and this is a great disappointment for me because being able to share the same code (or large portion) between different operating environments would be a great satisfaction
So I'm curious to understand how you do it when you have to try new code
Portions of code you've never tried and therefore you don't know how they will behave, how do you stop at a certain instruction and check the variables?
And within cycles of which you have to perform time measurements, and therefore you cannot insert additional code because it would alter the functioning, how do you stop the execution at a certain point and check what has happened up to that moment ?
We are talking about more complex procedures than the classic operating examples of a few lines
And therefore it is impossible to assume that they will work correctly but we need to verify their correct functionality, and therefore not a few tens of lines but hundreds or thousands of lines of code

amorosik said:

You think debug-related features are unimportant, while I think they are essential

Click to expand...

Here we go again, this is exactly why I don't interact that much on here.

I didn't say that debug-related features are unimportant, where exactly did I say that?????????

I said and I quote "Arduino IDE 2.0 debugging is limited to boards that use the SAMD architecture, so for me (I mainly use ESP8266 but mainly ESP32) it's a complete waste of time." This means that you can't debug ESP devices in the Arduino IDE 2.0 so IDE 2.0 is a waste of time for me.

That means exactly what I said, 2.0 debugging is limited to SAMD devices which is only available on a few boards, a small percentage of boards in reality. I too wish that debugging was great in 2.0 thus also in B4R but that's currently not the case.

Like me if you really want to debug Arduino/ESP using breakpoints, just install Visual Studio Code and install a couple of extension, they work great for debugging.

This discussion is now over...

Peter Simpson said:

Like me if you really want to debug Arduino/ESP using breakpoints, just install Visual Studio Code and install a couple of extension, they work great for debugging.

Click to expand...

Yes, I'm very interested in understanding what system you use
Which extensions are you referring to exactly?

You can have a basic debugging for all microprocessors including ESP8266 and ESP32 with the current B4R and Arduino version with this lib:

Thread 'rDebug.b4xlib - Debug arduino code adding break points in all microprocessors' code (even the older ones)' https://www.b4x.com/android/forum/t...roprocessors-code-even-the-older-ones.145028/

Thank you, very interesting
But the use of the serial port, while being possible to perform the simplest tasks, adds an unsustainable waste of time in the case of medium/large sized projects

amorosik said:

Thank you, very interesting
But the use of the serial port, while being possible to perform the simplest tasks, adds an unsustainable waste of time in the case of medium/large sized projects

Click to expand...

The only alternative is to use MQTT and modify the B4J app and the library in the thread I mentioned. Have a look in my contributions (at my signature) at the ESP32CAM logs and you can use this as a base to modify both the library (mentioned in my previous post) and the B4J app in this thread (ESP32CAM). Otherwise I cannot understand what you have in mind for debugging because there has to be eitherway a communication path between the computer and the MCU.

hatzisn said:

The only alternative is to use MQTT and modify the B4J app and the library in the thread I mentioned. Have a look in my contributions (at my signature) at the ESP32CAM logs and you can use this as a base to modify both the library (mentioned in my previous post) and the B4J app in this thread (ESP32CAM). Otherwise I cannot understand what you have in mind for debugging because there has to be eitherway a communication path between the computer and the MCU.

Click to expand...

Please also keep in mind that the debugging generally occurs chunk by chunk so even in huge projects you will do it this way - so I suppose no worries.