RAMBo board definition

[DRracer]

No description provided.

[DRracer]

@3d-gussner please have a look at this PR. I've removed links to your repo and mine too, let's finalize our effort by reviewing the changes and merging it into prusa3d main repo. Thank you ;)

[3d-gussner]

@DRracer I will review it asap and test it.
The changes everything are looking good. Have to double check these.

What borders me a bit is the name Original Prusa i3 MK3/MK3S Einsy RAMBo as this will be used to compile the MK3/s EINSy and MK2/s 2.5/s miniRAMBo

• As both boards use the same architecture and same firmware that distinguish these in the code, we could use another universal name. This would make it clearer to GUI users and easy to maintain as there is just one folder.
• Or add another variant with the same settings. Downside is to maintain both.

Are you interested in:

1. Getting the bootloader for the EINSy board in the Arduino_Boards as well? Advantage is that bricked EINSYy boards can be 'reanimated'. You also have the bootloader in for the MMU2 here.

2. Lock down the build environment to IDE 1.8.5 with boards definition 1.6.20 and so avr-gcc 4.9.2-atmel3.5.4-arduino2 , avrdude 6.3.0-arduino9 , arduinoOTA 1.1.1 are stored and used under PrusaResearch folder. At this moment i added a check to PF-build.sh if the Arduino AVR boards have been manually updated, the script will stop if so!

• Pros: Even if user update the Arduino AVR boards in their GUI compiling the Prusa EINSy will force to use the 'stock/fixed' tools.
• Cons: People (like me) will not be able to test newer Arduino IDE versions
  • This could be solved if we add another version 1.0.2-alpha to the JSON file so user can use that one to test newer versions. On the other hand PF-build.sh will use the latest stable one (now 1.0.1)

I started with a new branch https://github.com/3d-gussner/Arduino_Boards/tree/Bootloader

• Bootloader works ...
• Lock down works as well ...
• These two could be moved easily to 1.0.1
• And remove lock down in 1.0.2-alpha

While writing all of this maybe the best would be:

• just to add the bootloader to get un-brick function
• Use an universal name for the EINSy and miniRAMbo
• If user f..kup their build environment they have to fix/re-install it. Check via scirpts if the build environment is compromised.

[DRracer]

@3d-gussner thank you ;)
Name: please propose a better variant, sounds reasonable
Bootloader: that would be great
Lockdown: I'd also prefer a more benevolent environment, i.e. not locking to one particular avr-gcc or whatever.
Btw. I was originally thinking about adding the RAMBo to the same subtree as the MMU, but the Arduino IDE wasn't able to distinguish among them. Then the JSON would have a better structure - one vendor PrusaResearch a 2 boards. If you know how to, please feel free to propose ;)

[3d-gussner]

@DRracer Thanks for the fast answer. I will try to get a propose done soon. May take some time as it needs testing.

Name proposals:

• Platform Name: From Prusa Research AVR MK3 Einsy RAMBo to Prusa Reasearch AVR Printer Boards ... like the Prusa Research AVR MMU Boards
• Name: Original Prusa i3 MK2/MK2S/MK2.5/MK2.5S/MK3/MK3S EINSy RAMBo is way to long Original Prusa i3 MK2-3S EINSy/RAMBo ?

[DRracer]

@3d-gussner Prusa Reasearch AVR Printer Boards looks good
I'd stick with Original Prusa i3 MK3/MK3S Einsy RAMBo, since the board definition is not supposed to work with MK2 FW.

[3d-gussner]

@3d-gussner Prusa Reasearch AVR Printer Boards looks good

Check

I'd stick with Original Prusa i3 MK3/MK3S Einsy RAMBo, since the board definition is not supposed to work with MK2 FW.

As the MK2 has the identical board as the MK2.5/s it should also work with the MK2 branch. And MK2.5/s user may get confused if their board isn't shown.

[DRracer]

@3d-gussner the HW is compatible, but please note why we did all this - to silence the bed we had to reallocate timer0 for HW PWM of bed heating. And changing ISR(TIMER0_OVF) is not possible without patching standard Arduino core or making a special board definition (with patched core :) ). This change is not going into the MK2 branch.

[3d-gussner]

I tried few things but still getting errors...need to test more...sorry

[DRracer]

@3d-gussner ok, thanks for info. So far so good, I'll merge this for now to move forward with FW 3.8. When you are done please feel free to post new PR's with improved functionality.

[3d-gussner]

@DRracer no problem... It is more difficult than i thought and have quite delay until github has the new commit on all servers. Took me in beginning long to figure out that there is a delay.

[3d-gussner]

@DRracer I got the bootloader and cleanedup other things in https://github.com/3d-gussner/Arduino_Boards/tree/V1.0.2

To merge MMU2 and EinsyRAMBo board i have some questions:

1. Why does did you/Prusa/@mkbel add https://github.com/3d-gussner/Arduino_Boards/blob/V1.0.2/IDE_Board_Manager/prusa3dboards/avrdude.conf to the MMU2 package?

   • As far i can see it isn't used anywhere

2. Why is the MMU2 platform.txt different from EinsyRAMBo platform.txt at line 104/105?

tools.avrdude.upload.pattern="{cmd.path}" "-C{config.path}" {upload.verbose} {upload.verify} -p{build.mcu} -c{upload.protocol} -P{serial.port} -b{upload.speed} -D "-Uflash:w:{build.path}/{build.project_name}.hex:i"

instead of

tools.avrdude.upload.pattern="{cmd.path}" "-C{config.path}" {upload.verbose} {upload.verify} -p{build.mcu} -c{upload.protocol} "-P{serial.port}" -b{upload.speed} -D "-Uflash:w:{build.path}/{build.project_name}.hex:i"

To be more clear, why are -P{serial.port} and "-P{serial.port}" different?

3. As the compiler.c.elf.flags= for the EinsyRAMBo need additional values -Wl,-u,vfprintf -lprintf_flt -lm would it harm the MMU2 compiling if these are set there as well?

Why do i ask: As far I understand a Boards manager package/platform just contains one boards.txt and one platform.txt file.

• The boards.txt was easy to merge both boards as the board-names are unique.
• Merging two different platform.txt seams to be more complicated.
  • different tools.avrdude.upload.pattern=
  • different compiler.c.elf.flags=

Also open issue is the avr6.xn change for 2nd language support.

• As the MMU2 controller has a tiny tiny chip and already uses a lot of space. I don't think that is an option.

Maybe I find somewhere a solution for these issues.