Report Bugs Here

Moderator: Mmiscool

User avatar
By Electroguard
#67130 Yeah, portable setup seems to be working fine.
A few gotchas to point out for anyone following behind...

Copy the fresh unzipped arduino 1.6.5 folder where you want it, but don't run the arduino executable until you've created the new portable folder inside it else it won't create a portable configuration when first run, and if you try to do it later you won't easily undo whatever 'permanent' configuration it's already done.

So create the portable folder.
Then run arduino executable so it can create the appropriate structure inside it.
Then copy both the ESP8266Basic and libraries folders from the unzipped espbasic source into the newly created portable\sketchbook folder (you can simply ignore the duplicate libraries\readme warning).
Add the following link into the preferences url
http://arduino.esp8266.com/versions/2.3.0/package_esp8266com_index.json
then go to the bottom of the list in tools, boards manager and install it (it can take a long time).
Once an appropriate ESP8266 board has been selected, you should be able to open
portable\sketchbook\ESP8266Basic\ESP8266Basic.ino
and compile it ok.

Then if you're like me you'll probably feel like you've got a tiger by the tail but don't know what to do with it!

B.T.W. I've compiled and uploaded to an ESP and confirmed the bug is still there as expected, but how do I save a compiled bin file version instead of uploading it?
User avatar
By bugs
#67132 I find the binary file by setting the arduino (File->Preferences->Show verbose output [tick]) and looking near the end of all the waffle.
Example from the blink sketch:-
Code: Select allLinking everything together...
"E:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-gcc" -w -Os  -Wl,--gc-sections -mmcu=attiny85  -o "e:\Temp\builde4ae8b204f5ca14fdfb47f2f793d200e.tmp/Blink.ino.elf" "e:\Temp\builde4ae8b204f5ca14fdfb47f2f793d200e.tmp\sketch\Blink.ino.cpp.o" "e:\Temp\builde4ae8b204f5ca14fdfb47f2f793d200e.tmp/core\core.a" "-Le:\Temp\builde4ae8b204f5ca14fdfb47f2f793d200e.tmp" -lm
"E:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-objcopy" -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0  "e:\Temp\builde4ae8b204f5ca14fdfb47f2f793d200e.tmp/Blink.ino.elf" "e:\Temp\builde4ae8b204f5ca14fdfb47f2f793d200e.tmp/Blink.ino.eep"
"E:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-objcopy" -O ihex -R .eeprom  "e:\Temp\builde4ae8b204f5ca14fdfb47f2f793d200e.tmp/Blink.ino.elf" "e:\Temp\builde4ae8b204f5ca14fdfb47f2f793d200e.tmp/Blink.ino.hex"

This shows a temporary sub- directory is created - keep the IDE open until you have rescued the binary as the directory gets deleted on closing.
User avatar
By trackerj
#67147
bugs wrote:Glad you made some progress.
Using the same files as you, I get the same size binary file 438,176 bytes.
This size does not agree with any of the binaries in the espbasic unzipped file in the flasher\build sub directories. The nearest would be 438,240 in the 512k and 1M directories. So presumably something has to be changed to get a 2M or 4M build.

Fo interest I quickly tried Arduino 1.8.3 but the error list stopped that short.
Code: Select allClasses.h:275: error: 'PrintAndWebOut' was not declared in this scope
Classes.h:385: error: 'VarialbeLookup' was not declared in this scope
Classes.h:412: error: 'SetMeThatVar' was not declared in this scope
Classes.h:456: error: 'evaluate' was not declared in this scope


I think sticking to 1.6.5 is best...


I agree with you, it will be great to know what's the difference between this locally compiled fw and the provided 2M or 4M builds.
User avatar
By Oldbod
#72308 Just happened to be passing. I was playing with this last year as first step in learning c. (Never got past the first step)

I believe the difference is probably due to the build used by mike being very slightly different - he's posted in tbe past iirc due to the way the different versions are automatically generated. As the bug is reproducible in the versions people have built seems this probably isnt responsible for the bug and 'home built' versions are a valid test ground.

I would guess in some ways espbasic drives the chip harder than anything originally envisaged - for example, supporting two display types - no reason why a production device has to do that...