search

chipKIT32 / chipKIT32-MAX

Multi-platform IDE derived version from Arduino 0022 for the chipKit.
http://chipkit.net
Other
108 stars 76 forks source link

Add raspberrypi build target to build.xml #313

Closed ricklon closed 10 years ago

ricklon commented 11 years ago

Add raspberrypi build target to build.xml

majenkotech commented 11 years ago

I guess this is just a clone of the Linux build, but using a RPi binary of the toolchain. Does that toolchain exist at the moment?

The bootloader / board system would need to be modified to take the pi as an alternative host OS for commands to be run (command_windows, command_macos, command_raspberrypi, etc)

Raspberry avrdude would also be needed.

ricklon commented 11 years ago

The toolchain exists. I added the changes on a RaspberryPi, but lost the SD card. I need to do it again. :-(

Avrdude, and the Toolchain both exist so it will work great. Only needs the toolchain copied.

--Rick

On Mon, Jun 10, 2013 at 7:10 PM, majenkotech notifications@github.comwrote:

I guess this is just a clone of the Linux build, but using a RPi binary of the toolchain. Does that toolchain exist at the moment?

The bootloader / board system would need to be modified to take the pi as an alternative host OS for commands to be run (command_windows, command_macos, command_raspberrypi, etc)

Raspberry avrdude would also be needed.

— Reply to this email directly or view it on GitHubhttps://github.com/chipKIT32/chipKIT32-MAX/issues/313#issuecomment-19232230 .

Co-founder Fair Use Building and Research (FUBAR) Labs http://fubarlabs.org

majenkotech commented 11 years ago

For the "drop a board into the boards folder and just use it" schema the core will need to be able to differentiate between different Linux architectures in order to load the right flavour of tools. It's fine as it stands for "core" boards where the tools that get bundled with the distribution packages are single arch, but a "generic" board folder would (should) have the tools it needs for all architectures (if any non-standard ones are needed), so knowing which is for linux-x86 and which for linux-arm etc is important. The core routines that detect the operating system will need tweaking to include .isLinuxPi() or something similar. Maybe a more generic .getOsArch() function would be better, which returns a string of something like "{os}_{arch}", like "linux_arm" or "macos_x86_64" for example. That could be used "as is" to reference platform specific commands in the bootloader.txt files.

majenkotech commented 11 years ago

My Pi is in a position where I can sort this out. Can you point me to the arm binaries, or shall I build my own from JK's repo?

majenkotech commented 11 years ago

Ok, I have tweaked my local copy to make the programming executable completely generic. It combines the results of getPlatformName() with the os.arch system property, and finds the most precisely matching entry in the bootloaders.txt. On my system it looks at, for example (in order of preference):

mphidflash.command_linux_amd64 mphidflash.command_linux mphidflash.command

On the Pi it looks for:

mphidflash.command_linux_arm mphidflash.command_linux mphidflash.command

All I need now is to do the build.xml to support it ;)

ricklon commented 11 years ago

These commands will download the compiler, and tools for RaspberryPI. They also check if the file has changed and will not download until changed.

I'm hoping we can do on the fly downloading for the rest compilers, and avrdude files if it works for RaspberryPi.

--Rick

On Mon, Jun 17, 2013 at 7:29 AM, majenkotech notifications@github.comwrote:

Ok, I have tweaked my local copy to make the programming executable completely generic. It combines the results of getPlatformName() with the os.arch system property, and finds the most precisely matching entry in the bootloaders.txt. On my system it looks at, for example (in order of preference):

mphidflash.command_linux_amd64 mphidflash.command_linux mphidflash.command

On the Pi it looks for:

mphidflash.command_linux_arm mphidflash.command_linux mphidflash.command

All I need now is to do the build.xml to support it ;)

— Reply to this email directly or view it on GitHubhttps://github.com/chipKIT32/chipKIT32-MAX/issues/313#issuecomment-19539336 .

Co-founder Fair Use Building and Research (FUBAR) Labs http://fubarlabs.org

majenkotech commented 11 years ago

Cheers, that's spot on what I was looking for :)

majenkotech commented 11 years ago

Gah... problem...

That compiler tar file has symbolic links in it. The ant "untar" operation can't handle symlinks (stupid thing that it is), so doesn't generate some of the important binary files properly.

I guess I can go through and manually symlink them afterwards, but that's not nice if the structure changes in a future version.

Any chance the file can be regenerated using "tar -h" to dereference the symlinks?

ricklon commented 11 years ago

I'll check ASAP. We should have those packaged the same way as the other compilers. Is the compier OK, but the tools file isn't quite right?

-_Rick

On Mon, Jun 17, 2013 at 11:06 AM, majenkotech notifications@github.comwrote:

Gah... problem...

That compiler tar file has symbolic links in it. The ant "untar" operation can't handle symlinks (stupid thing that it is), so doesn't generate some of the important binary files properly.

I guess I can go through and manually symlink them afterwards, but that's not nice if the structure changes in a future version.

Any chance the file can be regenerated using "tar -h" to dereference the symlinks?

— Reply to this email directly or view it on GitHubhttps://github.com/chipKIT32/chipKIT32-MAX/issues/313#issuecomment-19551152 .

Co-founder Fair Use Building and Research (FUBAR) Labs http://fubarlabs.org

majenkotech commented 11 years ago

The compiler.tar is the one at fault. Files such as pic32-tools/bin/ar are linked to pic32-tools/pic32mx/bin/ar etc, so when it comes to make core.a it fails as the binaries are just 0 length plain files.

The other compilers are done as zip files, and zip has no concept of the symbolic link, so they end up as regular files.

ricklon commented 11 years ago

Jason is going to see about rebuilding this file tonight.

-Rick

On Mon, Jun 17, 2013 at 11:20 AM, majenkotech notifications@github.comwrote:

The compiler.tar is the one at fault. Files such as pic32-tools/bin/ar are linked to pic32-tools/pic32mx/bin/ar etc, so when it comes to make core.a it fails as the binaries are just 0 length plain files.

The other compilers are done as zip files, and zip has no concept of the symbolic link, so they end up as regular files.

— Reply to this email directly or view it on GitHubhttps://github.com/chipKIT32/chipKIT32-MAX/issues/313#issuecomment-19552091 .

Co-founder Fair Use Building and Research (FUBAR) Labs http://fubarlabs.org

majenkotech commented 11 years ago

Cool. Distributed as a zip file would be best. If you really want to use tar make sure you also compress it too, with gzip or bzip2 for example, otherwise the file is several sizes too large.

For now I will see about converting it to a zip locally and using that.

majenkotech commented 11 years ago

Works so much better as a zip... Compiles, runs, and now compiles BareMinimum on the pi. Next, packaging.

majenkotech commented 11 years ago

Ok, I think this is done and dusted now, apart from the downloading of the compiler.zip which is commented out at the moment. Not that it's very fast on a Pi though of course... Compiling and uploading Blink is like loading Arkanoid II on the Spectrum, just without the pretty noises and colourful stripes.

I have it arranged so that you can do all the build/dist/deb etc on a Linux PC (ant raspberrypi-build, etc) if you find the Pi just too painfully slow to build on.

ricklon commented 11 years ago

That's great. I'm wondering if the Beagle Bone black would be much faster.

--Rick

On Tue, Jun 18, 2013 at 10:01 AM, majenkotech notifications@github.comwrote:

Ok, I think this is done and dusted now, apart from the downloading of the compiler.zip which is commented out at the moment. Not that it's very fast on a Pi though of course... Compiling and uploading Blink is like loading Arkanoid II on the Spectrum, just without the pretty noises and colourful stripes.

I have it arranged so that you can do all the build/dist/deb etc on a Linux PC (ant raspberrypi-build, etc) if you find the Pi just too painfully slow to build on.

— Reply to this email directly or view it on GitHubhttps://github.com/chipKIT32/chipKIT32-MAX/issues/313#issuecomment-19612887 .

Co-founder Fair Use Building and Research (FUBAR) Labs http://fubarlabs.org

majenkotech commented 11 years ago

I think pretty much everything is faster than the Pi.

Buy me a beagle bone and I'll tell you ;)

ricklon commented 11 years ago

Here's the link to the RaspberryPI compiler: http://chipkit.s3.amazonaws.com/compilers/pic32-tools-chipKIT-cxx-master-arm-linux-image.zip

--Rick

On Tue, Jun 18, 2013 at 11:39 AM, Matt Jenkins notifications@github.comwrote:

I think pretty much everything is faster than the Pi.

Buy me a beagle bone and I'll tell you ;)

— Reply to this email directly or view it on GitHubhttps://github.com/chipKIT32/chipKIT32-MAX/issues/313#issuecomment-19619773 .

Co-founder Fair Use Building and Research (FUBAR) Labs http://fubarlabs.org

ricklon commented 11 years ago

Just checking how your changes are going.

majenkotech commented 11 years ago

The actual work is done, I was just waiting on the download. I just have to get round to checking out that branch, setting the URL, and testing it.

ricklon commented 10 years ago

This is added and works well. Thank You.