Prusa-firmware: Developer workflow concerns

[maxcom99]

I appreciate the work everyone is doing but why is the MK3_dev branch not being used if there is a need to commit breaking changes? The current MK3 branch should (IMHO) be operation / RC / UAT. It currently doesn't compile without reverting commits.

Is there any documentation on the workflow currently being followed or are we expected to work off of stable tags and not try to "get in your way"?

[maxcom99]

wiring.c.o (symbol from plugin): In function `__vector_23':

(.text+0x0): multiple definition of `__vector_23'

C:temparduino_build_309252sketchheatbed_pwm.cpp.o (symbol from plugin):(.text+0x0): first defined here

c:/users/usr/appdata/local/arduino15/packages/arduino/tools/avr-gcc/5.4.0-atmel3.6.1-arduino2/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ld.exe: Disabling relaxation: it will not work with multiple definitions

collect2.exe: error: ld returned 1 exit status

exit status 1
Error compiling for board RAMBo.

[Panayiotis-git]

Check DRacer's comment on https://github.com/prusa3d/Prusa-Firmware/pull/1979

[DRracer]

@maxcom99 you are right, there is no real documentation of the workflow and the MK3_dev is not used anymore.
The MK3 branch is the development branch, public releases are always tagged (as they roll out) and receive only major bugfixes if there is a need.
So if you guys want to try new (possibly broken) new features, please feel free to test the MK3 branch.
It's a work in progress, we'll try to document the process too, but as I've written elsewhere - please give us some time to settle, thank you ;) .
@Panayiotis-git thanks ;)

[DRracer]

@maxcom99 btw. can you try the build scripts in the firmware? Especially build.sh?
It should load a new board definition from here:
https://raw.githubusercontent.com/DRracer/Arduino_Boards/master/IDE_Board_Manager/package_prusa3d_index.json
Arduino IDE should be also working fine with this board definition (just switch to Prusa Rambo board).
It will get into mainline as soon as we finish our breaking changes. All this is because Arduino hardcodes ISR(TIMER0_OVF) in wiring.c and we saw no other way of getting rid of it :( .

[Panayiotis-git]

Should replace the Prusa's board definition with the DRacer's one for the new board to be available for selection.

After that, I've managed to build the project with the sloeber eclipse plugin (and the Arduino IDE) and upload the firmware to the printer.

[maxcom99]

Thank you for the update, ill try tonight. @DRracer I feel like the "Arduino hardcodes" are the least of the problems ...

I am presonally looking to abstract out all the calibration stuff from https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/ultralcd.cpp because holy man this is a disaster....

[maxcom99]

@maxcom99 btw. can you try the build scripts in the firmware? Especially build.sh?
It should load a new board definition from here:
https://raw.githubusercontent.com/DRracer/Arduino_Boards/master/IDE_Board_Manager/package_prusa3d_index.json
Arduino IDE should be also working fine with this board definition (just switch to Prusa Rambo board).
It will get into mainline as soon as we finish our breaking changes. All this is because Arduino hardcodes ISR(TIMER0_OVF) in wiring.c and we saw no other way of getting rid of it :( .

Im on a windows machine for dev (so havent tested build.sh) ... it seems you guys at least used to be on visual studio eh?

[MaleNurse]

@DRracer For me (on Ubuntu through Windows Subsystem for Linux) the only script that doesn't work is PF-Build.sh, even after changing the build environment version in the script and it downloading correctly. The error it gives is "Error: rambo: Unknown package" so I assume it has something to do with Arduino not finding the new board definition that is in the 1.0.6 build-env. I tried playing around with the --board option in the script as well, taking guidance from the here, but still no luck.

On the Arduino IDE (1.8.9) front, all's well once I plugged your version of the Board Manager JSON in, but I did notice that I had to get rid of Prusa3D's URL (the one for the MMU2/S hardware) in order for the Board Manager to display the new RAMBo board and allow it to be installed. I know that's probably not your problem, though.

[DRracer]

I am presonally looking to abstract out all the calibration stuff from https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/ultralcd.cpp because holy man this is a disaster....

Indeed, looking forward to your contribution. But make sure your code is shorter (and cleaner) than the current "disaster" ;)

[DRracer]

@nebbywan The MMU board should be available from the new board definition json file too. May be you just need to run board manager in Arduino IDE and let it download the MMU again. The new board definiton will return to the prusa3d repo once all this is finished.

[MaleNurse]

@DRracer So it is! Got so confused by IDE giving me the runaround that I didn't even notice it there 😅 Thanks!

[maxcom99]

Just to confirm, sorry for the delay. With the new board definition everything seems to be compiling again and working well on MK3S. Time to rip things apart.

[MaleNurse]

All compilation methods I've tried worked fine except for PF-build.sh, and it seems to be chugging along well on my MK3S w/ MMU2S.

[3d-gussner]

Opened PR https://github.com/prusa3d/Prusa-Firmware/pull/2028 with new PF-build.sh
@nebbywan give it a try ... feedback appreciated

[MaleNurse]

@3d-gussner Sorry for the delay. Working good! I did notice that Ubuntu via WSL on earlier builds of Win10 (e.g. 1709 build 16299.1217, like I'm stuck using at work) don't seem to like the "bullet" character at the end of $BUILD though (see attached image). It throws something akin to "Cannot create directory: 'FW372-Build2363r': No such file or directory". The latest and greatest don't seem to have any issues though.

edit: forgot to add that the $BUILD thing isn't new as the previous version of the script also behaves like this. Also that it's $BUILD not $BUILD_ENV

[leptun]

That bullet is actually a real problem for me. It’s because of the incompatibility between windows and linux regarding LFCR. That dot is probably the CR charracter. The real problem is that you can’t open that file from windows with avrdude because of that character.
The sollution for me was creating another script that runs dos2unix on all files and then runs PF-build.sh. It however messes with git/gitkraken and makes ghost changes. Those are however easily cleared by staging the affected files and the changes disappear. The only file that doesn’t work like that is heatbed_pwm.cpp.

[3d-gussner]

@nebbywan @leptun Thanks for the feedback.

When I use dos2unix -ic *.* the only tfile it finds is heatbed_pwm.cpp.
Also using notepad++ with View -> Show Symbol -> Show All Characters I just see LF
The same with find *.* -not -type d -exec file "{}" ";" | grep CRLF | sed 's/:.*//g'

I have no idea why dot is there as the variable is generated with BUILD=$(grep --max-count=1 "\bFW_COMMIT_NR\b" $SCRIPT_PATH/Firmware/Configuration.h | sed -e's/ */ /g'|cut -d ' ' -f3) , Tried echo Test$BUILD"Test" and result is Test2363Test nothing between.

@leptun you can run le.sh located in Firmware folder to convert CRLF line to LF.

[GurliGebis]

Would having an editorconfig file defining LF as the new line segment be an option, to help the different editors people use act identical?

[DRracer]

@maxcom99 thanks for confirmation, would you mind closing this issue?