Closed bgiot closed 4 years ago
Please re-test with upstream version http://docs.platformio.org/en/latest/platforms/atmelavr.html#upstream
Seems to work fine with upstream version. Had to build twice but now it's ok.
Thanks!
Ok, build goes through without error, but the result hex file doesn't seems to be ok. UI on the printer is not correct. Building with Arduino editor works fine and generated hex file is ok. As I'm not familiar with platform.io, I cannot figure out what's the issue...
How can it be correct that you write in the JSON file
"core": "rambo",
but your related PR (https://github.com/platformio/platformio-pkg-framework-arduinoavr/pull/22/files) creates a new arduino core in the folder prusa_rambo
?
Also related community forum discussion: https://community.platformio.org/t/error-when-building-latest-3d-printer-firmware/ The person that claims it works using a manual method.
Hello. I am the person from the PIO community forum who said manual method was working. Well it does build successfully, but I have the same LCD UI problem mentioned above. Sorry for any confusion.
See https://community.platformio.org/t/error-when-building-latest-3d-printer-firmware/9506/13?u=maxgerhardt, there is a bug in the return type of the lcd_putchar()
function, causing it to corrupt the display. This should be it.
@maxgerhardt Ivan Kravets renamed from 'prusa_rambo' to 'rambo' in both PR.
UI on the printer is not correct.
Do you use extra libraries?
@bgiot could you re-test with https://community.platformio.org/t/error-when-building-latest-3d-printer-firmware/9506/16?u=ivankravets?
@bgiot could you re-test with https://community.platformio.org/t/error-when-building-latest-3d-printer-firmware/9506/16?u=ivankravets?
Sure. Need to be at home tonight (CET+2) Question: do you want me to test with lcd.h/lcd.cpp fix ? or not ? (the change from void to int...)
@ivankravets I changed the lcd.h/lcd.cpp and the screen issue is gone.
Is this PIO Core's issue?
The problem is that the code uses a function returning void
as a functionpointer which expects int
as a return type, so depending on the optimization flags set for compilation, the compiler corrupts the stack / registers when trying to get the non-existent return value from the function, thereby messing all sorts of things up. So this is primarily a firmware issue and also the compiler generates a warning for it (reference). The firmware should be fixed instead of the compiler flags be adapted to not trigger the wrong behavior (which is 'undefined behaviour' and the compiler is totally allowed to do that in that situation) in my opinion.
I created a PR on Prusa repo with the fix. https://github.com/prusa3d/Prusa-Firmware/pull/2183
@stonehippo @ddlsmurf @jrbenito @eerimoq Any news ?