Go Down

Topic: Warning: This core does not support exporting sketches (Read 2653 times) previous topic - next topic

brice3010

Using Arduino IDE 1.6.12 on three pc's: W7 64b, W7 32b and W8.1 32b I recently run into this error when trying to export hex files of ATtiny85 or Digispark sketches, only when trying to export hex for Digispark (Arduino sketches export ok):

Warning: This core does not support exporting sketches

I have following hardware folders installed, in c:/program files (x86)/Arduino/hardware/

arduino

ATTinyCore-Master

and on 2 of the 3 pc's also
MicroCore-master

The preferences file includes following text in the Additional boards manager:

https://raw.githubusercontent.com/damellis/attiny/ide-1.6.x-boards-manager/package_damellis_attiny_index.json,http://digistump.com/package_digistump_index.json,http://arduino.esp8266.com/stable/package_esp8266com_index.json,https://mcudude.github.io/MicroCore/package_MCUdude_MicroCore_index.json

What can I do about this?

I used to be able to export without a problem until last week, and cannot remember having changed or added anything to the Arduino program folder.

I store all my sketches and libraries in Google Drive.

The platform.txt in the Arduino/hardware/ATTinyCore_master/avr folder contains following:

Code: [Select]


# Arduino AVR Core and platform.
# ------------------------------

# For more info:
# https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5---3rd-party-Hardware-specification

name=ATtiny Universal
version=1.1.3

# AVR compile variables
# ---------------------

compiler.warning_flags=-w
compiler.warning_flags.none=-w
compiler.warning_flags.default=
compiler.warning_flags.more=-Wall
compiler.warning_flags.all=-Wall -Wextra

# Default "compiler.path" is correct, change only if you want to overidde the initial value
compiler.path={runtime.tools.avr-gcc.path}/bin/
compiler.c.cmd=avr-gcc
compiler.c.flags=-c -g -Os {compiler.warning_flags} -std=gnu11 -ffunction-sections -fdata-sections -MMD {ltocflags}
compiler.c.elf.flags={compiler.warning_flags} -Os {ltoelfflags} -Wl,--gc-sections
compiler.c.elf.cmd=avr-gcc
compiler.S.flags=-c -g -x assembler-with-cpp {ltocppflags}
compiler.cpp.cmd=avr-g++
compiler.cpp.flags=-c -g -Os {compiler.warning_flags} -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD {ltocppflags}
compiler.ar.cmd=avr-{ltoarcmd}ar
compiler.ar.flags=rcs
compiler.objcopy.cmd=avr-objcopy
compiler.objcopy.eep.flags=-O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0
compiler.elf2hex.flags=-O ihex -R .eeprom
compiler.elf2hex.cmd=avr-objcopy
compiler.ldflags=
compiler.size.cmd=avr-size

# This can be overriden in boards.txt
build.extra_flags=

# These can be overridden in platform.local.txt
compiler.c.extra_flags=
compiler.c.elf.extra_flags=
compiler.S.extra_flags=
compiler.cpp.extra_flags=
compiler.ar.extra_flags=
compiler.objcopy.eep.extra_flags=
compiler.elf2hex.extra_flags=

# AVR compile patterns
# --------------------

## Compile c files
recipe.c.o.pattern="{compiler.path}{compiler.c.cmd}" {compiler.c.flags} -mmcu={build.mcu} -DF_CPU={build.f_cpu} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} {compiler.c.extra_flags} {build.extra_flags} {includes} "{source_file}" -o "{object_file}"

## Compile c++ files
recipe.cpp.o.pattern="{compiler.path}{compiler.cpp.cmd}" {compiler.cpp.flags} -mmcu={build.mcu} -DF_CPU={build.f_cpu} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} {compiler.cpp.extra_flags} {build.extra_flags} {includes} "{source_file}" -o "{object_file}"

## Compile S files
recipe.S.o.pattern="{compiler.path}{compiler.c.cmd}" {compiler.S.flags} -mmcu={build.mcu} -DF_CPU={build.f_cpu} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} {compiler.S.extra_flags} {build.extra_flags} {includes} "{source_file}" -o "{object_file}"

## Create archives
archive_file_path={build.path}/{archive_file}
recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} "{archive_file_path}" "{object_file}"

## Combine gc-sections, archives, and objects
recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" {compiler.c.elf.flags} -mmcu={build.mcu} {compiler.c.elf.extra_flags} -o "{build.path}/{build.project_name}.elf" {object_files} "{build.path}/{archive_file}" "-L{build.path}" -lm

## Create eeprom
recipe.objcopy.eep.pattern="{compiler.path}{compiler.objcopy.cmd}" {compiler.objcopy.eep.flags} {compiler.objcopy.eep.extra_flags} "{build.path}/{build.project_name}.elf" "{build.path}/{build.project_name}.eep"

## Create hex
recipe.objcopy.hex.pattern="{compiler.path}{compiler.elf2hex.cmd}" {compiler.elf2hex.flags} {compiler.elf2hex.extra_flags} "{build.path}/{build.project_name}.elf" "{build.path}/{build.project_name}.hex"

## Compute size
recipe.size.pattern="{compiler.path}{compiler.size.cmd}" -A "{build.path}/{build.project_name}.elf"
recipe.size.regex=^(?:\.text|\.data|\.bootloader)\s+([0-9]+).*
recipe.size.regex.data=^(?:\.data|\.bss|\.noinit)\s+([0-9]+).*
recipe.size.regex.eeprom=^(?:\.eeprom)\s+([0-9]+).*

## Save hex
recipe.output.tmp_file={build.project_name}.hex
recipe.output.save_file={build.project_name}.hex

## Preprocessor
preproc.includes.flags=-w -x c++ -M -MG -MP
recipe.preproc.includes="{compiler.path}{compiler.cpp.cmd}" {compiler.cpp.flags} {preproc.includes.flags} -mmcu={build.mcu} -DF_CPU={build.f_cpu} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} {compiler.cpp.extra_flags} {build.extra_flags} {includes} "{source_file}"

preproc.macros.flags=-w -x c++ -E -CC
preprocessed_file_path={build.path}/nul
recipe.preproc.macros="{compiler.path}{compiler.cpp.cmd}" {compiler.cpp.flags} {preproc.macros.flags} -mmcu={build.mcu} -DF_CPU={build.f_cpu} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} {compiler.cpp.extra_flags} {build.extra_flags} {includes} "{source_file}" -o "{preprocessed_file_path}"

# AVR Uploader/Programmers tools
# ------------------------------
tools.avrdude.path={runtime.tools.avrdude.path}
tools.avrdude.cmd.path={path}/bin/avrdude
tools.avrdude.config.path={runtime.platform.path}/avrdude.conf


tools.avrdude.upload.params.verbose=-v
tools.avrdude.upload.params.quiet=-q -q
tools.avrdude.upload.pattern="{cmd.path}" "-C{config.path}" {upload.verbose} -p{build.mcu} -c{upload.protocol} -P{serial.port} -b{upload.speed} -D "-Uflash:w:{build.path}/{build.project_name}.hex:i"

tools.avrdude.program.params.verbose=-v
tools.avrdude.program.params.quiet=-q -q
tools.avrdude.program.pattern="{cmd.path}" "-C{config.path}" {program.verbose} -p{build.mcu} -c{protocol} {program.extra_params} "-Uflash:w:{build.path}/{build.project_name}.hex:i"

tools.avrdude.erase.params.verbose=-v
tools.avrdude.erase.params.quiet=-q -q
tools.avrdude.erase.pattern="{cmd.path}" "-C{config.path}" {erase.verbose} -p{build.mcu} -c{protocol} {program.extra_params} -e -Uefuse:w:{bootloader.extended_fuses}:m -Uhfuse:w:{bootloader.high_fuses}:m -Ulfuse:w:{bootloader.low_fuses}:m

tools.avrdude.bootloader.params.verbose=-v
tools.avrdude.bootloader.params.quiet=-q -q
tools.avrdude.bootloader.pattern="{cmd.path}" "-C{config.path}" {bootloader.verbose} -p{build.mcu} -c{protocol} {program.extra_params} "-Uflash:w:{runtime.platform.path}/bootloaders/{bootloader.file}:i"



pert

The problem is the Digistump AVR Boards package doesn't define the output recipes to support Sketch > Export compiled Binary. I have submitted a pull request to add this functionality to the Digistump AVR Boards and Digistump SAM Boards packages:
https://github.com/digistump/DigistumpArduino/pull/51

If you need the hex file from your sketch compiled for Digispark you can set File > Preferences > Show verbose output during: compilation(check) > OK and then check the console after compilation for the temporary build folder, e.g.:
C:\Users\per\AppData\Local\Temp\arduino_build_241472

If you look in that folder you will find the .hex file, e.g.:
C:\Users\per\AppData\Local\Temp\arduino_build_241472/sketch_jan19a.ino.hex

You could also edit the Digistump AVR Boards platform.txt file to support exporting, as I have done in my pull request:
https://github.com/digistump/DigistumpArduino/pull/51/files
If you need instructions for how to do that let me know.

brice3010

Hi Pert, thank you very much for your reply!

I found -using verbose output- the location of the .hex file, and the .eep and .elf file to boot.

When following your recipe (I check platform.txt in c:/Program Files (x86)/Arduino-1.8.1/hardware/arduino/avr/platfomr.txt) I find the following already in that file:

## Create output files (.eep and .hex)
recipe.objcopy.eep.pattern="{compiler.path}{compiler.objcopy.cmd}" {compiler.objcopy.eep.flags} {compiler.objcopy.eep.extra_flags} "{build.path}/{build.project_name}.elf" "{build.path}/{build.project_name}.eep"
recipe.objcopy.hex.pattern="{compiler.path}{compiler.elf2hex.cmd}" {compiler.elf2hex.flags} {compiler.elf2hex.extra_flags} "{build.path}/{build.project_name}.elf" "{build.path}/{build.project_name}.hex"

## Save hex
recipe.output.tmp_file={build.project_name}.hex
recipe.output.save_file={build.project_name}.{build.variant}.hex


So basically what you wrote in your github request.

What do you think is wrong that I do not get the temp .hex file output to the sketch folder?

I am prepared to uninstall everything including all ../AppData/Local/... temp files etc and restart from scratch if it is required.


brice3010

You could also edit the Digistump AVR Boards platform.txt file to support exporting, as I have done in my pull request:
https://github.com/digistump/DigistumpArduino/pull/51/files
If you need instructions for how to do that let me know.
Edit on my previous post:

I may have to edit indeed the Digistump AVR board platform but can you tell me where to find that?

Thanks!
Erik

pert

What do you think is wrong that I do not get the temp .hex file output to the sketch folder?
Because when you have a Digispark board selected from the Tools > Board menu the Digistump AVR Boards platform.txt is used, not c:/Program Files (x86)/Arduino-1.8.1/hardware/arduino/avr/platform.txt, which is the Arduino AVR Boards package location. The Digistump AVR Boards platform.txt doesn't define the output recipes so what you're experiencing is the expected behavior and doesn't indicate any problem with your system. You can modify the Digistump AVR Boards platform.txt to add support for the Arduino IDE's export function if you like.

I may have to edit indeed the Digistump AVR board platform but can you tell me where to find that?
Do this:
  • Select a Digispark board from the Tools > Board menu
  • File > Examples > Digispark_Examples > _9DOF_Shield
  • Sketch > Show Sketch Folder - this will open something like AppData/local/Arduino15/packages/digistump/hardware/avr/1.6.7/libraries/Digispark_Examples/_9DOF_Shield
  • Move up folder levels to AppData/local/Arduino15/packages/digistump/hardware/avr/1.6.7
  • Open platform.txt in a text editor.
  • Add the following lines anywhere in the file:

Code: [Select]
recipe.output.tmp_file={build.project_name}.hex
recipe.output.save_file={build.project_name}.{build.variant}.hex

  • Save the file
  • Restart the Arduino IDE if it's running


After that Sketch > Export compiled Binary should now work for the Digispark boards.

brice3010

Hi pert: S O L V E D !!! Thanks so very much!

For the sake of others I will describe in detail what I did because a number of your references did not match up with my installed program parameters.

1. In my example sketches there is no Digispark_examples

2. In my hardware folder I have the following:
../hardware/arduino/
../hardware/ATTinyCore-master
../hardware/tools

Each time with their proper platform.txt. What was confusing is that your "recipe" already was/is included in the ATTinyCore-master/avr/platform.txt file

3. As I did not have the example you described I opened one of my own sketches written for a Digispark board. Compiling went ok, export binary file gave the famous error but I used verbose output and could find the temp file location:

c:\Users\Mysafety\AppData\Local\Temp\arduino_build_427935\DigisparkAnalogWrite.ino.hex

Then I looked for your folder reference and deduced what would likely be the location on my computer:
c:\Users\Mysafety\AppData\Local\Arduino15\packages\digistump\hardware\avr\1.6.7\platform.txt
And there I found the file

However the "#create hex" text did not refer to output to the .ino folder! Just some text stating the compiler path.

I then included the blank text from your code above in the file, save, restart arduino and BINGO!

HOWEVER:

1. I feel that my hardware descriptions in my Arduino folder also my not be up to scratch: could you please have a look at my harware folder contents and give me your critical opinion please?

2. I do not have the Digistump examples, probably I did not install their examples/libraries/hardware properly?? I however can do all I need/want in terms of writing/compiling/downloading/.. stuff to my Digispark boards. But I like to optimise and make it perfect, so your expert opinion will be greatly appreciated!

3. I still wondr what could have gone wrong as I could do an export earlier.. Or did I just not see this error? I have a feeling, when reading your solution, that this problem must have been there all the time.

Have a great day and thanks again!!
Erik


brice3010

 and addendum: in my haste to get it solved I must also say I did revert earlier today, before your post, to Arduino 1.6.12.

1. Can I safely upgrade again to 1.8?

2. And I have another 2 computers (Win 7 32b abd Win8.1 32b) -and for clarity, on another site another 2 computers with Win XP SP3) where I have not yet implemented this solution. Do I have manually to edit the platform.txt file in each of them?

3. Is the use of Google Drive a safe and reliable solution for storage of libraries and sketches?

Erik

pert

1. In my example sketches there is no Digispark_examples
Strange, are you using Digistump AVR Boards 1.6.7? Well it really doesn't matter, you can use any example for any of the Digispark libraries, I just used the first one on the menu. Or you can just navigate straight to the folder if you know where to find it. That's just an easy way I've found to tell people how to get to the correct folder since sometimes it's hidden.

2. In my hardware folder I have the following:
../hardware/arduino/
../hardware/ATTinyCore-master
../hardware/tools

Each time with their proper platform.txt. What was confusing is that your "recipe" already was/is included in the ATTinyCore-master/avr/platform.txt file
That's completely irrelevant. ATTinyCore is a different core from Digistump AVR Boards and so that platform.txt is only used if you have an ATTinyCore board selected in the Tools > Board menu.

1. I feel that my hardware descriptions in my Arduino folder also my not be up to scratch: could you please have a look at my harware folder contents and give me your critical opinion please?
There are actually multiple hardware folders:
  • {Arduino IDE installation folder}/hardware - this should only contain Arduino AVR Boards core. You should never install any other hardware package to that folder because it will be lost when you update to a new version of the Arduino IDE.
  • {sketchbook folder}/hardware - this is where you manually install hardware packages
  • AppData\Local\Arduino15\packages... - this is where Board Manager installs hardware packages

Generally you should be OK with the Arduino AVR Boards version included with your IDE, though you can update this via Boards Manager. Updating can sometimes be problematic if you're using an older IDE version because they're not so good about maintaining backwards compatibility but that shouldn't be a problem for Arduino IDE 1.6.12. I can see that you've manually installed ATTinyCore but I don't know which version you're running. I'd recommend you to remove the manual installation of that core and instead use the Boards Manager installation as described here:
https://github.com/SpenceKonde/ATTinyCore/blob/master/Installation.md#board-manager-installation
because this will make it easier for you to keep updated to the latest version. However, as I've said, that core is unrelated to your Digispark board, it is only used for the ATTinyCore boards.

2. I do not have the Digistump examples, probably I did not install their examples/libraries/hardware properly?? I however can do all I need/want in terms of writing/compiling/downloading/.. stuff to my Digispark boards. But I like to optimise and make it perfect, so your expert opinion will be greatly appreciated!
If you installed Digistump AVR Boards 1.6.7 via Boards Manager following:
http://digistump.com/wiki/digispark/tutorials/connecting
Then they should have been automatically installed with the hardware package. Note that these examples will only appear when you have a Digispark board selected in the Tools > Board menu.

3. I still wondr what could have gone wrong as I could do an export earlier.. Or did I just not see this error? I have a feeling, when reading your solution, that this problem must have been there all the time.
The Digistump AVR Boards package has never had the output recipes defined so there's nothing I know of that would have changed. Are you sure you were previously able to export with one of the Digispark boards? Note that the Arduino AVR Boards, ATTinyCore, and MicroCore packages you have installed all do support export already so you would never have had a problem exporting for any of those boards.

1. Can I safely upgrade again to 1.8?
It definitely won't cause any problems for being able to export. Arduino AVR Boards 1.8.1 seems like a very good release.

2. And I have another 2 computers (Win 7 32b abd Win8.1 32b) -and for clarity, on another site another 2 computers with Win XP SP3) where I have not yet implemented this solution. Do I have manually to edit the platform.txt file in each of them?
Yes

3. Is the use of Google Drive a safe and reliable solution for storage of libraries and sketches?
I've never used it, maybe someone else can comment on this.

brice3010

Strange, are you using Digistump AVR Boards 1.6.7? Well it really doesn't matter, you can use any example for any of the Digispark libraries, I just used the first one on the menu. Or you can just navigate straight to the folder if you know where to find it. That's just an easy way I've found to tell people how to get to the correct folder since sometimes it's hidden.
I use this text in the preferences board management:

https://raw.githubusercontent.com/damellis/attiny/ide-1.6.x-boards-manager/package_damellis_attiny_index.json,
http://digistump.com/package_digistump_index.json,
http://arduino.esp8266.com/stable/package_esp8266com_index.json
https://mcudude.github.io/MicroCore/package_MCUdude_MicroCore_index.json

Would you recommend changing some of it?

I will remove the hardware descriptions of non-arduino boards in the hardware folder.

There are actually multiple hardware folders:
  • {Arduino IDE installation folder}/hardware - this should only contain Arduino AVR Boards core. You should never install any other hardware package to that folder because it will be lost when you update to a new version of the Arduino IDE.
  • {sketchbook folder}/hardware - this is where you manually install hardware packages
  • AppData\Local\Arduino15\packages... - this is where Board Manager installs hardware packages

Thank you very much for this clear explanation!

Generally you should be OK with the Arduino AVR Boards version included with your IDE, though you can update this via Boards Manager. Updating can sometimes be problematic if you're using an older IDE version because they're not so good about maintaining backwards compatibility but that shouldn't be a problem for Arduino IDE 1.6.12. I can see that you've manually installed ATTinyCore but I don't know which version you're running.
I looked it up in the boards.txt file and it says "Overhauled summer 2015 by Dr. Azzy (Spence Konde) and again early 2016 to add support for more chips", and in the ..\avr\cores\tiny\ folder the files are dated 4/11/2016

I'd recommend you to remove the manual installation of that core and instead use the Boards Manager installation as described here:
https://github.com/SpenceKonde/ATTinyCore/blob/master/Installation.md#board-manager-installation
because this will make it easier for you to keep updated to the latest version.
Will be done.

However, as I've said, that core is unrelated to your Digispark board, it is only used for the ATTinyCore boards.
If you installed Digistump AVR Boards 1.6.7 via Boards Manager following:
http://digistump.com/wiki/digispark/tutorials/connecting
Then they should have been automatically installed with the hardware package. Note that these examples will only appear when you have a Digispark board selected in the Tools > Board menu.
The Digistump AVR Boards package has never had the output recipes defined so there's nothing I know of that would have changed. Are you sure you were previously able to export with one of the Digispark boards? Note that the Arduino AVR Boards, ATTinyCore, and MicroCore packages you have installed all do support export already so you would never have had a problem exporting for any of those boards.
It definitely won't cause any problems for being able to export.
I am not so sure and as a matter of fact it must not have been possible.

EDIT: I just discovered what had happened before.. I had selected the Arduino Uno while using a Digispark sketch to compile the .hex file. And now I understand why it did not work when downloaded to a Digispark ....

But thank you for the advice and information, it is very usefull to me!

Arduino AVR Boards 1.8.1 seems like a very good release.
Note taken; thks for the advice. Will be installed.

Yes
Must I conclude that support for Digispark is dwindling?

Personaly I like the Digispark solution because they are cheaper to get then straight ATtiny85. I buy the boards, set the fuses as I wish, and either treat them as Digispark to download over USB, or treat them as ATtiny85 and download over ISP.

And I can use the same code, as long as the bootloader is present.

I've never used it, maybe someone else can comment on this.
How would you recommend using a cloud solution for software design on multiple locations?

I hope someone can share their experience but I think I better open a new thread for that (for the above question too).

So for me this is closed (except for the few questions I still have in this last post), I appreciate very much your help, it is invaluable!
Erik

brice3010

Pert,

yet one more question:

I had converted somehow a number of .ino files to .hex but in those folders I also see following files:

...ino.standard.hex

...ino.with_bootloader.standard.hex

and a temp file .tmp

(EDIT and NOTE: those were compiled with the Arduino board selected)

Is it not important for Digispark also to have a .hex with a bootloader included?

What text is required in platform.txt to get that output to the .ino folder too?



And what about .elf files? Usefull?

DrAzzy

Github for storing code in the cloud - that's what it's made for, and what most people use. Makes it much easier to track changes and sync them across multiple systems.
ATTinyCore for x4/x5/x61/x7/x8/x41/1634/828/x313 megaTinyCore for the megaavr ATtinies - Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

brice3010

Digispark Example sketches: where do these get stored?

I installed 1.8.1 on two machines, one W7 32b and one W7 64b: one installation has the samples included, the other not.

Digispark boards from http://digistump.com/package_digistump_index.json is included in the boards manager, and on both installations the Digispark boards are installed.

pert

I use this text in the preferences board management:

https://raw.githubusercontent.com/damellis/attiny/ide-1.6.x-boards-manager/package_damellis_attiny_index.json,
http://digistump.com/package_digistump_index.json,
http://arduino.esp8266.com/stable/package_esp8266com_index.json
https://mcudude.github.io/MicroCore/package_MCUdude_MicroCore_index.json

Would you recommend changing some of it?
Since you have ATTinyCore installed I don't see any point in having damellis/attiny also installed. It won't hurt anything other than adding an unnecessary entry to your Boards menu but it may confuse you as to which hardware package you're using to have multiple ones that support the same parts.

Must I conclude that support for Digispark is dwindling?
Their hardware package is certainly not being very actively developed. I'm sure it works fine as is but certain things will tend to fall behind the current state of the art without occasional updates. It's possible their sales are being hurt by the lower priced clones and the income doesn't justify putting resources towards development. Hopefully they'll at least take the time to consider my pull request. I submitted one last year and they merged it only a week later so that's pretty responsive.

How would you recommend using a cloud solution for software design on multiple locations?
I agree with DrAzzy that GitHub is great. It will take a small amount of effort to get used to using it but that will be very worthwhile for your own project and also if you want to contribute to other projects it's pretty much the standard these days. The only downside is that you have to pay $7/month if you want private repositories (public repositories are free). I don't use GitHub for some of my personal projects, not because I care if other people have access to them but just because I only like to publish things to GitHub that I think would be generally useful. Some of my projects are too specialized so they'd just clutter up my repositories list. However, I still use Git for all my projects and much of what you learn by using GitHub applies to any use of Git.

I had converted somehow a number of .ino files to .hex but in those folders I also see following files:

...ino.standard.hex

...ino.with_bootloader.standard.hex

and a temp file .tmp

(EDIT and NOTE: those were compiled with the Arduino board selected)

Is it not important for Digispark also to have a .hex with a bootloader included?

What text is required in platform.txt to get that output to the .ino folder too?
The reason exporting for a Digispark board doesn't produce a ...ino.with_bootloader.hex file is because they don't define the bootloader.file property in boards.txt so the Arduino IDE is unable to produce that file. The ...ino.with_bootloader.hex files allow you to upload a .hex file to a board without overwriting the bootloader, as will happen with the normal .hex file. So no changes would be needed to platform.txt, only to boards.txt. On http://digistump.com/wiki/digispark/tutorials/connecting it says:
Quote
We are not at this point supporting upgrading the firmware
so I'm not sure whether Digistump would be interested in adding that functionality to their hardware package but it couldn't hurt to submit a pull request if you get it working.

And what about .elf files? Usefull?
I've only used .elf files for doing disassembly using avr-objdump but I'm sure there are other uses for the file.

Digispark Example sketches: where do these get stored?
c:\Users\Mysafety\AppData\Local\Arduino15\packages\digistump\hardware\avr\1.6.7\libraries\Digispark_Examples

brice3010

#13
Jan 21, 2017, 12:36 pm Last Edit: Jan 21, 2017, 03:57 pm by brice3010
Since you have ATTinyCore installed

...

I've only used .elf files for doing disassembly using avr-objdump but I'm sure there are other uses for the file.
c:\Users\Mysafety\AppData\Local\Arduino15\packages\digistump\hardware\avr\1.6.7\libraries\Digispark_Examples
Hi pert, thanks again very much for your precise explanations!

Just this:

1. where would I have the ATTinyCore installed? I removed it from the hardware directory in Arduino.

2. And how would I be able to get these Digispark examples loaded automatically? I am sure I did something wrong as on one pc it is properly installed, but on my current machine here it is not (same W7 OS, except here it is 64b).

EDIT item 2.: Solved. I copied ..\packages\digistump\hardware\avr\1.6.7\libraries\.. from one pc to the other. I now get the examples too. And I installed Arduino 1.8.1 on a Win8.1 64b pc and all is present.

EDIT: I deleted the damellis attiny board manager and installed the one from drazzy. It supports a larger MCU base and seems (subjective opinion) more actively supported.

Erik

Go Up