Adding BOOTLOADER option to support Robotis bootloader different ROM

[Gregwar]

This introduces a BOOTLOADER option in the Makefile, allowing to specify the bootloader that will be used

This is because the robotis bootloader starts for instance the program at 0x8003000 instead of 0x8005000

[Gregwar]

I've also wrote a python loader for Robotis:
https://github.com/Gregwar/robotis-loader

In our environment, we've also changed the "make install" regarding the bootloader option, adding the loader script in support/.

This allows to "make install" directly on the board of robotis without changing the bootloader.

However, we've introduced BOOTLOADER_PORT in our makefile because we can't detect it automatically

[mbolivar]

Cool, I'll definitely review this ASAP. In the meantime, can you please add a sign-off line to your commit and force-push into this same branch, as described in the HACKING file?

[Gregwar]

OK, and should I add the "make install" hack to use my loader to flash robotis-based boards?
If you want to try, you may buy an OpenCM9.04 or a CM900, do you have such board?

[Gregwar]

I've also added the loader script and changed the hook for the robotis case

Now, if I do:

BOARD=opencm904 BOOTLOADER=robotis make
BOARD=opencm904 BOOTLOADER=robotis make install

I'm flashing the board, keeping the compatibility with original robotis IDE

[Gregwar]

Summary of this PR changes:

• Adding BOOTLOADER option in the Makefile, that defines -DBOOTLOADER_value
• Adding support for robotis bootloader, including:
  • Changing the linking options on the opencm904 and cm900 boards to set flash begining at 0x8003000
  • Changing the USER_ADDR_ROM in wirish/boards.cpp in the case of robotis to 0x8003000
  • Changing the reset hook in the case of robotis (trigerring when RTS set high and DTR low then CM9X string sent)
  • Changing the make install behaviour in the case of robotis to use robotis-loader.py to send data to the board

[mbolivar]

You know, I'd honestly prefer to do this in a less special-cased way, but I'm going to go ahead and merge it, since you're the first third party in a long time to add support for their boards to libmaple, and it's nice to see an old project still getting some love ;).

A lot of the special-casing going on here is due to implementation choices we made before we had to support boards other than our own, or boards with non-default bootloader settings, anyway, by the looks of things.

If another pull request comes in which adds even more special cases, though, I'll probably refuse it until the more generic changes I propose in the rest of this comment are made, though. Feel free to do these cleanups yourself and send another PR (that would be super awesome):

Cleanup 1

It would be better for each board file in support/make/board-includes files to specify the RAM/ROM base offsets numerically, based on the current MEMORY_TARGET.

For example, if MEMORY_TARGET was "flash", maple.mk would set some new variables like so:

LD_RAM_ORIGIN := 0x20000C00 LD_ROM_ORIGIN := 0x08005000 LD_RAM_LENGTH := 17K LD_ROM_LENGTH := 108K

Your board files would be similar, except with smaller xxx_ORIGIN and correspondingly larger xxx_LENGTH.

Once that's done, we could replace all of the crap in support/ld/stm32/mem by autogenerating the .inc file in the build/ directory based on the LD_{RAM,ROM}_{ORIGIN,LENGTH} variables. The flash.ld, jtag.ld, and ram.ld linker scripts could be left unchanged; the linker include path just needs the directory for the generated file.

These variables would also let us eliminate the per-board special casing of USER_ADDR_RAM and USER_ADDR_ROM in wirish/boards.cpp, which definitely won't scale if more boards get added with still different bootloader offsets.

Cleanup 2

I'm really not a fan of all the per-board special casing going on in wirish/usb-serial.cpp (though it's definitely our fault for sticking our board-specific stuff there in the first place). The non-common bits of functionality should get ripped out and replaced with weak definitions that can be overridden in wirish/boards/BOARDNAME/board.cpp.

[mbolivar]

Cleanup 3

All the special-casing in the top-level makefile should also get replaced with hooks drawn from support/make/board-includes.

[Gregwar]

I agree, it would be nice to do those cleanups

One more cleanup: I think that the "BOOTLOADER ?= ..." should also be contained in the board include files, the default bootloader for opencm904 could be robotis.

For .inc generation, I guess it could be done with "echo" and ">"/">>" in a Makefile rule, it would be compatible with both linux and windows.

Why do you call it "old project", Maple & Maple mini are still in production and available in a lot of stores

Moreover, ROBOTIS based OpenCM on the libmaple (guess you're aware: https://github.com/robotis-pandora/ROBOTIS-OpenCM/tree/master/OpenCM_ide/processing-head/hardware/robotis/cores/robotis), this board is in production and is likely to be really more used when their new servos will be on the market.

libmaple is really handy and clean, we're using it in some robotics project.

[mbolivar]

I agree about the BOOTLOADER cleanup.

When I say "old project", I mean we don't have the developer resources to actively move the platform forward as quickly as we once did. I love libmaple and think it's how MCU libraries should be done, even if I do say so myself ;). Thank you very much for the kind words, and I look forward to seeing Robotis succeed.

On April 30, 2014 1:28:40 AM PDT, "Grégoire Passault" notifications@github.com wrote:

I agree, it would be nice to do those cleanups

One more cleanup: I think that the "BOOTLOADER ?= ..." should also be
contained in the board include files, the default bootloader for
opencm904 could be robotis.

For .inc generation, I guess it could be done with "echo" and
">"/">>" in a Makefile rule, it would be compatible with both linux and
windows.

Why do you call it "old project", Maple & Maple mini are still in
production and available in a lot of stores

Moreover, ROBOTIS based OpenCM on the libmaple (guess you're aware:
https://github.com/robotis-pandora/ROBOTIS-OpenCM/tree/master/OpenCM_ide/processing-head/hardware/robotis/cores/robotis),
this board is in production and is likely to be really more used when
their new servos will be on the market.

libmaple is really handy and clean, we're using it in some robotics
project.

---

Reply to this email directly or view it on GitHub:
#89 (comment)