MSP430F5419a - 100pin quad flat pack.
I would like to know if USCI_A0 & USCI_B0 can be operated simultaneously as Async UART & I2C master respectively. From inspection of datasheet, the resources on-chip appear to be entirely separate and for all 4 of the _Ax & 4 _Bx modules, the only constraints I can see that would disallow implementing this would be pinning conflicts in some modes on some of the USCI_A/Bx channels.
So as USCI_A0 (no harware handshake) is to run 9600 baud N81 asynch - pins 39/40 , and USCI_B0 as 2 wire 400kHz I2C pins 34/35, are there any gotchas?
And I only ask because I am a newbie to MSP430 core & peripherals. I am a little confused by statements in datasheet that imply up to four serial channels LIMIT. But there are no statements I can find in user manual or datasheet "slas655b.pdf" that specifically say my desire to implement as above is illegal.
I am I correct in the way I have interpreted this use of resource? BTW I also wish to use USCI_A1 & A2 & A3 in this design and foresee no issues with those channels.
Thanks in advance.
Regards,
Jim Parr
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.
Leo Hendrawan
- Now that my signature has caught your attention, please click the "Verify Answer" button if this post answers your question. Thanks! -
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 GeneratorThe ADC12_A module of the MSP430F54xx contains a built-in voltage reference with two selectablevoltage levels, 1.5 V and 2.5 V. Either of these reference voltages may be used internally and externallyon pin VREF+.The ADC12_A modules of other devices have a separate reference module that supplies three selectablevoltage levels, 1.5 V, 2.0 V, and 2.5 V to the ADC12_A. Either of these voltages may be used internallyand 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
I suspect the "MSP430F54xx " referred to in the family guide is the MSP430F5491 without the -a, the older iteration of the chip.
Tony
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
Hi Jim
Jim Parr 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.
If you are still new to MSP430, i would recommend you to take a look at the software tools TI offers today, for example in this case as you are doing 5xx family, the MSP430ware: http://www.ti.com/tool/msp430ware
This would help you to at least not writing anything from scratch.
Jim Parr BTW, the generic user manual "slau208h.pdf" states the following... 22.2.3 Voltage Reference GeneratorThe ADC12_A module of the MSP430F54xx contains a built-in voltage reference with two selectablevoltage levels, 1.5 V and 2.5 V. Either of these reference voltages may be used internally and externallyon pin VREF+.The ADC12_A modules of other devices have a separate reference module that supplies three selectablevoltage levels, 1.5 V, 2.0 V, and 2.5 V to the ADC12_A. Either of these voltages may be used internallyand 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?
TonyKao I suspect the "MSP430F54xx " referred to in the family guide is the MSP430F5491 without the -a, the older iteration of the chip. Tony
Tony is right in this case, Jim. The MSP430F54xx (without A) device do not have the REF (Reference Voltage Module) as the MSP430F54xxA devices. With the REF module it is of course possible to supply 2.0V reference voltage.
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 ParrI assume that your comment means specifically in this case that USCI_A0 & USCI_B0 can be used provided no pinning resource conflicts.
Jim ParrAgain I am rather confused because the F5491a data-sheet clearly allows use of 2.0V internal reference.
In 54xxA devices, there is a REF module. It offers 2V and overrides the ADC12 controls by default. However, for 1.5 and 2.5V reference, the ADC12 controls provide more options. You'll have to disable the REF module first.
So the A devices are not 100% backwards compatible to the 54xx. They need at least an additional REFCTL &= ~REFMSTR; Which many people didn't notice at first.
_____________________________________Before posting bug reports or ask for help, do at least quick scan over this article. It applies to any kind of problem reporting. On any forum. And/or look here.If you cannot discuss your problem in the public, feel free to start a private conversation: click on my name and then 'start conversation'. But please do so only if you really cannot do it in a public thread, as I usually read all threads. And I prefer to answer where others can profit from it (or contribute to it) too.
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 Parr 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.
You can always code the time/size critical parts of your program in assembly, then use the main C framework to "glue" them together.
Also, have you tried playing with some of the optimizer options? You may be surprised at what the compiler can do in some instances. Of course nothing replaces human ingenuity. :)
BTW, to compare code size you should look at the linker map instead of the intermediate object code themselves, since the object codes contain a lot of debug information as well as hints for the linker to help with optimization. The linker memory map would give a clearer picture of how much space you're actually using.
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.