Hello, there is a reason to know about the usb periphery. You can use some usb ports as GPIO and you need to configure it directly in the usb periphery registers. I think we should not virtually remove the usb periphery registers. We should be able to change the ram start/end address independent of the usb or some other periphery.
Regards, Mathias Am 19.10.2011 12:16, schrieb JMGross: > > Peter, > that wasn't what I meant nor what I think I said. > > It is not a matter of experience. > > Everyone who learned C(++) first, has learned to > include the necessary heeader file one by one, if > hee wants to use the features they provide. > So a separate USB header file is 'normal' for everyone, > who learned C first before moving to the MSP. > The MSP approach to have an all-in-one header file > is the 'unusual' way to do things. > (This is _not_ a judgement of which way is better!) > > However, having to configure a different MSP type > (by a suffix) to have the ram available for USB or not > is unusual for both, normal C programmers and > MSP-experienced programmers. > >>From a compiler programmers view, this may be > the cleanest solution. But not really from a compiler > users view. > > Of course, this is only my personal opinion (backed by > some observations in the TI MSP forum), and if you > decide to do things different, that's your decision. > > BTW: Maybe I wasn't clear about my suggestion: > I didn't mean just enabling USB by the separate header file. > I meant including ALL the USB related header information > in a separate file that is not auto-included by MSP430.h > So if someone wants to access the USB registers, > he will need to include the USB.H and gets the USB > ram assigned to the USB too. If he doesn't include > the header, he will not have access to the USB registers at > all. Just like printf() and other things. > The thing I was unsure about was whether some USB > registers need to be accessed even if you don't want to > use USB. (e.g. to totally deactivate it) > I have not enough experience with the USB module > to be sure of that. > > JMGross > > ----- Ursprüngliche Nachricht ----- > Von: Peter Bigot > Gesendet am: 18 Okt 2011 14:54:49 > > > On Tue, Oct 18, 2011 at 5:22 AM, JMGross <msp...@grossibaer.de> wrote: > >> >> I agree with you about the compatibility (or the lack of). >> However, the other way would be to either patch the linker files >> individually for each project (with/without USB-ram), or to >> introduce two different 'CPUs' for compiler/linker. >> >> Having to include the USB header is not different from including >> string.h or similar if you want to use them. So it is not too >> complicated or surprising for users. The other two solutions, >> however, are non-normal, unexpected operations. >> >> Every solution (except for ingoring the additional 2k ram if >> USB is not used) requires a 'non-conforming' action. >> The question is, which action is easiest. >> And including an USB header if you want to use USB is >> the most natural thing for every C programmer (except for >> people who started with C on an MSP) >> > > An observation: some people might be insulted by a suggestion that they're > too inexperienced to see the superiority of your solution. > > Since the standard MCU header already provides all the USB-related > peripheral registers and flags, including a second file to enable USB is no= > t > natural. Disabling resources reserved for USB is the deviation from normal > practice that should require a "non-conforming" action. > > I'll implement an mcu suffix solution as soon as TI provides me the > necessary information to produce new linker scripts. > > Peter > > >> >> JMGross >> >> ----- Urspr=FCngliche Nachricht ----- >> Von: Crazy Casta >> An: mspgcc-users@lists.sourceforge.net >> Gesendet am: 18 Okt 2011 06:11:11 >> Betreff: Re: [Mspgcc-users] MSP430F5510 - USB RAM >> >> I'm against the idea of adding a USB specific header because it's >> different from what TI does. I think it will be easier to publish >> patches and all if the changes are minimal from the TI published code. >> It currently looks as if the difference will be a few lines of code in >> one file and the addition of a Makefile to describe the build process. >> I personally think the dual MCU idea is quite good and better than a >> separate header. >> >> Alex >> >> On Wed, Oct 12, 2011 at 9:16 AM, JMGross <msp...@grossibaer.de> wrote: >>> >>> Yes, that's what I thought. >>> However, I don't know whether the USB part is in lowest power state aft= > er >> a reset. >>> If not, you'll need to access its regsiters and therefore need the >> register definitions >>> even if you don't use USB, to get the MSP to it s lowest power state. >>> >>> But if it is, my suggestion was to generally treat the ram as ram. >>> Only if someone explicitely includes the header file with the USB >> definitions, >>> then the lower 2k of the ram are occupied by a (dummy) buffer of that >> size and a >>> fixed address, so that the linker will place everythng else above it. >>> So once you include the USB header, you'll get a dummy variable of 2 k >> size that >>> happens to sit exactly where the USB needs to have its ram. >>> >>> Then there is no need for separate linker scripts. >>> >>> JMGross >>> >>> ----- Urspr=FCngliche Nachricht ----- >>> Von: Mathias K. >>> An: mspgcc-users@lists.sourceforge.net >>> Gesendet am: 11 Okt 2011 19:05:48 >>> Betreff: Re: [Mspgcc-users] MSP430F5510 - USB RAM >>> >>> Hello, >>> >>> the USB-Ram is only used by hardware if the USB-Periphery is enabled. I >>> use a custom linker map file to expand the RAM. I don't use USB yet. >>> >>> >>> Regards, >>> >>> Mathias >>> >>> Am 11.10.2011 12:51, schrieb JMGross: >>>> >>>> A possible way to handle this (at least on chips where the USB ram is >> right >>>> before and not behind the 'normal' ram) would be to have the USB-relat= > ed >>>> includes in a separate header file that needs to be included manually. >>>> Within the header file, the USB ram is allocated as a fixed-address >>>> non-initialized buffer. >>>> >>>> This way, it would be placed there if the header is included and the r= > am >> would >>>> be free for the rest if not. >>>> Since the USB ram is before the normal ram, there is no need for a >> separate >>>> linker file, as the stack pointer init would be the same. The USB ram >> would >>>> just be normal ram in the memory map. >>>> >>>> But I'm not 100% sure whether you need to access the USB registers (an= > d >>>> therefore include the USB header) just to send the USB part in lowest >> power >>>> state after power-up. I never worked with USB. >>>> >>>> JMGross >>>> >>>> ----- Urspr=FCngliche Nachricht ----- >>>> Von: Peter Bigot >>>> An: Mathias K. >>>> Gesendet am: 09 Okt 2011 18:11:30 >>>> Betreff: Re: [Mspgcc-users] MSP430F5510 - USB RAM >>>> >>>> Found an old related ticket at >>>> >> https://sourceforge.net/tracker/?func=3Ddetail&aid=3D3113886&group_id=3D4= > 2303&atid=3D432701 >>>> >>>> I've asked TI to provide the information necessary to support the >> solution >>>> described below in the next msp430mcu release. >>>> >>>> Peter >>>> >>>> On Sat, Oct 8, 2011 at 6:38 AM, Peter Bigot<big...@acm.org> wrote: >>>> >>>>> I don't believe so. >>>>> >>>>> One fairly simple solution would be to augment msp430mcu to detect >>>>> chips with USB RAM and to provide two MCU descriptions for them. >>>>> Viz., msp430f5510 which would reserve USB memory and msp430f5510nousb >>>>> which would combine it with RAM (assuming the two are contiguous). >>>>> The only difference would be in linker flags and the memory map. >>>>> >>>> > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct > _______________________________________________ > Mspgcc-users mailing list > Mspgcc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mspgcc-users ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
