hey Steve,

wait so currently it's PFLAGS += -DSMCLK_4MHZ in the jfatlogging makefile, and I want to change it to PFLAGS += -DUSE_8MHZ_CRYSTAL in there as well as in rovingnetworks? the following snippet is currently in rovingnetworksp:

#ifdef USE_8MHZ_CRYSTAL // we need exact divisors, else the thing acts unpredictably
    call UARTControl.setUbr(0x08);
    call UARTControl.setUmctl(0xee);

    /* 4mhz smclk
    call UARTControl.setUbr(0x23);
    call UARTControl.setUmctl(0xd6);
    */
#endif

sorry for the confusion!
thanks,
Richard

Quoting steve ayer <[email protected]>:

hi richard,

don't forget to edit RovingNetworksP.nc to expose the correct calls to
rest the uart clock.  search for USE_8MHZ_CRYSTAL to locate that
snippet and change the comment...

-steve


On 05/31/2011 11:49 AM, [email protected] wrote:
Hi Steve,

Thanks for your reply. I've updated my tinyos and it's now on revision
5605. I've also replaced the clock line in the makefile, however,
nothing changed as far as I can tell. Sorry about the FAT_EKG thing, I
found the dead files on google and seemed like it fit what I was trying
to do.

Cheers,
Richard

Quoting steve ayer <[email protected]>:

hi richard,

you may have a clock skew problem, as the bluetooth module uses the
uart to communicate with the mcu on the shimmer, and justfatlogging
uses a high-speed clock configuration.

my casual observation (please don't send me code if this isn't the
problem) sez that you'll need two things to get going: 1) a flag in
your makefile telling the bluetooth module that you're running this
clock configuration (PFLAGS += -DUSE_8MHZ_CRYSTAL) and 2) an updated
bluetooth driver, the public version of which was missing a second set
of uart settings for this case.

good news is that your mail reminded me that i never got around to
releasing this driver update, but i have now!

update ~/tinyos-main/tos/platforms/shimmer/chips/bluetooth/ to get what
you need, then edit the file to swap the comments between the 1mhz and
4mhz smclk calls.

i hope that this helps,

steve

ps: you should not look at FAT_EKG for guidance; it has no relevance
to our mainstream codebase. in fact, thanks for reminding me to remove
it from the repository completely.



On 05/31/2011 10:39 AM, [email protected] wrote:
Hi,
I'm attempting to integrate the bluetooth function into justfatlogging,
and I've run into a couple of problems:
Firstly, after the code compiles and is loaded, it seems that bluetooth
commandModeEnded does not get triggered, as oppose to the case in
HelloWorld. Secondly, bluetooth.writeDone is not triggered either with
no good explanation, thus the ready flag is not changed within and the
write only happens once. Lastly, I'm using hyperterminal to intepret a
test message sent through bluetooth. the same message from HelloWorld,
which displays perfectly as ascii, would become jumbled and not
completely sent when the functionality is brought over to
justfatlogging.
All that i'm doing is copying over the code from helloworld, plus adding
in the necessary initialization etc. Does anyone have any idea regarding
this? Also, is there a better way to integrate SD+bluetooth
functionality? I've checked out Reconfigurable and FAT_EKG and both of
them seem to point this way.

Thanks a lot,
Richard








_______________________________________________
Shimmer-users mailing list
[email protected]
https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users

Reply via email to