Hi, JMGross Thanks for replying.
While bit fields are generally inefficient and as I recall not even guaranteed to be packed in any particular order or on specific boundaries across compilers, my understanding is that in the context of the MSP430 they were advisory to the compiler. The MSP430 can implement a bit set or clear (using bis and bic instructions) in a single uninterruptable instruction. It was understood that the defined bit-field nomenclature promised the use of this single instruction access where allowed. Thus the efficiency is not the concern in this particular case but rather that a fraction of a port could be set or cleared without concern for unrelated interrupt processing. Since an embedded system may often use of only a fraction of the general I/O to implement a logical device it allows the device to be controlled efficiently with a driver without concern for other drivers using the same port. Since the PxOUT |= x is not guaranteed in this instance to be compiled into an atomic unit it cannot be relied upon although it may in fact result in a bis instruction in this case. The port must now be regarded as a resource which must be obtained for exclusive use for each routine accessing unless it is known that no routine accesses the port under interrupt control. One can argue of course that it is a non-standard nomenclature which is true but then to my mind it was a built in solution which I must now add to achieve the same end. -- Paul > Date: Thu, 19 Jul 2012 15:54:11 +0200 > From: "JMGross" <msp...@grossibaer.de> > Subject: Re: [Mspgcc-users] port1.out.pin1 nomenclature > > > Hi Paul, > > one of the reasons why bitfields have been abandoned is that bitfields are > quite ineffective regarding hardware registers. > If you have a register that contains various configuration bits, > accessing the individual bits through a bitfield results in > one separate RMSW (read-mask-set-write) operation for each and every > access, which is by magnitudes larger and faster than a single combined > access, which usually is one single instruction. > Since registers are declared volatile, the compiler cannot combine > bitfield accesses into one operation. Each assignment must be one access > exactly as written. > > Also, in some situations, more than one bit/multibit setting needs to be set > simultaneously. which is impossible if you use bitfields. > Not to mention the additional confusion with the predefined symbols: > do they relate to the bitfield (0..3) or the register > (maybe 0x00..0x60 with 0x60 as mask) > > So removing the bitfields was (not only) an educational step, > forcing people to program efficiently and not conveniently > on a microcontroller. :) > > JMGross > > ----- Urspr?ngliche Nachricht ----- > Von: Paul Voith > Gesendet am: 16 Jul 2012 08:28:07 > > Hi all, > > I am trying to port code from an earlier release of msp430-gcc and > having trouble. > > Specifically now that <io.h> is depreciated I don't know the expected > mechanism to support the "port1.out.pin0" nomenclature for referencing > bit I/O. > > In the past there was an installation kit for the tool chain on windows. > I see now that there is a built zip file for windows (Thanks Matthias!). > Any info available on how to install this? Perhaps just unzip into a > searchable directory is all? > > The have referred to the manual but it seems out of date for these aspects. > > Thanks > -- Paul > > > > > ------------------------------ > > Message: 2 > Date: Sat, 21 Jul 2012 07:45:02 +0200 > From: qbe...@gmx.de > Subject: [Mspgcc-users] Updates: slac460c and msp430_add_alpha_0.6.0 > To: mspgcc-users@lists.sourceforge.net > Message-ID: <20120721054502.130...@gmx.net> > Content-Type: text/plain; charset="utf-8" > > Hi all, > > the TI v3 driver has been recently updated to version 'C'. In the > new version the size_t bug is fixed, but there are missing headers > (string.h) so a patch (slac460c.patch) is needed again. > > The v3 driver update forces an update of the msp430_add tool chain > because of some internal changes (HAL, breakpoint), so there is > a new version 0.6.0 > > Note: the msp430_add tool chain uses the C++-interface > (DLL430_v3/include/DLL430) instead of the C-wrapper > (DLL430_v3/include). The C++ interface was was considered to be > as stable as the C wrapper, but there are changes. > > Due to the interface changes and other points, the current > version 0.6.0 does only support 1 breakpoint and there are > no FRAM targets in the database. Version 0.6.1 should fix this. > > The link to the updates: > https://sourceforge.net/projects/msp4linux/files/ > > Regards Hubert > > > > > > ------------------------------ > > Message: 3 > Date: Sun, 22 Jul 2012 15:46:15 +0200 > From: Kuba <kubaraczkow...@gmail.com> > Subject: [Mspgcc-users] View settings of peripherals in debug > To: mspgcc-users@lists.sourceforge.net > Message-ID: > <CAFFUSEOvDvsLYBeF4P3u4xTdw3oSbnVgoDXz-LYK-tm0sFvw=a...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > > A bit of a noob question perhaps concerning inspecting the settings of > peripherals during debugging session. > > Let me explain: in Code Composer Studio when debugging is launched, you > get a window with a tree of all settings of the chip (like for example > P1OUT or BCSCTL1, etc.). This is quite handy to check in the middle of > something whether the settings are okay... > > Is there something similar in the tool chain and environment of mspgcc? And > by similar I also mean easy to use :-) I guess dumping the memory and > mapping to the datasheet is doable, but perhaps there is already a tool > that I have missed... > > Thank you for your help! > Kuba > > ------------------------------ > > Message: 4 > Date: Sun, 22 Jul 2012 09:44:44 -0500 > From: Peter Bigot <big...@acm.org> > Subject: Re: [Mspgcc-users] View settings of peripherals in debug > To: Kuba <kubaraczkow...@gmail.com> > Cc: mspgcc-users@lists.sourceforge.net > Message-ID: > <capoj94pegaxujklxnf8ey_pr9lbzd3wbb74ct5o+lxon4j+...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > mspgcc as a toolchain does not provide an integrated development > environment, nor any functionality like you describe. To examine the > contents of a peripheral register within msp430-gdb you have to > reference the name with two underscores prepended, e.g: > > (gdb) x __P1DIR > > The sort of thing you describe is probably only going to be provided > by an IDE. I believe there are solutions that integrate the toolchain > into Eclipse (reference google), one of which is described on the wiki > at > http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Setting_up_an_IDE. > However, those instructions are from a couple years ago, and are not > currently linked to from the main page (where the IDE page is > undefined), so I don't know if they're still relevant. > > If somebody would like to review the Eclipse instructions and, if they > are still accurate, update the main page to reference them, I'd > appreciate it. If you need wiki editing rights, submit a support > request as described on the wiki main page. Then follow-up if it > turns out that the resulting environment does provide a device tree > view. > > Anybody wishing to write such a tool can find helpful information > about what peripherals are available on what chips within the analysis > subdirectory of the msp430mcu package. > > Peter > > On Sun, Jul 22, 2012 at 8:46 AM, Kuba <kubaraczkow...@gmail.com> wrote: >> Hi, >> >> A bit of a noob question perhaps concerning inspecting the settings of >> peripherals during debugging session. >> >> Let me explain: in Code Composer Studio when debugging is launched, you >> get a window with a tree of all settings of the chip (like for example >> P1OUT or BCSCTL1, etc.). This is quite handy to check in the middle of >> something whether the settings are okay... >> >> Is there something similar in the tool chain and environment of mspgcc? And >> by similar I also mean easy to use :-) I guess dumping the memory and >> mapping to the datasheet is doable, but perhaps there is already a tool >> that I have missed... >> >> Thank you for your help! >> Kuba >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Mspgcc-users mailing list >> Mspgcc-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mspgcc-users >> > > > ------------------------------ > > Message: 5 > Date: Sun, 22 Jul 2012 11:38:32 -0400 > From: Rick Kimball <rick.kimb...@gmail.com> > Subject: Re: [Mspgcc-users] View settings of peripherals in debug > To: Peter Bigot <big...@acm.org> > Cc: mspgcc-users@lists.sourceforge.net, Kuba > <kubaraczkow...@gmail.com> > Message-ID: > <CAAF5-vP5yqGF0Qok9V5FWna_Lb=dyyui88fqanqbjjvrymv...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > The following post provides information about an eclipse plugin that > works with the latest version of eclipse: > > http://www.43oh.com/forum/viewtopic.php?f=5&t=1874#p13103 > > The plugin handles much of this tedious setup for gcc and mspdebug > inside of eclipse. > > I've only tried it on linux and it works great from me. Although > sometimes I want more control over msp430-gcc arguments than it > allows. In that case, I just use a cross platform target and do all > the setup by hand. > > -rick > >> Anybody wishing to write such a tool can find helpful information >> about what peripherals are available on what chips within the analysis >> subdirectory of the msp430mcu package. >> >> Peter > > > ------------------------------ > > Message: 6 > Date: Sun, 22 Jul 2012 11:42:20 -0400 > From: Przemek Klosowski <przemek.klosow...@gmail.com> > Subject: Re: [Mspgcc-users] View settings of peripherals in debug > To: mspgcc-users@lists.sourceforge.net > Message-ID: > <CAC=1gghypanrajcdnordffl4rsux45uymvcgst+ajyfbx0c...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Sun, Jul 22, 2012 at 10:44 AM, Peter Bigot <big...@acm.org> wrote: >> mspgcc as a toolchain does not provide an integrated development >> environment, nor any functionality like you describe. To examine the >> contents of a peripheral register within msp430-gdb you have to >> reference the name with two underscores prepended, e.g: >> >> (gdb) x __P1DIR >> >> The sort of thing you describe is probably only going to be provided >> by an IDE. > Having said that, gdb has macros, so you can define a shortcut that > displays the variables you're interested in: > > define show_peripherals > x __P1DIR > ..... > end > > > > ------------------------------ > > Message: 7 > Date: Sun, 22 Jul 2012 23:03:49 +0200 > From: Kuba <kubaraczkow...@gmail.com> > Subject: Re: [Mspgcc-users] View settings of peripherals in debug > To: Peter Bigot <big...@acm.org> > Cc: mspgcc-users@lists.sourceforge.net > Message-ID: > <caffusemezlfxctio4vdx6fkzwjgoarwqvtba_xhw2llsadf...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Peter, > > Thank you for your answer. I do understand that my question only touches > mspgcc toolchain, however I decided to give it a try since people reading > this list have also quite some "toolset" knowledge. > > Thank you for the __P1DIR hint! It is already close to what I would like, > but is there still a command to show all available symbols? (these are > symbols, right?) > > Concerning eclipse... Would a tool I described be available in the eclipse > (without CCS) ? It sounds too good to be true, but perhaps? Not a big fan > of eclipse for the moment, I rather have the total vim+make control till I > properly learn what to do :) > > Regards, > Kuba > > On Sun, Jul 22, 2012 at 4:44 PM, Peter Bigot <big...@acm.org> wrote: > >> mspgcc as a toolchain does not provide an integrated development >> environment, nor any functionality like you describe. To examine the >> contents of a peripheral register within msp430-gdb you have to >> reference the name with two underscores prepended, e.g: >> >> (gdb) x __P1DIR >> >> The sort of thing you describe is probably only going to be provided >> by an IDE. I believe there are solutions that integrate the toolchain >> into Eclipse (reference google), one of which is described on the wiki >> at >> http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Setting_up_an_IDE >> . >> However, those instructions are from a couple years ago, and are not >> currently linked to from the main page (where the IDE page is >> undefined), so I don't know if they're still relevant. >> >> If somebody would like to review the Eclipse instructions and, if they >> are still accurate, update the main page to reference them, I'd >> appreciate it. If you need wiki editing rights, submit a support >> request as described on the wiki main page. Then follow-up if it >> turns out that the resulting environment does provide a device tree >> view. >> >> Anybody wishing to write such a tool can find helpful information >> about what peripherals are available on what chips within the analysis >> subdirectory of the msp430mcu package. >> >> Peter >> >> On Sun, Jul 22, 2012 at 8:46 AM, Kuba <kubaraczkow...@gmail.com> wrote: >>> Hi, >>> >>> A bit of a noob question perhaps concerning inspecting the settings of >>> peripherals during debugging session. >>> >>> Let me explain: in Code Composer Studio when debugging is launched, you >>> get a window with a tree of all settings of the chip (like for example >>> P1OUT or BCSCTL1, etc.). This is quite handy to check in the middle of >>> something whether the settings are okay... >>> >>> Is there something similar in the tool chain and environment of mspgcc? >> And >>> by similar I also mean easy to use :-) I guess dumping the memory and >>> mapping to the datasheet is doable, but perhaps there is already a tool >>> that I have missed... >>> >>> Thank you for your help! >>> Kuba >>> >>> >> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> Mspgcc-users mailing list >>> Mspgcc-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/mspgcc-users >>> > ------------------------------ > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > ------------------------------ > > _______________________________________________ > Mspgcc-users mailing list > Mspgcc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > > End of Mspgcc-users Digest, Vol 74, Issue 7 > ******************************************* ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
