loading to device without debugging

[MuratUrsavas]

piker,

As a general advice, if you are programming your devices with a development tool, then it means you are on a very dangerous track. Let me explain why...

With doing this you are showing that your firmwares are not under source control. Looks like you are publising (releasing) them without tracking the revisions. This is OK with DIY projects but not OK in a bigger scope. Production programming means you are selling some devices or releasing to the field even without selling them. And if you can not track the revisions and not test them enough, you'll going to get into trouble sooner or later.

You should track your revisions in a system even for beta and field tests.

Also your "MCU loading" stage has to be isolated from the development medium. This way you can always load the expected firmware. Otherwise you cannot be sure about that.

[piker]

Good advice thanks. So you are saying I should be programming the device with hex or elf file with something other than the EM::Blocks? A command line tool or ...? I have only ever programmed projects with dev tools so not sure how to go about controlling version. I always just use the most recent build and date the folder.

[MuratUrsavas]

Yes, exactly. Even you have one PC for every job, you have to define your jobs with different software. The development environments are tend to be dirty because of our nature. We try and figure new things out and there are tens of thousands lines we can mess up unintentionally.

Other than that you could have some options regarding to the device configurations. You must be sure about the options you have for that particular release.

Also managing untracked releases will decrease your productivity and profitability. Bug fixing would become very difficult.

But the most important thing is; fixing something in the field is tremendously expensive. That's why release stage is so important. You have to freeze your software, test it in the field and fix the bugs without adding new features and release it. Your development branch has to be seperated from the release branch.

For tracking the releases and also your development progress you should use a source control management software like SVN, Git or Mercurial. For bug tracking you can even use Notepad or Excel. Important thing is taking notes somewhere and not trusting your memory. But using a dedicated tool like Bugzilla or Redmine is ofcourse preferable.

[Psi]

Just to be clear, this thread has nothing to do with production programming.

First off, thanks to all who have given up their free time to develop emblocks/embitz, it's awesome.
Please take all the text below as constructive criticism

The issue the OP is having, and me too, is that there are many cases during development when you need to upload code to a MCU but do not require any debugging.
In fact i would say it's more common to not use debugging than use it. However this really is down to personal preference and the how the specific engineer works best. Most programmers i have seen only use debugging when they have a bug and not when they are simply adding features or tweaking code.

The STM32 debugging is actually pretty fast to start, so having it 'start debugging' every time you upload isn't the real issue.

The root cause of the issue is getting the cycle time as quick as possible between clicking a button and having the code uploaded and running on the device. Reducing unnecessary clicks and annoyances in this area is essential.

Some programmings work with a very rapid cycle,
1. change code a little
2. compile
3. observe result
4. change code a little more
5. compile...

Currently the source-code/file window instantly changes from the code you are working on to start of execution code (usually startup_stm32fxxx.S unless you have a breakpoint or "run to main" set to on).
I find this window/file change almost always jumps to a place i don't want to be. So it forces me to change back manually every time. The other thing that's needed is a way to always 'run' the code. Instead of having to click 'continue' every time. (If there is a way to do this i've not found it yet)

So i put forward that we need two separate buttons
'Upload and Run with debugging'
* No source window jump
* Your code automatically starts running as soon as it's uploaded.
* No popup warning that you are already debugging if you click the button again, it just stop debugging and restart automatically

'Upload and Pause for debugging' (exactly what we have now)
* source window jumps away from current file to start of execution.
* The execution waits for user to hit 'continue'
* Popup warning if user tries to start debugging again when already running.

Alternative the first option could have debugging off entirely, however it's pretty nice to have it running in case you do decide to stop and have a look at some variables. And its pretty fast. so i say keep debugging active for both or maybe 3rd option, upload and run without debugging?


Note to all users:
There is a current work-around for this source jumping issue. Drag Startup_stm32fxx.S to a second source window with the window width set very small (so it doesn't get in the way of your main window). The IDE can jump to that window all it likes but your main source stays there.

[EmBitz]

The new EB-link platform is closing this gap. There will be a special menu button only uploading the image if the debug interface is configured right. A beta EB-link version becomes available in the member section for testing.

The EB-link is a modular platform and by using command line switches you can select any combination of MCU's, hardware interfaces (st-link, CMSIS-dap etc) and services like flashing or GDB server. It uses full caching and by keeping EB-link open during debug sessions you will have a much faster debug experience between debug sessions. EB-link uses C-like squirrel scripting for all MCU related functions and definitions (reseting, flashing, memory mapping etc) so users can extend it.

Downside, we should use EB-link as our only interface layer so that we get a coherent GUI.

[EmBitz]

Just to be clear, this thread has nothing to do with production programming.

First off, thanks to all who have given up their free time to develop emblocks/embitz, it's awesome.
Please take all the text below as constructive criticism

The issue the OP is having, and me too, is that there are many cases during development when you need to upload code to a MCU but do not require any debugging.
In fact i would say it's more common to not use debugging than use it. However this really is down to personal preference and the how the specific engineer works best. Most programmers i have seen only use debugging when they have a bug and not when they are simply adding features or tweaking code.

The STM32 debugging is actually pretty fast to start, so having it 'start debugging' every time you upload isn't the real issue.

The root cause of the issue is getting the cycle time as quick as possible between clicking a button and having the code uploaded and running on the device. Reducing unnecessary clicks and annoyances in this area is essential.

Some programmings work with a very rapid cycle,
1. change code a little
2. compile
3. observe result
4. change code a little more
5. compile...

Currently the source-code/file window instantly changes from the code you are working on to start of execution code (usually startup_stm32fxxx.S unless you have a breakpoint or "run to main" set to on).
I find this window/file change almost always jumps to a place i don't want to be. So it forces me to change back manually every time. The other thing that's needed is a way to always 'run' the code. Instead of having to click 'continue' every time. (If there is a way to do this i've not found it yet)

So i put forward that we need two separate buttons
'Upload and Run with debugging'  
* No source window jump
* Your code automatically starts running as soon as it's uploaded.
* No popup warning that you are already debugging if you click the button again, it just stop debugging and restart automatically

'Upload and Pause for debugging'  (exactly what we have now)
* source window jumps away from current file to start of execution.
* The execution waits for user to hit 'continue'
* Popup warning if user tries to start debugging again when already running.

Alternative the first option could have debugging off entirely, however it's pretty nice to have it running in case you do decide to stop and have a look at some variables. And its pretty fast. so i say keep debugging active for both or maybe 3rd option, upload and run without debugging?


Note to all users:
There is a current work-around for this source jumping issue. Drag Startup_stm32fxx.S to a second source window with the window width set very small (so it doesn't get in the way of your main window). The IDE can jump to that window all it likes but your main source stays there.

@Psi

A button to upload the image and skip that whole debugging would also be a solution or not?

   

[troyerta]

Yes. That would be awesome. If there is an F8, F10, or F-whatever shortcut to be added for this functionality, that would also be great.

In Keil, you can hit F7 to build, and then F8 to flash. F5 to start debugging session. It assumes that debugging is a separate ordeal to startup.

This is handy since a lot of my firmware changes are small, and can be verified the fastest when I can get the mcu to simply execute it.

[Alma]

Just to be clear, this thread has nothing to do with production programming.

First off, thanks to all who have given up their free time to develop emblocks/embitz, it's awesome.
Please take all the text below as constructive criticism

The issue the OP is having, and me too, is that there are many cases during development when you need to upload code to a MCU but do not require any debugging.
In fact i would say it's more common to not use debugging than use it. However this really is down to personal preference and the how the specific engineer works best. Most programmers i have seen only use debugging when they have a bug and not when they are simply adding features or tweaking code.

The STM32 debugging is actually pretty fast to start, so having it 'start debugging' every time you upload isn't the real issue.

The root cause of the issue is getting the cycle time as quick as possible between clicking a button and having the code uploaded and running on the device. Reducing unnecessary clicks and annoyances in this area is essential.

Some programmings work with a very rapid cycle,
1. change code a little
2. compile
3. observe result
4. change code a little more
5. compile...

Currently the source-code/file window instantly changes from the code you are working on to start of execution code (usually startup_stm32fxxx.S unless you have a breakpoint or "run to main" set to on).
I find this window/file change almost always jumps to a place i don't want to be. So it forces me to change back manually every time. The other thing that's needed is a way to always 'run' the code. Instead of having to click 'continue' every time. (If there is a way to do this i've not found it yet)

So i put forward that we need two separate buttons
'Upload and Run with debugging'  
* No source window jump
* Your code automatically starts running as soon as it's uploaded.
* No popup warning that you are already debugging if you click the button again, it just stop debugging and restart automatically

'Upload and Pause for debugging'  (exactly what we have now)
* source window jumps away from current file to start of execution.
* The execution waits for user to hit 'continue'
* Popup warning if user tries to start debugging again when already running.

Alternative the first option could have debugging off entirely, however it's pretty nice to have it running in case you do decide to stop and have a look at some variables. And its pretty fast. so i say keep debugging active for both or maybe 3rd option, upload and run without debugging?


Note to all users:
There is a current work-around for this source jumping issue. Drag Startup_stm32fxx.S to a second source window with the window width set very small (so it doesn't get in the way of your main window). The IDE can jump to that window all it likes but your main source stays there.

@Psi

A button to upload the image and skip that whole debugging would also be a solution or not?

Hello
this is great
But why does not it exist in my version?

[escalator]

Hello
this is great
But why does not it exist in my version?

Because it's just a proposal by Psi