Totally, I’m a fan of the new progress bar. I know those guys are close to releasing 0.8, so it’s better to catch them now while they’re actively working on it 
2 Likes
Hmm im throwing this error with this new dfu-util… is my code too big? fow much flash do we have?
Opening DFU capable USB device…
ID 1d50:607f
Run-time device DFU version 011a
Claiming USB DFU Interface…
Setting Alternate Setting #0 …
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash "
Downloading to address = 0x08005000, size = 111316
Last page at 0x080202d3 is not writeable
RUN FAILED (exit value 74, total time: 175ms)
Yep, you are over the limit of 110592 
1 Like
hmmm… i knew it was getting big with all the menus! now to work out my options… i might have to move all my menu stuff into a pc app and just then send the results to the core with serial… maybe over the web hmmm
hi @Hootie81 You can try removing unused components to free up flash. For example, you can remove any or all of I2C, EEPROM, UDP, TCP, Servo, SPI etc… - you do this by putting a ‘#’ at the start of the line with the relevant file in src\build.mk. E.g. to remove I2C
change
CPPSRC += $(TARGET_SRC_PATH)/spark_wiring_i2c.cpp
to
# CPPSRC += $(TARGET_SRC_PATH)/spark_wiring_i2c.cpp
You should see your flash size (and RAM size) decrease. If you get any linker errors, then that means you were using those functions, and you’ll have to include them again.
1 Like
As far as I can tell stubbing out the C++ Classes doesn’t really help a whole lot. I ditched like 6 of them and only gained 300 bytes of Flash. However that was without the EEPROM one… adding EEPROM got it down to almost 900 bytes savings total. Could be useful if you are JUST over the edge. I’ll have to remember it just in case 
make clean all make work for you in the build directory… if not, try my windows batch file:
Run from the root of all 3 libraries.
@ECHO OFF
ECHO BUILDING PROJECT!!!
rmdir /S /Q core-firmware\build\obj
rmdir /S /Q core-common-lib\build\obj
rmdir /S /Q core-communication-lib\build\obj
cd core-firmware\build
make
cd ..\..\
1 Like
@Hootie81 is 724 bytes over the edge - removing unused components is a simple strategy to getting his flash down to size.
These are the components I removed:
# CPPSRC += $(TARGET_SRC_PATH)/spark_wiring_eeprom.cpp
# CPPSRC += $(TARGET_SRC_PATH)/spark_wiring_i2c.cpp
# CPPSRC += $(TARGET_SRC_PATH)/spark_wiring_interrupts.cpp
# CPPSRC += $(TARGET_SRC_PATH)/spark_wiring_ipaddress.cpp
# CPPSRC += $(TARGET_SRC_PATH)/spark_wiring_network.cpp
# CPPSRC += $(TARGET_SRC_PATH)/spark_wiring_servo.cpp
# CPPSRC += $(TARGET_SRC_PATH)/spark_wiring_spi.cpp
# CPPSRC += $(TARGET_SRC_PATH)/spark_wiring_tcpclient.cpp
# CPPSRC += $(TARGET_SRC_PATH)/spark_wiring_tcpserver.cpp
# CPPSRC += $(TARGET_SRC_PATH)/spark_wiring_tone.cpp
# CPPSRC += $(TARGET_SRC_PATH)/spark_wiring_udp.cpp
# CPPSRC += $(TARGET_SRC_PATH)/spark_wiring_usartserial.cpp
Size with optional components removed:
text data bss dec hex filename
68724 536 10992 80252 1397c core-firmware.elf
And then with them included, for a blank application.cpp
text data bss dec hex filename
70444 612 11520 82576 14290 core-firmware.elf
Text + data is 69260 before, and 71056 after. That’s a saving of 1769 bytes.
When you’re stuck with code that’s too big, those 1769 bytes are a very welcome saving!
Oh, one other thing, you don’t need to clear out the obj files - the system simply doesn’t link them if it’s not in the build.mk file.
1 Like
Right. I fully agree. I was just kind of thinking when you mentioned it that maybe there would be some substantial size change like 20KB… Even though I’ve always been under the impression that the compiler/linker handles everything pretty efficiently. So I thought it would be good to put some numbers down
1 Like
I did a bit of cleaning in my code too… took out a lot of the De-bugging code and streamlined the menu system and reused code for the menu headers, and simplified the code for displaying text on the Digole. Thats slimmed it down to 105k so it fits again
1 Like
Thats an interesting number! if my code gets to that number not including the data the compiler throws an error. but doesnt take into account the data.. which dfu seems to include.
I stole that number from the Web IDE… not sure how accurate it is. Hmm…
within 4 bytes of where my compiler says nope… thats as close as i could get it
this is what i get at the end of compiling… the compiler says no when the text gets to about 110592 and dfu-util says no when text + data gets to 110592 ish… havent worked out the magic line of code to add to test how close it gets
Invoking: ARM GNU Print Size
arm-none-eabi-size --format=berkeley core-firmware.elf
text data bss dec hex filename
107928 1904 14044 123876 1e3e4 core-firmware.elf
Ah sorry, there is 128k of application flash on the Core, and the first 20k is reserved for the bootloader, leaving you about 108k