On Fri, Jun 29, 2012 at 5:42 AM, JMGross <msp...@grossibaer.de> wrote: > ----- Ursprüngliche Nachricht ----- > Von: Peter Bigot > Gesendet am: 28 Jun 2012 19:48:27 > >> I personally prefer to use msp430.h, which automatically includes the >> header relevant to the chip you've told gcc you're compiling for, >> because I have at eight different platforms I use and a lot of code is >> dependent only on a peripheral, not a specific chip. It's easy enough >> to have conditional code in the program that configures pins >> appropriately for the specific chip. > > If you know what you're doing, and if it is your code and properly maintained, > this is fine. > And as I already agreed, it is convenient to jsu tuse one header file. > However, automatic selections can automatically fail and you don't know why. > Sure, it is in the very most cases a user error, but the resulting error > messages > are then as useful in tracing it down as a generic 'there was an error' > messge. > >> FWIW, the following text appears in the genericized headers (e.g., >> msp430x54x.h) as they are provided by TI. > > /******************************************************************************/ > /* Legacy Header File > */ > /* Not recommended for use in new projects. > */ > /* Please use the msp430.h file or the device specific header file > */ > /******************************************************************************/ > > Unfortunately. > I see some TI engineers moving towards the convenient solution. > However, they leave the people along with the problems that arise. > Especially the demo projects, with their scarce or almost non-existent > documentation cause problems for new users again and again. > If the only remaining hint for which device this code was designed is > removed in favor of a generic include, then they will be totally lost - > and even support by experienced users becomes at least very difficult. > > The compiler could as well auto-include MSP430.h ;) > Also, code using a generic include becomes less portable. > Unless all compilers use the same or 100% compatible MSP430.h file.
In fact, they do. It was the use in CCS and IAR that motivated my transition of mspgcc to supporting an <msp430.h>. > About the different supported devices, yes, I know this situation. > You can as well include ifdefs for including the proper headers. > It also makes clear which devices are supported by the code. > Again, a generic include doesn't. Including <msp430f2274.h> tells me the code supports that chip. It doesn't tell me that the code actually supports any chip that has an ADC10. That would be indicated by: #include <msp430.h> #ifndef __MSP430_HAS_ADC10__ #error Peripheral not supported #endif /* ADC10 */ > (for UART functions, I even include different code depending on device, > USCI/USART, available ram etc. So why not inlcuding the proper > headers too?) I understand your point. I just don't agree that your approach is the superior solution. Peter > IMHO, not everything TI does is 'right'. > And if we come to a conclusion, we both together should have enough > influence to make TI change their decisions. At least in details like this. > > JMGross > > > ------------------------------------------------------------------------------ > 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
