hi grant,
as long as you use lpm3 for a sleep state, the aclk is still running...
-steve
On 02/24/2012 10:37 AM, Grant Edwards wrote:
On 2012-02-24, steve ayera...@handhelds.org wrote:
not necessarily. you can certainly provide a device with a seed
timestamp that will carry through an
mark,
exactly. software, meet hardware.
-steve
On 02/24/2012 12:36 PM, Mark Rages wrote:
On Fri, Feb 24, 2012 at 9:06 AM, Sergio Campamásergiocamp...@gmail.com
wrote:
it's not bad, but very imprecise… i don't think its a real replacement for
gettimeofday()
This makes no sense... you
or, if you want really simple, the python bsl tool
(http://packages.python.org/python-msp430-tools/commandline_tools.html#msp430-bsl).
tinyos has its own version, too (tos-bsl).
-steve
On 01/30/2012 05:46 AM, Eric Decker wrote:
mspdebug
See: http://mspdebug.sourceforge.net/
On Mon,
...
python bsl == $0.00.
fast. works.
and, as the hot-rodders (used to) say, you run what you brung.
only effort required on your part is to determine the polarity of the
test and reset signals on your board.
-steve
On 01/30/2012 06:58 AM, Eric Decker wrote:
On Mon, Jan 30, 2012 at 3:00
hi,
of course, you could put a wire on an unused gpio pin and put the device
on a scope; that will give you accurate timing of code segments.
-steve
On 01/06/2012 01:21 PM, Peter Bigot wrote:
On Fri, Jan 6, 2012 at 12:08 PM, Mark Ragesmarkra...@gmail.com wrote:
Hi,
I have a moderately
hi mark,
sorry, i haven't profiled code outside of actually running it on actual
hardware. if you find your simulator, just remember the immortal words
of donald knuth, Beware of bugs in the above code; I have only proved
it correct, not tried it.
have fun,
steve
On 01/06/2012 03:05 PM,
that
they're vaguely similiar, the addresses/sizes of the code/vectors seem
right, but...
i did try adding the -mcpu=430xv2 flag to the compile line, but that
makes no difference in the ihex.
can anyone please offer a pointer on how to proceed?
thanks,
steve ayer
-up? The current msp430
toolchain does not do this automatically like the old one did.
Peter
On Thu, Sep 29, 2011 at 11:12 AM, steve ayer a...@handhelds.org
mailto:a...@handhelds.org wrote:
hi folks,
last summer (july 2010) i bought a ti eval board for the 5438 and
proceeded
in the ihex.
can anyone please offer a pointer on how to proceed?
thanks,
steve ayer
--**--**
--
All the data continuously generated in your IT infrastructure contains
a
definitive record
um,
if it ain't broke, don't fix it!
-steve
On 05/04/2011 02:24 PM, msp430 wrote:
I didn't expect such a response. Days ago i have read an article,
about the advantages of modern forums compared to mailing-lists.
develissimo.com is not yet perfect, but its improving from day to day.
I hope
hi michiel,
your mention of broken register variables caught my eye.
can you, or peter, please clarify?
thanks,
steve
On 04/19/2010 08:09 AM, Michiel Konstapel wrote:
-Original Message-
From: Peter Bigot [mailto:p...@peoplepowerco.com]
Sent: maandag 19 april 2010 14:02
To: GCC for
please provide some guidance? i'm afraid that i'm addicted to
the wonderfully-simple bsl.py.
thanks in advance,
steve ayer
JMGross wrote:
In the last days I did some experiments with the MSP430F5438 and its 32bit
hardware multiplier.
The compiler (non-X-build from 12/2008) generates proper
um,
can you all please take this thread into your own private little world,
please? this kind of bickering doesn't benefit the general audience in
the slightest.
just trying to keep the peace,
steve
Bevan Weiss wrote:
-Original Message-
From:
hello gunther and mat,
i do have one more small item to add to the libc patch: i found that there's a piece
missing from iomacros.h to define sfra(). here it is.
diff -urN -x CVS -x '*.x*' -x 'Makefile*' -x 'doc*' -x 'config*' -x '*.lo' -x '*.o' -x
'*.a'
hi mat and gunther.
i did have this problem, and i have encountered a couple of missing items to pull this as
far as compiling a simple bare_test.c. unfortunately, i haven't assembled all of my fixes
yet.
one of the things that i discovered late in the game (been at it for several days now)
hi mat and gunther,
i have what may be a complete supplemental patch for at least the binutils tree. i'll
check the gcc and libc bits tomorrow morning (eastern us time) and pass along anything
else that i did to get this far.
please let me know if i missed something in this tree and i'll
patch fails, choking on
missing mach_msp defs in archures.c, which propagate all over the bfd code.
can you shed some light on this for me, please?
thanks,
steve ayer
Gunther Lemm wrote:
Gunther Lemm wrote:
Hopefully, it'll work as expected (I'm absolutely no expert in hacking
compilers
aha!
i found the patch that has to be applied to binutils before yours, problem
solved.
sorry about the confusion. i'll let you know what i find out and send you any mods that i
have to make.
-steve
steve ayer wrote:
hi gunther.
thanks for your work on adding support the new msp430s
hi,
take a look at tinyos-1.x, which does a good job of hardware abstraction
and has a large community of developers working on msp430-based
platforms, both cots and custom. for reference, we use(d) the f1611
variant.
in particular, if you're interested in an excellent network software
hi,
could someone on the devel team please post to this list when they're
able to sync the development cvs to the public tree?
a MSP430mspgcc bug fix for jtag verification that's already done would
help me considerably...
thanks,
steve
20 matches
Mail list logo
