From: Cody K. <co...@ho...> - 2013-07-02 22:10:12
|
Hello everyone, I have reached a point where I am needing to use upper memory in a project. I am currently using version 20110716, and I would like to migrate the project to the new Red Hat version if it will be arriving soon. If not, I will need to migrate to the newest LTS release. Is there an estimated release date? Thank you for your help, Cody Kemp |
From: Peter B. <bi...@ac...> - 2013-07-02 22:23:37
|
I don't follow the status of Red Hat's port, but if you need 20-bit support you need 20120911 which is not an LTS release. Peter On Tue, Jul 2, 2013 at 5:06 PM, Cody Kemp <co...@ho...> wrote: > Hello everyone, > > I have reached a point where I am needing to use upper memory in a project. > I am currently using version 20110716, and I would like to migrate the > project to the new Red Hat version if it will be arriving soon. If not, I > will need to migrate to the newest LTS release. Is there an estimated > release date? > > Thank you for your help, > > Cody Kemp > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Mspgcc-users mailing list > Msp...@li... > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > |
From: Brendan C. <bl...@re...> - 2013-07-02 22:29:53
|
On 07/02/2013 03:06 PM, Cody Kemp wrote: > Hello everyone, > > I have reached a point where I am needing to use upper memory in a project. > I am currently using version 20110716, and I would like to migrate the > project to the new Red Hat version if it will be arriving soon. If not, I > will need to migrate to the newest LTS release. Is there an estimated > release date? Essentially everything is upstream at this point except for gcc. If you wanted to build up a current version of binutils, gdb, and gcc with the current patch set (http://patchwork.ozlabs.org/patch/252490/), you'd be good to go. -- Brendan Conoboy / Red Hat, Inc. / bl...@re... |
From: Sergei S. <se...@ho...> - 2013-07-02 22:55:11
|
Brendan Conoboy <blc <at> redhat.com> writes: > Essentially everything is upstream at this point except for gcc. If you > wanted to build up a current version of binutils, gdb, and gcc with the > current patch set (http://patchwork.ozlabs.org/patch/252490/), you'd be > good to go. Will it build cleanly under Cygwin or Mingw? Are there any instructions on doing so? Regards, Sergei |
From: Howard0Su <how...@gm...> - 2013-07-05 01:36:42
|
I grab the patch and latest binutils. I sucessfully build the gcc and binutils. However I am not sure how to handle msp430mcu and msp430-libc. Do I still need them? If so, where I can find the right version? Thanks, Howard -- View this message in context: http://msp430-gcc-users.1086195.n5.nabble.com/mspgcc-Red-Hat-release-tp6761p6770.html Sent from the MSP430 gcc - Users mailing list archive at Nabble.com. |
From: Jhon J. <sof...@gm...> - 2013-07-10 01:17:54
|
Hello, I want to install the msp430-gcc on ARM processor. I have installed msp430-gcc 4.63 but the problem is that I am using it with contiki and 4.63 version cannot detect the serial port to program the motes and it is recommended to use msp430-gcc 4.7.0 I tried installing it on ARM but did not suceeded can anyone help me or share some link for it?? Regard's On Fri, Jul 5, 2013 at 6:36 AM, Howard0Su <how...@gm...> wrote: > I grab the patch and latest binutils. I sucessfully build the gcc and > binutils. However I am not sure how to handle msp430mcu and msp430-libc. Do > I still need them? If so, where I can find the right version? > > Thanks, > > Howard > > > > -- > View this message in context: > http://msp430-gcc-users.1086195.n5.nabble.com/mspgcc-Red-Hat-release-tp6761p6770.html > Sent from the MSP430 gcc - Users mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Mspgcc-users mailing list > Msp...@li... > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > |
From: Eric D. <ci...@gm...> - 2013-07-05 01:54:56
|
If you are building 4.7 which I beleive you are. You should use the msp430mcu and msp430-libc that came with the 4.7 release that Peter talked about. yes you need them... On Thu, Jul 4, 2013 at 6:36 PM, Howard0Su <how...@gm...> wrote: > I grab the patch and latest binutils. I sucessfully build the gcc and > binutils. However I am not sure how to handle msp430mcu and msp430-libc. Do > I still need them? If so, where I can find the right version? > > Thanks, > > Howard > > > > -- > View this message in context: > http://msp430-gcc-users.1086195.n5.nabble.com/mspgcc-Red-Hat-release-tp6761p6770.html > Sent from the MSP430 gcc - Users mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Mspgcc-users mailing list > Msp...@li... > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > -- Eric B. Decker Senior (over 50 :-) Researcher |
From: Peter B. <bi...@ac...> - 2013-07-05 02:10:32
|
I have no information about Red Hat's toolchain other than what's been announced here, but: Red Hat's MSP430 toolchain is entirely unrelated to mspgcc. I am unaware of any information having been provided related to support for libc or specific MCUs in this new work. While msp430mcu and msp430-libc might work with some fiddling, it's not clear they're needed, I very much doubt they're the intended solution, and they certainly don't incorporate any changes to accommodate Red Hat's implementation. Peter On Thu, Jul 4, 2013 at 8:54 PM, Eric Decker <ci...@gm...> wrote: > If you are building 4.7 which I beleive you are. You should use the > msp430mcu and msp430-libc that came with the 4.7 release that Peter talked > about. > > yes you need them... > > > > On Thu, Jul 4, 2013 at 6:36 PM, Howard0Su <how...@gm...> wrote: > > > I grab the patch and latest binutils. I sucessfully build the gcc and > > binutils. However I am not sure how to handle msp430mcu and msp430-libc. > Do > > I still need them? If so, where I can find the right version? > > > > Thanks, > > > > Howard > > > > > > > > -- > > View this message in context: > > > http://msp430-gcc-users.1086195.n5.nabble.com/mspgcc-Red-Hat-release-tp6761p6770.html > > Sent from the MSP430 gcc - Users mailing list archive at Nabble.com. > > > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > _______________________________________________ > > Mspgcc-users mailing list > > Msp...@li... > > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > > > > > -- > Eric B. Decker > Senior (over 50 :-) Researcher > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Mspgcc-users mailing list > Msp...@li... > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > |
From: Przemek K. <prz...@gm...> - 2013-07-05 18:25:06
|
Kudos to Peter Bigot for maintaining MSP430 toolchain for so long and for getting it to the level of support that it has today. Kudos also to RedHat people like Brendan Conoboy for committing to ongoing support. Having said that, could I suggest some public or private coordination between the two teams? Peter has extensive knowledge of this toolchain and I'm sure that anyone working in this area would benefit from his advice---but I have a sense that he is not involved with whatever is happening at RedHat. In the interest of the MSP430 community, could you guys brief each other on your plans and such? I have a feeling that this is something doable via a fairly short phone conversation. I do know that Brendan super busy because of his involvement with the Fedora/Redhat ARM project, which is booming now, what with it becoming an official Fedora architecture and with the buzz and activity around Beaglebone Black---nevertheless, I hope something could be done re. MSP430 in the short term. |
From: Brendan C. <bl...@re...> - 2013-07-08 01:13:04
|
On 07/04/2013 07:10 PM, Peter Bigot wrote: > I have no information about Red Hat's toolchain other than what's been > announced here, but: > > Red Hat's MSP430 toolchain is entirely unrelated to mspgcc. I am unaware > of any information having been provided related to support for libc or > specific MCUs in this new work. While msp430mcu and msp430-libc might work > with some fiddling, it's not clear they're needed, I very much doubt > they're the intended solution, and they certainly don't incorporate any > changes to accommodate Red Hat's implementation. There is now msp430 support in newlib: http://www.cygwin.com/ml/newlib/2013/msg00362.html Since we did a clean re-implementation of the MSP port we can't comment on the pre-existing mspgcc library solutions: We really don't know. Our plan is to support and enhance standard upstream infrastructure. For libc this means newlib. -- Brendan Conoboy / Red Hat, Inc. / bl...@re... |
From: Peter J. <roc...@gm...> - 2013-07-08 02:40:12
|
On Sun, Jul 7, 2013 at 9:12 PM, Brendan Conoboy <bl...@re...> wrote: > Since we did a clean re-implementation of the MSP port we can't comment > on the pre-existing mspgcc library solutions: We really don't know. Our > plan is to support and enhance standard upstream infrastructure. For > libc this means newlib. What is your plan (if any) for chip-specific header files and linker files? -p. |
From: Brendan C. <bl...@re...> - 2013-07-08 01:28:21
|
On 07/05/2013 11:24 AM, Przemek Klosowski wrote: > Kudos to Peter Bigot for maintaining MSP430 toolchain for so long and > for getting it to the level of support that it has today. Kudos also > to RedHat people like Brendan Conoboy for committing to ongoing > support. > > Having said that, could I suggest some public or private coordination > between the two teams? Peter has extensive knowledge of this > toolchain and I'm sure that anyone working in this area would benefit > from his advice---but I have a sense that he is not involved with > whatever is happening at RedHat. In the interest of the MSP430 > community, could you guys brief each other on your plans and such? I > have a feeling that this is something doable via a fairly short phone > conversation. Peter and I had a nice chat early on, but out of necessity we did the port without his considerable expertise. I think gcc is just about ready to be checked in, at which point the upstream sources will be complete and available for everybody to use without special patching. Once that completes, I will send a note, but also: I would like to encourage everybody who wants to contribute to the new tools to submit their patches upstream: This makes sure every future release is the best release ever. > I do know that Brendan super busy because of his involvement with the > Fedora/Redhat ARM project, which is booming now, what with it becoming > an official Fedora architecture and with the buzz and activity around > Beaglebone Black---nevertheless, I hope something could be done re. > MSP430 in the short term. Fedora-ARM is a demanding mistress :-) Fortunately the engineers doing the real work on the MSP 430 GNU tools can give it much more attention: Kevin Buettner, DJ Delorie, and Nick Clifton. Hopefully TI will have an update of their own in the near future. Cheers, -- Brendan Conoboy / Red Hat, Inc. / bl...@re... |
From: Peter B. <bi...@ac...> - 2013-07-08 03:18:32
|
As Brendan notes I'm excluded from TI and Red Hat's collaboration so have been unable to ease this transition in the ways that I had planned at the time it was announced. Best to just leave it at that. Peter On Sun, Jul 7, 2013 at 8:28 PM, Brendan Conoboy <bl...@re...> wrote: > On 07/05/2013 11:24 AM, Przemek Klosowski wrote: > > Kudos to Peter Bigot for maintaining MSP430 toolchain for so long and > > for getting it to the level of support that it has today. Kudos also > > to RedHat people like Brendan Conoboy for committing to ongoing > > support. > > > > Having said that, could I suggest some public or private coordination > > between the two teams? Peter has extensive knowledge of this > > toolchain and I'm sure that anyone working in this area would benefit > > from his advice---but I have a sense that he is not involved with > > whatever is happening at RedHat. In the interest of the MSP430 > > community, could you guys brief each other on your plans and such? I > > have a feeling that this is something doable via a fairly short phone > > conversation. > > Peter and I had a nice chat early on, but out of necessity we did the > port without his considerable expertise. I think gcc is just about > ready to be checked in, at which point the upstream sources will be > complete and available for everybody to use without special patching. > Once that completes, I will send a note, but also: I would like to > encourage everybody who wants to contribute to the new tools to submit > their patches upstream: This makes sure every future release is the best > release ever. > |
From: Eric D. <ci...@gm...> - 2013-07-08 02:22:08
|
Hi Brendan, will this newlib support for msp430 have support for the MSP430X cpus? I assume. On Sun, Jul 7, 2013 at 6:28 PM, Brendan Conoboy <bl...@re...> wrote: > On 07/05/2013 11:24 AM, Przemek Klosowski wrote: > > Kudos to Peter Bigot for maintaining MSP430 toolchain for so long and > > for getting it to the level of support that it has today. Kudos also > > to RedHat people like Brendan Conoboy for committing to ongoing > > support. > > > > Having said that, could I suggest some public or private coordination > > between the two teams? Peter has extensive knowledge of this > > toolchain and I'm sure that anyone working in this area would benefit > > from his advice---but I have a sense that he is not involved with > > whatever is happening at RedHat. In the interest of the MSP430 > > community, could you guys brief each other on your plans and such? I > > have a feeling that this is something doable via a fairly short phone > > conversation. > > Peter and I had a nice chat early on, but out of necessity we did the > port without his considerable expertise. I think gcc is just about > ready to be checked in, at which point the upstream sources will be > complete and available for everybody to use without special patching. > Once that completes, I will send a note, but also: I would like to > encourage everybody who wants to contribute to the new tools to submit > their patches upstream: This makes sure every future release is the best > release ever. > > > I do know that Brendan super busy because of his involvement with the > > Fedora/Redhat ARM project, which is booming now, what with it becoming > > an official Fedora architecture and with the buzz and activity around > > Beaglebone Black---nevertheless, I hope something could be done re. > > MSP430 in the short term. > > Fedora-ARM is a demanding mistress :-) Fortunately the engineers doing > the real work on the MSP 430 GNU tools can give it much more attention: > Kevin Buettner, DJ Delorie, and Nick Clifton. Hopefully TI will have an > update of their own in the near future. Cheers, > > -- > Brendan Conoboy / Red Hat, Inc. / bl...@re... > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Mspgcc-users mailing list > Msp...@li... > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > -- Eric B. Decker Senior (over 50 :-) Researcher |
From: Brendan C. <bl...@re...> - 2013-07-08 04:26:55
|
On 07/07/2013 07:21 PM, Eric Decker wrote: > > Hi Brendan, > > will this newlib support for msp430 have support for the MSP430X cpus? There is support for msp430, msp430x and msp430x/-mlarge -- Brendan Conoboy / Red Hat, Inc. / bl...@re... |
From: Mark R. <mar...@gm...> - 2013-07-08 02:49:32
|
On Sun, Jul 7, 2013 at 7:12 PM, Brendan Conoboy <bl...@re...> wrote: > > There is now msp430 support in newlib: > > http://www.cygwin.com/ml/newlib/2013/msg00362.html > > Since we did a clean re-implementation of the MSP port we can't comment > on the pre-existing mspgcc library solutions: We really don't know. Our > plan is to support and enhance standard upstream infrastructure. For > libc this means newlib. > > How does newlib's footprint compare with msp430-libc? Last time I used newlib (on ARM) it seemed to want to do dynamic memory allocation for a simple printf() (!). I can't imagine using it on a device with 256 bytes RAM... or was I just using newlib wrong? Regards, Mark markrages@gmail |
From: Eric D. <ci...@gm...> - 2013-07-08 02:55:36
|
There definitely needs to be a way to not have malloc get used automatically. Malloc will cause all kinds of problems in the tinyos community. We discourage the use of malloc and that kind of dynamic memory allocation to minimize wild pointers in very small embedded systems. On Sun, Jul 7, 2013 at 7:49 PM, Mark Rages <mar...@gm...> wrote: > On Sun, Jul 7, 2013 at 7:12 PM, Brendan Conoboy <bl...@re...> wrote: > > > > > There is now msp430 support in newlib: > > > > http://www.cygwin.com/ml/newlib/2013/msg00362.html > > > > Since we did a clean re-implementation of the MSP port we can't comment > > on the pre-existing mspgcc library solutions: We really don't know. Our > > plan is to support and enhance standard upstream infrastructure. For > > libc this means newlib. > > > > > How does newlib's footprint compare with msp430-libc? > > Last time I used newlib (on ARM) it seemed to want to do dynamic memory > allocation for a simple printf() (!). I can't imagine using it on a device > with 256 bytes RAM... or was I just using newlib wrong? > > Regards, > Mark > markrages@gmail > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Mspgcc-users mailing list > Msp...@li... > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > -- Eric B. Decker Senior (over 50 :-) Researcher |
From: David B. <da...@we...> - 2013-07-08 07:01:38
|
Malloc is discouraged in almost all embedded programming - it should never be used by other library functions unless it is absolutely obvious and necessary (such as for an implementation of C++ "new"). On 08/07/13 04:55, Eric Decker wrote: > There definitely needs to be a way to not have malloc get used > automatically. > > Malloc will cause all kinds of problems in the tinyos community. We > discourage the use of malloc and that kind of dynamic memory allocation to > minimize wild pointers in very small embedded systems. > > > On Sun, Jul 7, 2013 at 7:49 PM, Mark Rages <mar...@gm...> wrote: > >> On Sun, Jul 7, 2013 at 7:12 PM, Brendan Conoboy <bl...@re...> wrote: >> >>> >>> There is now msp430 support in newlib: >>> >>> http://www.cygwin.com/ml/newlib/2013/msg00362.html >>> >>> Since we did a clean re-implementation of the MSP port we can't comment >>> on the pre-existing mspgcc library solutions: We really don't know. Our >>> plan is to support and enhance standard upstream infrastructure. For >>> libc this means newlib. >>> >>> >> How does newlib's footprint compare with msp430-libc? >> >> Last time I used newlib (on ARM) it seemed to want to do dynamic memory >> allocation for a simple printf() (!). I can't imagine using it on a device >> with 256 bytes RAM... or was I just using newlib wrong? >> >> Regards, >> Mark >> markrages@gmail >> |
From: David B. <da...@we...> - 2013-07-08 10:39:53
|
On 08/07/13 03:28, Brendan Conoboy wrote: > On 07/05/2013 11:24 AM, Przemek Klosowski wrote: >> Kudos to Peter Bigot for maintaining MSP430 toolchain for so long and >> for getting it to the level of support that it has today. Kudos also >> to RedHat people like Brendan Conoboy for committing to ongoing >> support. >> >> Having said that, could I suggest some public or private coordination >> between the two teams? Peter has extensive knowledge of this >> toolchain and I'm sure that anyone working in this area would benefit >> from his advice---but I have a sense that he is not involved with >> whatever is happening at RedHat. In the interest of the MSP430 >> community, could you guys brief each other on your plans and such? I >> have a feeling that this is something doable via a fairly short phone >> conversation. > > Peter and I had a nice chat early on, but out of necessity we did the > port without his considerable expertise. I think gcc is just about > ready to be checked in, at which point the upstream sources will be > complete and available for everybody to use without special patching. > Once that completes, I will send a note, but also: I would like to > encourage everybody who wants to contribute to the new tools to submit > their patches upstream: This makes sure every future release is the best > release ever. > >> I do know that Brendan super busy because of his involvement with the >> Fedora/Redhat ARM project, which is booming now, what with it becoming >> an official Fedora architecture and with the buzz and activity around >> Beaglebone Black---nevertheless, I hope something could be done re. >> MSP430 in the short term. > > Fedora-ARM is a demanding mistress :-) Fortunately the engineers doing > the real work on the MSP 430 GNU tools can give it much more attention: > Kevin Buettner, DJ Delorie, and Nick Clifton. Hopefully TI will have an > update of their own in the near future. Cheers, > Do you know how this is going to work? Will TI release packages with binary builds of the toolchain (including libraries) for Windows and Linux? Will they provide a collection of patches against the main gcc and library releases? Will they integrate gcc into Code Composer Studio? As a cross-platform user, I would like to be able to get ready-packaged bundles for Linux (32-bit and 64-bit, of preference) and Windows that contain the same compiler and library snapshot, so that I can say "this project is built using the 20130708 release" and get the same build on all platforms. Such snapshots should include pre-built binaries (especially for Windows), source (including basic instructions such as lists of patches), libraries and headers. For many users, integration into Code Composer would be a big benefit too. What I would hate to see is a Microchip-style gcc, where you can pay them lots of money to use the free compiler developed by other people, or you are on your own regarding building the compiler, finding libraries, writing header files, etc. I don't expect that to happen here - it doesn't sound like TI and it certainly doesn't sound like Redhat - but legally it is possible. Anyway, I am looking forward to this new msp430 gcc port. Peter (and others before him) have done a fantastic job, but he has earned a rest and having TI and Redhat behind the port opens up many possibilities. |
From: Mitnacht, T. <t-m...@ti...> - 2013-07-08 10:59:28
|
Hi David, In a nutshell ... * TI will drive the availability of precompiled packages * TI will support header and linker command files for all supported MSP430 derivatives, same as we do for MSPGCC * TI will release a CCS version supporting GCC * TI will support GCC via the TI E2E forum Stay tuned... Thanks, Thomas Mitnacht Texas Instruments Deutschland GmbH, Haggertystr. 1, D-85356 Freising. Amtsgericht M?nchen HRB 40960. Gesch?ftsf?hrer: Dr. Wolfram Tietscher. Vorsitzender des Aufsichtsrates: Edgar Frank -----Original Message----- From: David Brown [mailto:da...@we...] Sent: Monday, July 08, 2013 12:40 PM To: Brendan Conoboy Cc: msp...@li... Subject: Re: [Mspgcc-users] mspgcc Red Hat release On 08/07/13 03:28, Brendan Conoboy wrote: > On 07/05/2013 11:24 AM, Przemek Klosowski wrote: >> Kudos to Peter Bigot for maintaining MSP430 toolchain for so long and >> for getting it to the level of support that it has today. Kudos also >> to RedHat people like Brendan Conoboy for committing to ongoing >> support. >> >> Having said that, could I suggest some public or private coordination >> between the two teams? Peter has extensive knowledge of this >> toolchain and I'm sure that anyone working in this area would benefit >> from his advice---but I have a sense that he is not involved with >> whatever is happening at RedHat. In the interest of the MSP430 >> community, could you guys brief each other on your plans and such? I >> have a feeling that this is something doable via a fairly short phone >> conversation. > > Peter and I had a nice chat early on, but out of necessity we did the > port without his considerable expertise. I think gcc is just about > ready to be checked in, at which point the upstream sources will be > complete and available for everybody to use without special patching. > Once that completes, I will send a note, but also: I would like to > encourage everybody who wants to contribute to the new tools to submit > their patches upstream: This makes sure every future release is the > best release ever. > >> I do know that Brendan super busy because of his involvement with the >> Fedora/Redhat ARM project, which is booming now, what with it >> becoming an official Fedora architecture and with the buzz and >> activity around Beaglebone Black---nevertheless, I hope something could be done re. >> MSP430 in the short term. > > Fedora-ARM is a demanding mistress :-) Fortunately the engineers > doing the real work on the MSP 430 GNU tools can give it much more attention: > Kevin Buettner, DJ Delorie, and Nick Clifton. Hopefully TI will have > an update of their own in the near future. Cheers, > Do you know how this is going to work? Will TI release packages with binary builds of the toolchain (including libraries) for Windows and Linux? Will they provide a collection of patches against the main gcc and library releases? Will they integrate gcc into Code Composer Studio? As a cross-platform user, I would like to be able to get ready-packaged bundles for Linux (32-bit and 64-bit, of preference) and Windows that contain the same compiler and library snapshot, so that I can say "this project is built using the 20130708 release" and get the same build on all platforms. Such snapshots should include pre-built binaries (especially for Windows), source (including basic instructions such as lists of patches), libraries and headers. For many users, integration into Code Composer would be a big benefit too. What I would hate to see is a Microchip-style gcc, where you can pay them lots of money to use the free compiler developed by other people, or you are on your own regarding building the compiler, finding libraries, writing header files, etc. I don't expect that to happen here - it doesn't sound like TI and it certainly doesn't sound like Redhat - but legally it is possible. Anyway, I am looking forward to this new msp430 gcc port. Peter (and others before him) have done a fantastic job, but he has earned a rest and having TI and Redhat behind the port opens up many possibilities. ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Mspgcc-users mailing list Msp...@li... https://lists.sourceforge.net/lists/listinfo/mspgcc-users |
From: Lev S. <le...@se...> - 2013-07-08 14:12:11
|
Hello, Thomas. You wrote 8 июля 2013 г., 14:59:15: MT> * TI will drive the availability of precompiled packages MT> * TI will support header and linker command files for all supported MT> MSP430 derivatives, same as we do for MSPGCC And what about CLEAN AND UNDERSTANDABLE way to build packages from sources? I'm supporting msp430-gcc for FreeBSD host and I need to understand, will it be as easy as now -- stock release binutils/gcc versions + manageable amount of patches + standard cross-toolchain build? Now ARM cross-tools for small devices (like Cortex-M) is not so straightforward, unfortunately. It needs special hacks to build them well not on Linux hosts, as they expect some Linux-specific headers, etc. -- // Black Lion AKA Lev Serebryakov <le...@se...> |
From: Dmitry <di...@sp...> - 2013-07-08 11:22:58
|
Hi All, I'm quite distant from MSPs now yet just interesting - is now gcc's ABI compatible with others (like IAR CS, etc.) ? Cheers, Dmitry. 08.07.2013 14:59, Mitnacht, Thomas пишет: > CCS version supporting GCC > * TI will support GCC via the TI E2E for |
From: Nils F. <nil...@ke...> - 2013-07-08 11:28:23
|
Am 08.07.2013 12:59, schrieb Mitnacht, Thomas: > Hi David, > In a nutshell ... > > * TI will drive the availability of precompiled packages That's great to hear! Which distributions will this include? I would very much like see the already existing Debian packages, which are based for derived versions in many other Debian based distributions like Mint, Ubuntu etc.. So working together with the Debian MSP430-gcc package maintainer(s) seems like a promising a fruitful thing. > * TI will support header and linker command files for all supported MSP430 derivatives, same as we do for MSPGCC Excellent! > * TI will release a CCS version supporting GCC Uh, also nice! Just for clearing up my ignorance - which part of CCS is covered by the commercial license? The compiler? The IDE? Or both? I was just wondering if GCC in CCS would mean that CCS could then be used "for free" in order to work with MSP-GCC. Not that I would use it ;) I more of a Makefile and simple text editor guy... just out of curiosity... > * TI will support GCC via the TI E2E forum Great! > Stay tuned... > > Thanks, > Thomas Mitnacht Cheers nils > Texas Instruments Deutschland GmbH, Haggertystr. 1, D-85356 Freising. Amtsgericht M?nchen HRB 40960. Gesch?ftsf?hrer: Dr. Wolfram Tietscher. Vorsitzender des Aufsichtsrates: Edgar Frank > > -----Original Message----- > From: David Brown [mailto:da...@we...] > Sent: Monday, July 08, 2013 12:40 PM > To: Brendan Conoboy > Cc: msp...@li... > Subject: Re: [Mspgcc-users] mspgcc Red Hat release > > On 08/07/13 03:28, Brendan Conoboy wrote: >> On 07/05/2013 11:24 AM, Przemek Klosowski wrote: >>> Kudos to Peter Bigot for maintaining MSP430 toolchain for so long and >>> for getting it to the level of support that it has today. Kudos also >>> to RedHat people like Brendan Conoboy for committing to ongoing >>> support. >>> >>> Having said that, could I suggest some public or private coordination >>> between the two teams? Peter has extensive knowledge of this >>> toolchain and I'm sure that anyone working in this area would benefit >>> from his advice---but I have a sense that he is not involved with >>> whatever is happening at RedHat. In the interest of the MSP430 >>> community, could you guys brief each other on your plans and such? I >>> have a feeling that this is something doable via a fairly short phone >>> conversation. >> >> Peter and I had a nice chat early on, but out of necessity we did the >> port without his considerable expertise. I think gcc is just about >> ready to be checked in, at which point the upstream sources will be >> complete and available for everybody to use without special patching. >> Once that completes, I will send a note, but also: I would like to >> encourage everybody who wants to contribute to the new tools to submit >> their patches upstream: This makes sure every future release is the >> best release ever. >> >>> I do know that Brendan super busy because of his involvement with the >>> Fedora/Redhat ARM project, which is booming now, what with it >>> becoming an official Fedora architecture and with the buzz and >>> activity around Beaglebone Black---nevertheless, I hope something could be done re. >>> MSP430 in the short term. >> >> Fedora-ARM is a demanding mistress :-) Fortunately the engineers >> doing the real work on the MSP 430 GNU tools can give it much more attention: >> Kevin Buettner, DJ Delorie, and Nick Clifton. Hopefully TI will have >> an update of their own in the near future. Cheers, >> > > Do you know how this is going to work? Will TI release packages with > binary builds of the toolchain (including libraries) for Windows and > Linux? Will they provide a collection of patches against the main gcc > and library releases? Will they integrate gcc into Code Composer Studio? > > As a cross-platform user, I would like to be able to get ready-packaged > bundles for Linux (32-bit and 64-bit, of preference) and Windows that > contain the same compiler and library snapshot, so that I can say "this > project is built using the 20130708 release" and get the same build on > all platforms. Such snapshots should include pre-built binaries > (especially for Windows), source (including basic instructions such as > lists of patches), libraries and headers. > > For many users, integration into Code Composer would be a big benefit too. > > What I would hate to see is a Microchip-style gcc, where you can pay > them lots of money to use the free compiler developed by other people, > or you are on your own regarding building the compiler, finding > libraries, writing header files, etc. I don't expect that to happen > here - it doesn't sound like TI and it certainly doesn't sound like > Redhat - but legally it is possible. > > Anyway, I am looking forward to this new msp430 gcc port. Peter (and > others before him) have done a fantastic job, but he has earned a rest > and having TI and Redhat behind the port opens up many possibilities. > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Mspgcc-users mailing list > Msp...@li... > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ |
From: David B. <da...@we...> - 2013-07-08 11:38:12
|
On 08/07/13 13:06, Dmitry wrote: > Hi All, > > I'm quite distant from MSPs now yet just interesting - > is now gcc's ABI compatible with others (like IAR CS, etc.) ? > > Cheers, > Dmitry. > Why is that likely to matter? Are you mixing code compiled with one compiler with code compiled with another? It matters that the headers are the same (or at least compatible), so that you can use the same code to access peripherals in the same way. |
From: Peter B. <bi...@ac...> - 2013-07-08 12:01:59
|
One reason it matters is it seems TI is moving to releasing binary-only modules such as MSPMATHLIB. Much of the RF support for MSP430 devices is similarly available only in binary form, though most of this has been from third-party vendors. mspgcc has never been able to use these tools because of ABI differences. A benefit to the Red Hat / TI collaboration is that Red Hat was given access to ABI information that was not available to mspgcc developers. Had existence of such an ABI been public knowledge compatibility might have happened years ago (certainly, I would have considered it at the point of doing MSP430X enhancements had I been aware an ABI had been defined and shared between TI/CCS and IAR). Peter On Mon, Jul 8, 2013 at 6:38 AM, David Brown <da...@we...> wrote: > On 08/07/13 13:06, Dmitry wrote: > > Hi All, > > > > I'm quite distant from MSPs now yet just interesting - > > is now gcc's ABI compatible with others (like IAR CS, etc.) ? > > > > Cheers, > > Dmitry. > > > > Why is that likely to matter? Are you mixing code compiled with one > compiler with code compiled with another? > > It matters that the headers are the same (or at least compatible), so > that you can use the same code to access peripherals in the same way. > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Mspgcc-users mailing list > Msp...@li... > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > |