Any wishes for script hooks in Studio 6(.X) ?

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there any interest in support for executing Python scripts at specific times during debugging with Atmel Studio ? I am currently thinking of providing hooks for:

H1. Calling a script when a breakpoint is hit (with "auto continue" if desired)
H2. Calling a script at reset (Launch, Reset)
H3. Calling a script when evaluating a watch expression (potentially changing watched expire)

In a script, one should be able to
F1. Eval a watch.
F2. Read/write memory and registers
F3. Print to the output window
+ all the features provided by the IronPython distro we package with Studio.

Please take contact if you have any interesting ideas.

dan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know we got told off for being hostile to developers but seriously, don't you think you should fix the existing product before adding new features?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hear hear

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lol, didn't take long.

No buyers then ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"hooks" are always welcome but as long as the mechanism doesn't break anything else and it doesn't sap implementation effort from things like AVR Toolchain (most importantly) or fixing other issues in the eye candy (less importantly).

What, for example, are Atmel's plans for adopting 4.7.1? Now that the __flash mechanism and LTO seem ready for human consumption it'd be good to see them in a readily accessible toolchain that has support for a wide range of AVRs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the rationale behind Python specifically?

(The hostile snide remark would be: Surprised you didn't pick VB scripting... :wink:)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff: Sorry, I am not involved with the toolchain and don´t know their schedule.

Johan: IronPython is already part of the Studio distribution because of ASF, so it was a good place to start.

We´ve fixed and are fixing a lot of bugs in the upcoming 6.0 release; meanwhile it is refreshing to plan for and think about new features. So your input is certainly appreciated.

So far I´ve seen people use scripts to:
- On ARM : support debugging in RAM by initializing SP and PC to custom values at launch. In Studio 6, solved by using a custom field in the Tool options pane.
- On ARM : reset peripherals on core reset. Now hardcoded for ARM in Studio 6
- On ARM: disable-enable interrupts when stepping. Coming as an option for all MCUs in Studio 6
- gdb, MS DevStudio ,etc : pretty print complicated structures. This one is a valid case for scripting in Studio 6
- tracepoints: do something when hitting a breakpoint. Studio 6 can currently print a message with variables, and optionally continue execution. Script support here would potentially allow for taking snapshots of memory space and vars and do intelligent diffs.

Have you seen a cool/useful use of hooks/macros in embedded debugging ? Speak out :)

dan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Have you seen a cool/useful use of hooks/macros in embedded debugging ? Speak out

Well I presume you know TI's "gel file" system?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

danv wrote:

- On ARM: disable-enable interrupts when stepping. Coming as an option for all MCUs in Studio 6

Yahoo! I've wanted this for a very long time. This makes it enormously more usable. Still, can you add another option to make it perfect: Allow interupt routines to run, step only following the current thread?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jkuusama wrote:

Yahoo! I've wanted this for a very long time. This makes it enormously more usable. Still, can you add another option to make it perfect: Allow interupt routines to run, step only following the current thread?

Interrupts would be serviced whenever running freely, like when stepping over a function call, or running to next breakpoint. This may not be enough, but there´s the easy workaround of setting a breakpoint and run freely whenever you want queued interrupts to be serviced.
At least this is the theory. We´re anxious to see how this turns out in practice :)

dan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Well I presume you know TI's "gel file" system?

Now I do, thanks :)
Fairly big chunk of functionality, but unlikely we will get time to implement anything of that magnitude. Interesting to note that TI split their IDE in a GUI bit and a debug server, not unlike Atmel Studio, and that they provide separate scripting engines for the two components.

dan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

danv wrote:

Interrupts would be serviced whenever running freely, like when stepping over a function call, or running to next breakpoint. This may not be enough, but there´s the easy workaround of setting a breakpoint and run freely whenever you want queued interrupts to be serviced.
At least this is the theory. We´re anxious to see how this turns out in practice :)

dan


You mean that even with an interrupt pending, I can single step without falling into the interrupt server, but if I step over a function call or run to cursor, the pending interrupts get served? Sounds like a very good solution. When this will be out? Next week, please? :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Interesting to note that TI split their IDE in a GUI bit and a debug server, not unlike Atmel Studio

Except that theirs is based on Eclipse and is available for all operating systems :lol:

BTW if anyone here thinks AS5/6 is "bloatware" look at the size of my \Program Files\Texas Instruments\ in the following picture!

Admittedly this is because I have quite a few of TI's library code packages installed:

 Directory of C:\Program Files\Texas Instruments

01/04/2012  14:43              .
01/04/2012  14:43              ..
14/12/2011  11:09              AVB
17/02/2012  15:26              AVB_2.0_asl
27/10/2011  10:53              avb-old
30/01/2012  18:02              bios_6_32_05_54
31/10/2011  12:02              C6000 Code Generation Tools 7.3.0B3
18/04/2011  13:05              ccsv4
15/02/2012  12:40              codec_engine_3_21_02_25
28/10/2011  11:20              edma3_lld_02_11_02_04
15/02/2012  12:36              edma3_lld_02_11_03_02
15/02/2012  12:36              framework_components_3_21_03_34_asl
09/12/2011  16:17              HDVPSS_01_00_01_28_asl_v4
28/10/2011  10:48              ipc_1_23_03_31_asl
01/03/2012  15:22              ipc_1_23_05_40_asl
27/10/2011  10:56              ivahd_hdvicp20api_01_00_00_19_production
27/10/2011  10:52              ivahd_jpegvdec_01_00_00_00_production
11/11/2011  14:31              ivahd_jpegvdec_01_00_01_00_production
30/01/2012  18:06              ivahd_jpegvdec_01_00_02_00_production
27/10/2011  10:53              ndk_2_20_03_24
05/09/2011  19:32              nsp_1_00_00_07_eng_centaurus_rel
28/10/2011  15:09              nsp_1_00_00_07_eng_centaurus_rel_ECU_asl
15/02/2012  12:41              nsp_dm814x_01_00_00_08_ecu_asl
15/02/2012  12:41              nsp_dm814x_01_00_00_08_evm_asl
02/11/2011  12:08              pspdrivers_02_20_02_01_asl_v2
15/02/2012  12:35              pspdrivers_02_20_02_01_asl_v3
31/10/2011  12:02              TMS470 Code Generation Tools 4.9.0
01/04/2012  14:44              TMS470 Code Generation Tools 4.9.2
28/10/2011  10:47              xdais_7_21_00_01
27/10/2011  10:40              xdctools_3_22_01_21
30/01/2012  17:51              xdctools_3_22_04_46

(you thought ASF was big?)

Attachment(s):