-chan.org/docs/mmc/mmc_e.html.
At the time we made the measurements I did not know how to modify thar
part of the driver.
Regards,
André
- Original Message -
*From:* Eric Decker mailto:cire...@gmail.com
*To:* Avishay Meron mailto:avishay.me...@mail.huji.ac.il
*Cc:* steve
all,
i'd like to thank janos for doing this work, because it enabled me to
port this stack over to the shimmer platforms, which i just checked in.
both time resolutions compile/install/run, but i have not tested
timestamping yet (i do have a volunteer already).
apologies to janos, but i
hi miklos,
in the meantime, on shimmers you can certainly wire in FastClockC, which
uses the platform's 8mhz xt2 and runs smclk at 4mhz, which will divert
data bottlenecks away from the spi bus...
$0.02,
steve
On 04/21/2011 04:50 AM, Miklos Maroti wrote:
Hi Michiel,
I think creating
hi janos,
i validated this code, which came from an old (OLD) mspgcc post, on a
scope, toggling a pin and measuring the duration.
doing it again now, with the stock 4mhz clock, a nominal 100us wait
takes 100.7us. pretty reasonable. at 8mhz, i see 105.1us.
with your code, we have a delay of
hi.
miklos, you may be confusing the configurations among the various
shimmer revs, which have different pin layouts relative to the cc2420.
on shimmer, the sfd signal is routed to a capture-capable pin on the
msp430; on shimmer2, due to an oversight it was not, so a capture was
manually
aha!
why didn't you say so? i'll make the change now.
thanks for pointing this out; please tell me when i miss details like
that when you discover them, it helps me a great deal to have others my
bugs.
i committed the fix.
thanks again. silvan, please let me know if this solves your
