These are chat archives for esp8266/Arduino

14th
May 2015
Ivan Grokhotkov
@igrr
May 14 2015 11:21
@Makuna Imroy/pubsubclient#1
there does seem to be an issue if PROGMEM is used in argument list
Markus
@Links2004
May 14 2015 14:10
what is Fatal exception (28)?
is there any list who lists all Fatal exception?
ficeto
@ficeto
May 14 2015 14:11
+1 on that
Michael Miller
@Makuna
May 14 2015 14:20
looking into it
Ivan Grokhotkov
@igrr
May 14 2015 14:25
yes it's in xtensa reference manual
Michael Miller
@Makuna
May 14 2015 14:25
PROGMEM only should have been applied to global variables.
Is that even valid syntax? that parameter should not have defined that way for AVR, it should be..
   bool publish_P(String topic, PGM_P* payload, unsigned int, bool retained = false);
Ivan Grokhotkov
@igrr
May 14 2015 14:26
I've got a PDF of that. will post it here when I get to my laptop
Markus
@Links2004
May 14 2015 14:26
@igrr yay
Ivan Grokhotkov
@igrr
May 14 2015 14:26
okay, so does it fail to compile for AVRs?
Michael Miller
@Makuna
May 14 2015 14:26
testing now
Michael Miller
@Makuna
May 14 2015 14:35
unfortunately it does compile on AVR target.
Michael Miller
@Makuna
May 14 2015 14:41
Ok, the usage being used is deprecated, as per the comments in the pgmspace.h from Arduino.cc versions.
This typedef is now deprecated because the usage of the progmem
attribute on a type is not supported in GCC. However, the use of the
progmem attribute on a variable declaration is supported, and this is
now the recommended usage.
Markus
@Links2004
May 14 2015 14:43

gcc workaround

#define F(str)  []() -> const char * { static const char tmp[] ICACHE_RODATA_ATTR = str; return &tmp[0]; }()

for the variable

Michael Miller
@Makuna
May 14 2015 14:44
this isn't about the variable, its about the definition of the function. I get a compile error without ever calling the function.
in the esp8266 PgmSpace.h we "lost" the comments when it got translated. A bunch of stuff got deprecated at one point in the AVR (and marked with attribute so it shows in the compile) and they were all the type definitions using PROGMEM.
Ivan Grokhotkov
@igrr
May 14 2015 14:48
OK, thanks for taking a look. So this should be fixed in the library then.
Michael Miller
@Makuna
May 14 2015 14:48
@Links2004 I don't see a need for that work around, what was it solving?
@igrr correct, I also think we need to add back those comments about deprecation so its clear if someone investigates this in the future.
Markus
@Links2004
May 14 2015 14:52
its force the variable to ".irom.text" area in flash. but eave "const char" places it in flash but then in ".bss"
Michael Miller
@Makuna
May 14 2015 14:59
The "original" Arduino code for PSTR() and F() works as is with the correct definition for PROGMEM, what is the benefit of that over the original defines?
#define PSTR(s) (__extension__({static const char __c[] PROGMEM = (s); &__c[0];}))

#define F(string_literal) (reinterpret_cast<const __FlashStringHelper *>(PSTR(string_literal)))
Markus
@Links2004
May 14 2015 15:14
it is returning direct an const char * type so its working with many functions without the need to implement the __FlashStringHelper class handling
Michael Miller
@Makuna
May 14 2015 15:15
@Links2004 You weren't supposed to use F() for that, you were to use PSTR() for that purpose.
The whole __FlashStringHelper was to create a unique pointer type so the compiler could pick between methods that have the same name but give them unique signatures.
If you have the name_P method, then the use of PSTR() is required.
Markus
@Links2004
May 14 2015 15:17
k good to know.
Michael Miller
@Makuna
May 14 2015 15:18
All this is Arduino (AVR/ARM) compatible so we get cross platform support.
BTW, the built Arduino AVR from this depo, are any of the avr header files modified? As I was just looking at 1.63 PgmSpace.h and it is different than the once included in the depo, a bunch of types are marked deprecated now and this is where that comment I quoted above comes from.
Difference between 1.61 and 1.64?
Ivan Grokhotkov
@igrr
May 14 2015 15:35
perhaps, need to check
ficeto
@ficeto
May 14 2015 15:44
so... attempting to flash and boot from SD here
i do fail on writing to the SD though
bootloader connects and fails when starting to transfer the 0x0000 binary
if someone has buddies at espressif, any info will be welcomed
search for exccause
Markus
@Links2004
May 14 2015 16:08
nice at page 89
Markus
@Links2004
May 14 2015 16:23
any idea what goes wrong when the free heap goes to negative values? when i get them the program still runs and at some random pint around 5sec later it crashes with Fatal exception (9)
Markus
@Links2004
May 14 2015 16:48
o hell the os_free looks buggy
void free(void* ptr) {
    if(ptr) {
        uint32_t free = system_get_free_heap_size();
        os_printf("[free] ptr: 0x%08X heapPre: %d 0x%08X\n", ptr, free, free);
        os_free(ptr);
        free = system_get_free_heap_size();
        os_printf("[free] ptr: 0x%08X heap: %d 0x%08X\n", ptr, free, free);

    } else {
        os_printf("[free] free a null ptr is a bad idea!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!\n");
    }
}

output at some point:

[malloc] ptr: 0x3FFF5CA0 size: 60 heapPre: 25424 0x00006350 heap: 25344 
[free] ptr: 0x3FFF5CA0 heapPre: 25168 0x00006250 
[free] ptr: 0x3FFF5CA0 heap: -2043549567 0x8631E881

this is really bad!

Markus
@Links2004
May 14 2015 16:56
anyone an idea?
marcoschwartz
@marcoschwartz
May 14 2015 17:09
Hello there! Since the last commit I am having problems with PROGMEM stuff, in my aREST library for example:
/Users/marco/Dropbox/Arduino/libraries/aREST/aREST.h: In member function 'void aREST::addToBuffer(const __FlashStringHelper)':
/Users/marco/Dropbox/Arduino/libraries/aREST/aREST.h:962:23: error: section attribute cannot be specified for local variables
const char PROGMEM
p = (const char PROGMEM *)toAdd;
Markus
@Links2004
May 14 2015 17:40
ok if i add a check to block all os_free and os_malloc calls if i see a free heap size bigger the 0x14000 (dram size) my application dont crash anymore.
but the big question where the problem in the memory managment is coming from.
has anyone ever seen problems with the malloc/free stuff form espressif?
of course my application can not work anymore it the not get the ram they ask for ;)
ficeto
@ficeto
May 14 2015 17:43
almost all memory issues I have had were caused by my own crap
maybe even all
network keeps resources
so on a busy http app it will fill up fast
but those get released as we have talked
the rest were all coding mistakes
Markus
@Links2004
May 14 2015 17:44
but malloc shut not crash if there no space left it shut return a null ptr
ficeto
@ficeto
May 14 2015 17:45
maybe I have not run into that case so far
Markus
@Links2004
May 14 2015 17:45
will try trigger the bug with s simple example
ficeto
@ficeto
May 14 2015 17:45
or have not cought it
espressif do not seem to be good coders
so god knows what's behind os_malloc
Markus
@Links2004
May 14 2015 17:46
yes
Michael Miller
@Makuna
May 14 2015 18:23
@marcoschwartz Using PROGMEM on a local or writable variable is an incorrect use pattern. The latest Arduino 1.63+ makes this more obvious with deprecating most of the old prog_ types
@marcoschwartz Pointer Variables should be defined as PGM_P generally. But you need to be careful that they get passed to methods that can read them (*_P()).
Michael Miller
@Makuna
May 14 2015 18:45
Looks like dtostrf is broken, I may have a fix, testing now.
Michael Miller
@Makuna
May 14 2015 18:59
esp8266/Arduino#242 submitted to fix dtostrf and String(float) support.
ficeto
@ficeto
May 14 2015 23:34
@Links2004 I think that the SPI clock does not divide by the CPU clock
when I up the clock to 160, my SD speed is slower
just reverting the CPU clock and it's all fine
so unless something prevents the chip from actually running at 160MHz
the SPI clock is also divided by the APB clock which is constant 80MHz