Forums

Hi Jim,

it shoul be possible to use USCI_Ax and USCI_Bx simultaneously. In my opinion, they can be seen as "separated" modules. I have never done it myself, but i have seen customers doing that.

Hope this helps.

Hi Ihend,

Thanks for very  prompt response to my query.  I assume that your comment means specifically in this case that USCI_A0 & USCI_B0 can be used provided no pinning resource conflicts.  I am nearly 100% sure this is your answer but there is a lot riding on this design at prototyping stage so want to be as sure as I can this is OK!

I have been cutting a bit of code (successfully) in MSP430 - but new language 'C', new instruction set & new IDE environment to cope with all at once.  So thanks for this encouraging news.

BTW, the generic user manual "slau208h.pdf" states the following...

22.2.3 Voltage Reference Generator
The ADC12_A module of the MSP430F54xx contains a built-in voltage reference with two selectable
voltage levels, 1.5 V and 2.5 V. Either of these reference voltages may be used internally and externally
on pin VREF+.
The ADC12_A modules of other devices have a separate reference module that supplies three selectable
voltage levels, 1.5 V, 2.0 V, and 2.5 V to the ADC12_A. Either of these voltages may be used internally
and externally on pin VREF+.

Again I am rather confused because the F5491a data-sheet clearly allows use of 2.0V internal reference.  I will be using 3V0 supply and have chosen 2.0V reference as best fit for this job when all parameters considered.

Q. Can you tell me if 2.0V INTERNAL reference is usable on F5419a part?

Cheers and thanks again Ihend,

Jim

Thanks Tony.  That makes perfect sense.  I need to go mining the TI document resource to find the latest documents and update my archives.
Jim

Thanks Ihend,

I have taken a brief look at the CCStudio offerings.  Have bookmarked and will inspect over weekend (aside from the downtime On TI website this weekend).  I am using CCStudio for code development right now.

My major learning curve issues are about coping with 'C' structures - because I am a 'dyed in the wool' assembler chap who knows how to get the very best performance out of micro-controllers.  So even the basic 'C' language abstractions leave me rather gob-smacked still.

Don't get me wrong.  A project of this size and complexity needs 'C' to get it going.  But am very ambivalent about much of the object code I see generated.  Hopefully I will learn quickly how to exploit the language to better effect.

Thanks for the resource link Ihend.  I am sure it will be most useful once I get myself properly saddled up.

Best regards,

Jim

Thank you Mr Gross for your helpful comments.

You appear to have also confirmed that my particular USCI usage is legal.  I fully understand the potential minefield of pinning conflicts but can see none for USCI_A0 and USCI_B0 when both in basic 2-wire modes (UART & I2C in this case).

Ok your comments in respect of interrupt vectors for 2x/5x families.  Understood.  Vector sub-tables are always a pain -especially when all you might want to do is toggle a flag and hand back control.

Thanks for this detail on ADC12.  I have understood all you wrote but need to verify for myself in data-sheets that the data-sheets I am using are kosher.  Interesting that you state option changes between REF module engaged and disengaged.  Will research this as a matter of priority to make sure that I have the right of it all B4 casting prototype artwork in concrete.

Understood non-backward compliance between 54xx & 54xxA.  I am among those who did not notice.

Thanks a lot for reply.

Jim

Thanks for the tips Tony.

All understood.  I have fiddled with optimisation switches and settings - and yes this has made a difference in the past - especially to rather overburdened on-chip RAM.  For this reason I have added a 128Kbyte FRAM on the I2C bus to mitigate this problem (although frankly I have difficulty conceiving how a programmer can gobble 16Kbyte on-chip memory in course of orthodox coding of a program for a supervisory style project.

I have inherited a basically well written program - previous model of product.  But I have now made HUGE alterations to the hardware in order to exploit ALL the on-chip CNTR/TMR peripheral hardware (as I/O) and also improve expandability - hence use of all USCI ports in various orthodox ways.  In other words, because the product exploits low-power modes of micro-controller in many ways, I have a fairly fiddly set of problems on my hands.  The consequent massive increase of interrupt oriented events will require very careful construction of code to meet the goals of project.  Oh well I would probably go stir-crazy if I didn't have a decent problem I can bite down on...

I understand about the linker map - now.  Thanks especially for that tip.   Basically these appear to be 'assembler' equivalents so had little difficulty sorting out what you mean here.

I have found the 'C' compiler quite tolerant of very BASIC structures and it seems to code these in a passably practical way.  So I may wind up using rather less in-line assembler when I have fully understood the concepts - in particular - usage of core register set as opposed to direct operations on RAM registers.  And all this is about correct scoping and management of variables and their type-casting methinks.

I will get there.  Don't think it is going to be fun because I do not like the tools much (stupid and needless time-wasting communication difficulties with a PET for example).  But hey that's life.

Best regards,

Jim Parr