On Mon, Sep 26, 2011 at 3:49 PM, Nikhil Deshpande <[email protected]>wrote:
> Hi Eric, > > I was able to get both problems solved, thanks to your pointers. I > appreciate it a lot! > Good. Glad you got it working. > After some digging, I think I understood the hierarchy of the modules and > components for the MSP430 UART on TelosB. The Msp430UartP generic module > configures the UART on the TelosB, based on the Resource call which includes > the port number - UART0 or UART1. > Well I'm sure the thinking at the time made sense, The 1611 has a limited number of ports. There is a thing that TI calls the USART and the 1611 has two of them. The USART is an odd beast but that is what TI has given us. It is odd in that each USART can be configured to be a UART or a SPI (and one can be configured as I2C). I'm not sure how much of the h/w blocks are shared, I am sure that the state machines are very different. It doesn't make a great deal of sense to me (and I've been around awhile) but like I said it is what TI gave us. So the question then becomes what to name things. USART0 can provide a UART, a SPI, or an I2C port and USART1 provides UART and SPI. This gets more interesting when you start adding more ports. New processors such as the 5438 has 4 USCIs (similar to the USART but improved?). I played around with trying to name ports in a simple numeric fashion (ie. UART0, UART1, etc) but how the ports are actually used really is a platform specific thing. With the USCI ports it gets very confusing trying to come up with a standard naming convention for something that is inherently a platform specific thing. So for the x2 (2617/2618) and x5 families (5438 etc), both USCI based, we've adapted a different naming convention. Instead of simple numeric numbers, we use which USCI the port is part of. ie. Msp430UartA0 is port A0 used as a UART. Msp430SpiA0, etc. A given USCI has an A and B part, As can be UART or SPI, Bs can be SPI or I2C. Very strange but there it is. A Resource request initiates the *ResourceConfigure.configure()* call in the > Msp430UartP module and the configuration block to this call is obtained from > the *Msp430UartConfigure.getConfig()* function. (The name of this function > is rather counter-intuitive, in my opinion... shouldn't it be setConfig()?) > No. getConfig is a call out from the Arbiter to the Resource client to obtain a configuration block that is then used by the configurator to set the h/w up. The Arbiter is agnostic. It doesn't know anything about how to set up the h/w that is the down call which is ResourceConfigure.configure(). But the client needs to provide how it wants the h/w set up. That is the getConfig call. Now where this breaks down is in practice you want all this to be ultra efficient, so the configuration block in practice is register values that get slammed into h/w registers to get the right things to happen. But these values are also specific to the cpu and platform, clock rates, etc. ie. how does one specify UART baud rate. in the msp430 config block it is specified as a divisor which divides the main cpu clock down). I'm sure you see how that breaks across different platforms running at different clock rates. Are you at 4MHz vs. 8Mhz. The current TinyOS code tried to say he is the default config block to get such and such a speed. The reality is that it is a platform specific thing and should have a well defined mechanism for the platform to provide that kind of thing. The problem is you really really want it to be ultra efficient especially if the h/w is arbitrated because it will potentially be happening alot. The whole business that the MSP430 h/w is by default is arbitrated is another issue. Probably shouldn't be with arbitrated being something that is easy to add if the platform/design requires it because the h/w is shared. The default came into play because TinyOS started on the MSP430 with the 1611 which has limited h/w ports and the configuration of those ports (as pointed out above) is strange. So pretty much required arbitration. But as shown above arbitration has an associated cost. > This function obviously is required to be in any user-defined UART Comms. > module - where the defined comms. parameter block is provided. So... > > 1. I did not require separate instances of the Resource client. Just > defined separate configuration blocks for the different baud rates. Then, > before operating at a particular desired baud rate for the device, I release > the earlier requested Resource instance, change a variable value, and > re-request the Resource as a new instance. This changing variable rests as a > *switch-case* in the *Msp430UartConfigure.getConfig()* function. The > variable value directs the usage of the desired configuration block in the > function, when it is called by the *ResourceConfigure.configure()* function. > This sets the desired baud rate and I'm good to go. Obviously, I need to > remember to change the baud rate of the command terminal every time I change > the baud rate on the TelosB, to start receiving data at the new baud rate! > That certainly works but is expensive. It is easier to bypass the layers and hit the interface directly. Simpler in code too. > > 2. The full-duples comms. problem was a coding error - I was unnecessarily > releasing/requesting the Resource before every Tx and Rx operation. That was > obviously not required, and I have full duplex comms. now with a single > Resource request. I only release the Resource when I require to reconfigure > the baud rates. > > Finally I can play with this - reconfiguring other UART comms. parameters > was part of the original intention with it. > > Best, > > ~ Nikhil > > > On 23 September 2011 01:58, Eric Decker <[email protected]> wrote: > >> >> >> On Thu, Sep 22, 2011 at 10:24 PM, Nikhil Deshpande < >> [email protected]> wrote: >> >>> On 23 September 2011 00:37, Eric Decker <[email protected]> wrote: >>> >>>> >>>> >>>> On Tue, Sep 20, 2011 at 10:05 PM, Nikhil Deshpande < >>>> [email protected]> wrote: >>>> >>>>> Hi, >>>>> >>>>> There are two issues - which I've been struggling with for a while now. >>>>> 1. I was wondering if there was any way to reconfigure the UART baud >>>>> rates at run time in the MSP430 telosb mote? Currently, I have the UART >>>>> working with the default configuration - which I can change at compile >>>>> time. >>>>> I have daisy chained devices to the mote, which are at different baud >>>>> rates. >>>>> >>>> >>>> I'm not sure how to help you figure this out... But yes you can >>>> change the UART configuration. Clearly, one can always jam different >>>> values >>>> into the h/w and that will certainly change what the UART is doing. Given >>>> that one can do this at the lowest level argues that it is at least >>>> possible >>>> to do this using higher level mechanisms. >>>> >>>> One can call the configuration routines directly, check out the >>>> interfaces in tos/chips/msp430/usart or usci depending on the chip family. >>>> >>>> You need to study how the lower levels work. One way of doing this is >>>> to define two different resource clients and the 2nd one's configuration >>>> block has the new baud rate. When the grant for this client is generated >>>> the h/w will have been configured for the new baud rate. >>>> >>>> No I'm not going to show you how it is done. Look at the tutorials on >>>> how to use Resources. >>>> >>> >>>> >>> Aah... I didn't think of it this way - that should certainly be possible. >>> Thanks for the thought. I'll give it a try and post an update. Also, I >>> wouldn't want you to show me how it's done anyway! >>> >> >> cool. A lot of folks on this mailing list don't do their homework. >> >> >>> I was just wanting to know whether I was wasting my effort on something >>> that someone else had already done and/or wasn't possible... >>> >> >> Well there ya go. Cool. After digging into things, go ahead and ask >> more questions. I don't mind helping folks who are digging in. >> >> >>> >>>> >>>>> 2. Since the UART uses the Resource interface - there seems to be no >>>>> way for full duplex communication, i.e. having TX and RX working >>>>> simultaneously. I have it working in polling mode - where I transfer the >>>>> resource back-and-forth between TX and RX when either is done. Am I >>>>> missing >>>>> something trivial here? Is there a better way to do this? >>>>> >>>> >>>> I don't understand what you are doing or why you are concluding that >>>> because the Resource interface is being used that precludes simultaneous >>>> TX/RX operation. >>>> >>>> You conclusion is wrong. The Resource subsystem controls access to a >>>> shared resource. Once the resource is granted any operations can be done. >>>> This includes simultaneous TX/RX operations. I don't understand why you >>>> think you need to poll nor why you have a TX resource and RX resource. >>>> You >>>> do need a coordinated subsystem that handles both TX/RX together. >>>> >>> >> sorry if i was harsh. didn't intend to be. >> >> >>> >>>> >>> The existing SerialAM code does do this. >>>> >>> >>>> >>> Hmmm... Maybe I'm doing it wrong then. I'll go back and look at my code. >>> It sounds simple enough... >>> >> >> It is hard to understand the tinyos code and how it is written but it is >> in there. >> >> I have found the easiest way to understand the code by following it via >> insitu using a jtag and single stepping the code. I recommend you do the >> same. >> >> >> eric >> >> >> >>> >>>>> Thanks, >>>>> >>>>> ~ Nikhil >>>>> >>>>> _______________________________________________ >>>>> Tinyos-help mailing list >>>>> [email protected] >>>>> >>>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >>>>> >>>> >>>> >>>> >>>> -- >>>> Eric B. Decker >>>> Senior (over 50 :-) Researcher >>>> >>>> >>>> Thanks, >>> >>> ~ Nikhil >>> >> >> >> >> -- >> Eric B. Decker >> Senior (over 50 :-) Researcher >> >> >> > -- Eric B. Decker Senior (over 50 :-) Researcher
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
