On one system I made, I had similar requirements - I needed to generate a
baud clock (uarts tolerate up to 5% difference between the sender and the
transmitter), and had a 32kHz crystal on the timer pins as a reference. I
made a very simple regulator in software. I aimed to drive the DCO at a
par
curate baud
rate. However, I wanted other timing functions to be improved as well, and
you don't gain anything much by aiming for a uart accuracy of more than
about 1%.
> David Brown wrote:
> > On one system I made, I had similar requirements - I needed to generate
a
> > baud clo
s. You get accuracy +-
> 1.5%, and then set fixed U0BRx and U0MCTL modulator value
>
>
>
> David Brown wrote:
> >>And what about baud modulator UMCTL0. Is it precalculated fixed value?
> >>
> >
> >
> > Yes - it was calculated from the target fre
> Is there a more elegant solution than adding a dummy function?
> Can I search the next RET instruction or something like this?
>
More elegant (and more reliable, if you've got heavy optomisations enabled
on newer gcc) is to put your function in the initialised data section:
void __attribute__ (
What sort of compile-time options have you got turned on? It looks to me
like this is compiled with all optomisations switched off, and full
debugging on, so that the compiler generates as debugger-friendly code as
possible. For example, a local copy of the parameter d is made on the
stack, and m
>
> #define mc_RESET (*(void(**)(void))(0xfffe))()
> // alternate version:
> // #define mc_RESET { WDTCTL = 0xDEAD }
>
Your first version of mc_RESET is a very bad idea - it will not cause a
reset, so all peripherals in the device will still be set as they were when
the "reset" function/interrupt
t. I don't know whether
this is a big issue - maybe I'm the only one looking for the feature. If
USB-based debugging takes off, there will no longer be the same problem, as
support for multiple debuggers will be more natural there.
David Brown
System Developer
WestControl a.s
Norway
"Utvikling er kunsten av å vikle seg ut av det man har viklet seg inn i"
th an msp430fg439
> running suse-linux on an old 233MHz Celeron with 128MB RAM and it works
> without any problems.
> Have a nice day
>
> Arnd-Hendrik
>
> David Brown wrote:
> > Has anyone had success using LPT2 (on windows - or, for curiosity's sake
at
> > th
> David Brown wrote:
> > Hi Arnd-Hendrik,
> >
> > I did not realise that msp430-gdbproxy accepted a parallel port like
this
> > (although I knew about the choice of tcp/ip port for communicating with
> > gdb). That would certainly be a help if I can first get
> David Brown wrote:
> > I believe, but can't be sure, that my PCI parallel port card *is* mapped
to
> > IO. Windows (w2k) device manager reports it as using IO ports
> > 0xb000..0xb007, which looks to me like it could be accessed as a
standard
> > paralle
Hi,
I assume what you are trying to do here is store some data in flash as
non-volatile data. Apart from your linker issue (the rule is that
everything in header files is declared "extern", with a matching non-extern
definition in one c file), there are a few other things to note when storing
dat
t usable
would be very nice - but I can't make time just at the moment.
As for msp430-jtag and msp430-gdbproxy - I don't know why they don't work
given "0x378" as a parameter, HIL.dll works as expected from _parjtag.
Regards,
David
> David Brown wrote:
> > I be
> At 11:39 10-05-05 +0200, you wrote:
>
> >void Swap_TAB_UART(unsigned char ix, unsigned char len)
> >{
> >unsigned char i, tmp, l;
> >
> >l = len/2;
> >i = 0;
> >do
> > {
> > tmp = TAB_UART[ix+i];
> > TAB_UART[ix+i] = TAB_UART[ix+len-i-1];
> > TAB_UART[ix+len-i-1] = tmp;
> > i++;
> > } whil
> Hermann Kraus wrote:
>
> > On Mon, 06 Jun 2005 20:40:49 +0200, wrote:
> >
> >> Hi,
> >>
> >> on www.msp430.com (TI) there are only two x2xx devices
> >> and both do have the status "preview".
> >> You can't order samples of them online (but via the CEO ;-).
> >> The memory map is in the datashee
> At 04:53 17-06-05 -0400, you wrote:
> >I'm trying to write a bootstrap routine in C that will reside in flash
> >and be copied to RAM for execution. Can anyone give me some helpful
> >hints on how to do that?
>
> In an earlier discussion the method of copying a routine was discussed.
>
> >I've
The _BIC_SR_IRQ macro doesn't make sense outside interrupt functions. The
normal way to make a interrupt function that wakes up the processor is with
something like:
interrupt (TIMERA0_VECTOR) wakeup TimerRoutine(void) { ... };
http://mspgcc.sourceforge.net/manual/x918.html
mvh.,
David
>
> H
Comments intersperced with text below...
> N. Coesel wrote:
>
> >At 19:38 10-08-05 +0200, you wrote:
> >
> >>N. Coesel wrote :
> >>
> >>>Just a thought that pops into my mind: Is "long long int" a valid type?
If
> >>>
> >>>you want a 64 bit number, the proper type is "long long". I would not
rely
> > > BTW, I've seen processors where char is 32 bit.
>
> The storage allocation of a char may be 16-bits, 32-bits or whatever, with
> only 8-bits actually being used.
A "char" is always at least the size of the smallest allocation unit for the
architecture. So for a dsp with 16-bit or 32-bit ch
> Fellows,
>
> >From this long conversation I cannot understand what has to be fixed.
> I used long long types all the time and never had problems with them.
> So, in 3.2.xx, is there anything particular to be changed?
>
> Cheers,
> ~d
>
There may or may not be a problem - the discusion so far ha
> Hi all,
>
> ftp://ftp.soft-switch.org/pub/msp430-gdbproxy.exe is a new version of
> gdbproxy using the latest library code from TI. This means it supports
> the latest devices, like the 21x1, and the 42x0. It also means it works
> with the USB FET tool.
>
> Support for updating the firmware in th
This sounds like a perfectly good arrangement - if it makes your life easier
for maintaining the binutils, then fine. The majority of users do not call
the assembler or linker directly, and therefore only see the
compiler's -mcpu flag. Since you are leaving that unchanged, I think most
people wil
> Fellows,
>
> I almost finished porting gcc-4.xx.
> This has been completely rewritten ;)
>
> This will have some new features PLUS some intrising call will be modified
> (for example - registers passing scheme for mult/div routines as well as
> hardware multiplier has been changed). Therefore, pl
Hi,
I haven't figured out the signed multiply yet (maybe I'll get a chance to
think about it at home tonight), but this *should* work for unsigned. It's
untested as yet. Using MAC saves a couple of instructions compared to bare
MPY.
r5:r4 * r8:r9, result in r15:r14:r13:r12
r15: r14: r13: r1
Are you sure you have the right chip on the board, and the right chip
selected for the build? Most of the time when I get this sort of error it's
because I've built the code for an '149 but the card has an '147, or
similar.
Other than that, I've sometimes seen msp430 chips die, and fail to
commun
- Original Message -
From: "Robert Bon"
To:
Sent: Wednesday, October 19, 2005 9:22 AM
Subject: [Mspgcc-users] msp430 and CANBus
>
> Hello,
>
> Does any one has experiance with a msp430 with a CANBus.
> I believe that there isn't a msp430 processor with a CANBus controler.
> Is there a o
> See my comments added in-line below/
>
> Sincerely,
>
> David Smead
I've snipped a bit, and added new comments below.
mvh.,
David
>
> On Fri, 4 Nov 2005, Kris Heidenstrom wrote:
>
> > Hi all,
> >
> >
> >> 5. Avoid using global variables of small size - it is a waste of RAM.
> >
> > I don't u
>
> Hi,
>
> there is no difference between a file and a function static.
>
> I'm often using static because if complete initialisation is not done,
> the results can be random results and compiler and environment
> dependent bugs.
>
> Regards,
>
> Rolf
>
That's not quite true - there are *some* d
> Peter,
> > I have been working on a patch for gcc-4.0.2, and have it compiling now,
> > although I have some problems with the machine description file and
> > optimisations. I would like to put these into the public cvs so maybe
> > someone who knows how to fix it could, or when I get the chance
> On 2006-03-15, Chris Liechti wrote:
> > Grant Edwards schrieb:
> >> I've been looking at the code generated by avr-gcc 3.4.5, and
> >> it sure looks like there's a lot of extra overhead involved in
> >> ISRs. Let's write an ISR that just toggles a port pin every
> >> time the interrupt happens.
- Original Message -
From: "Grant Edwards"
To:
Sent: Thursday, March 16, 2006 4:22 PM
Subject: [Mspgcc-users] Re: Large interrupt overhead?
> On 2006-03-16, David Brown wrote:
>
> > As far as code size or performance is concerned, the AVR and
> > MSP430 ar
> Hi!
>
> Has anyone ever changed an interrupt handler during runtime?
> I need to do that and any idea is welcome.
>
> I suppose I should declare two ISR like:
>
> interrupt (NOVECTOR) ISR1 {}
> interrupt (NOVECTOR) ISR2 {}
>
> and then write the address of the routine I want in the flash
- Original Message -
From: "Grant Edwards"
To:
Sent: Monday, March 20, 2006 6:24 PM
Subject: [Mspgcc-users] Re: How to exit from low power mode?
> On 2006-03-20, Stokes, Mark wrote:
>
> > That's a silly statement, the build code is exactly the same.
> > One has a warning, one doesn't.
This might be slightly off-topic, and you might not be able to (or be
allowed to) answer it, but...
*Why* did TI make the CCE tools, especially the compiler? TI makes chips,
and wants to sell chips - development tools are just a way to give customers
the tools they need, so that they'll buy more
- Original Message -
From: "Recoskie, Chris"
To:
Sent: Friday, March 24, 2006 4:10 PM
Subject: RE: [Mspgcc-users] MSP430FG461X
>
> We already had compiler technology for other instruction set
> architectures that we reused. I don't think this is really the
> appropriate place to get i
> On 2006-03-24, Dmitry wrote:
> > On Friday 24 March 2006 18:37, Grant Edwards wrote:
> >> You're really going to add support to gcc for supporting
> >> code/data pointers of different sizes (e.g. 20 bit code
> >> pointers and 16 bit data pointers)?
> >
> > yes, gcc allows for this.
>
> Really?
The disk file system is utterly irrelevant. Windows (other than Win9x and
friends) supports FAT and NTFS, with NTFS being the most commonly used these
days, but for most purposes, and almost all applications, there is no
difference. Similarly, almost any Linux application will work regardless of
> Hi all,
>
> We have a MSP 430 project developed with release 20041112 of the Win32
> toolchain. Our c source files have been named with the suffix .cpp and
> while we have not used any classes some minor C++ language features
> (namespaces, variable declaration in the middle of blocks, maybe som
> Mindaugas Karciauskas schrieb:
> > The problem:
> > MSP should echo a symbol. But when I send a symbol to MSP from
> > HyperTerminal, for example 'e' (= 65h ), the software reads the buffer
> > RXBUF0 and sends it back through TXBUF0. However I don't get back 65h
> > but D9h instead. Or if
's been a while since I updated my
mspgcc-win32, but the last version I used, from 20050422, works fine.
mvh.,
David Brown
System Developer
WestControl a.s
Norway
"Utvikling er kunsten av å vikle seg ut av det man har viklet seg inn i"
K
and -1 is an error. The jtag.MSP430_Error_Number() function returns 0 for
no error, and the buffer has not been read.
Since downloading with gdb/gdbproxy works fine, I know the interface itself
is working properly. But I'd like to get the python stuff working - it
makes it a lot eas
I know the interface
itself
> is working properly. But I'd like to get the python stuff working - it
> makes it a lot easier to write user-friendly updater programs.
>
>
> David Brown
> System Developer
> WestControl a.s
> Norway
>
I don't want to sound dema
doesn't seem to work is the progress bar. It's hardly needed
for USB downloading - a full erase, download, program and verify of 16k code
takes about 3 seconds - but it might be useful for the parallel port
connection.
Many thanks,
David
> David Brown schrieb:
> >>However,
> On 19/05/06, David Brown wrote:
> > Hi Chris,
> >
> > It works!
> >
> > I checked out your latest changes, and msp430-download.py and
msp430-jtag.py
> > work smoothly. In fact, updates go so fast I think users might be
> > suspicious, even tho
Also in reply to Giancarlo's post, since it's the same problem...
The latest versions in the sourceforge cvs fix this problem.
mvh.,
David
- Original Message -
From: "Moussa Ba"
To:
Sent: Saturday, May 20, 2006 8:45 PM
Subject: [Mspgcc-users] TI-USB with MSPGCC
> I am trying to lo
- Original Message -
From: "Yvan Castilloux"
To:
Sent: Tuesday, June 13, 2006 12:29 AM
Subject: Re: [Mspgcc-users] Making and adding a library without msp430-ar
> Hi Grant,
>
> Thanx for your reply.
>
> My main goal is to create a library with which a user cannot recreate the
C
> code.
h
the
> keep (-K) option and it seems that I have to keep all the global variables
> and functions for it to link properly.
>
> Thanx,
>
> Yvan
>
>
> >From: "David Brown"
> >Reply-To: "GCC for MSP430 - http://mspgcc.sf.net";
> >
> >
include the files such as:
>
> #include "foo.c"
>
> Notice I'm including a .c file. I know it's probably not clean code but
it's
> the only simple way I can think of.
>
> I'm sure it would be very fun and challenging to migrate to mspg
>From the Olimex web page http://www.olimex.com/dev/msp-jtag-tiny.html , you
can get
the drivers for the Olimex jtag debugger, and install that as the driver for
the USB device. You then need to copy the "SiUSBXp.dll", "FTD2XX.dll", and
"MSP430.dll" from the Olimex software into the directory with
with the MSP430 USB
> programmer?
>
> I may have to fall back to the parallel port version.
>
> Greg
>
> -----Original Message-
> From: mspgcc-users-boun...@lists.sourceforge.net
> [mailto:mspgcc-users-boun...@lists.sourceforge.net] On Behalf Of David
> Brown
> Sent: Fr
27; option for details.
>
> debug: MSP430_Initialize()
> debug: MSP430_Configure()
> debug: MSP430_VCC(3000)
> debug: MSP430_Identify()
> info: msp430: Target device is a 'MSP430F169' (type 40)
> debug: MSP430_Configure()
> notice:msp430-gdbproxy: waiti
- Original Message -
From: "Bodo Rzany"
To:
Sent: Friday, June 30, 2006 10:57 AM
Subject: Re: [Mspgcc-users] Code generation question
> Am Wed, 28 Jun 2006 19:59:27 + (UTC) schrieb Grant Edwards:
> > Can anybody explain the code generated for this function?
> >
> > #include
> >
>
> Am Fri, 30 Jun 2006 11:20:03 +0200 schrieb David Brown:
> >>
> >> mov.b &0x0034, r15
> >> add r15, r15
> >> mov r15, &two
> >> ret
> >
> > That would be wrong. PINB is declared volatile - the C code says it
should
>
I don't mean to sound patronising, but I don't think you are aware of what
compilers do, how they work, how "volatile" works, or how to write good C
code for embedded systems. I'm afraid your post is almost completely
incorrect - I hope you take my reply here as constructive critisism to aid
your
- Original Message -
From: "Roberto Padovani"
To: "GCC for MSP430 - http://mspgcc.sf.net";
Sent: Monday, July 03, 2006 11:57 AM
Subject: Re: [Mspgcc-users] Code generation question
> Hi David,
>
> criticism is fineI'll explain my view.
>
>
- Original Message -
From: "John Pote"
To: "GCC for MSP430 - http://mspgcc.sf.net";
Sent: Monday, July 03, 2006 1:11 PM
Subject: Re: [Mspgcc-users] Code generation question
> Hi everone,
>
> My thought on the following snippet from the prev mail:-
>
> >> > By the way, I think it's also
- Original Message -
From: "Roberto Padovani"
To: "GCC for MSP430 - http://mspgcc.sf.net";
Sent: Monday, July 03, 2006 3:35 PM
Subject: Re: [Mspgcc-users] Code generation question
> >> if you really want that single instruction as a function by itself and
> >> you want it to write dire
lute the code.
So unnecessary variables have a very real drawback in the quality of the
source code. As a more minor point, they can have an adverse effect on the
quality of the target code, at least if debugging prevents the compiler from
using its most agressive optimisations.
mvh.,
David
- Original Message -
From: "Grant Edwards"
To:
Sent: Tuesday, July 04, 2006 3:52 AM
Subject: Re: [Mspgcc-users] bitfield code gen questions
> On 2006-07-04, David Smead wrote:
>
> > You can define all ports and pins in a single file and only need to
> > change that file if you move pi
un...@lists.sourceforge.net
> [mailto:mspgcc-users-boun...@lists.sourceforge.net] On Behalf Of David
Brown
> Sent: Tuesday, July 04, 2006 3:18 AM
> To: GCC for MSP430 - http://mspgcc.sf.net
> Subject: Re: [Mspgcc-users] bitfield code gen questions
>
>
> - Original Message -
> From: "
Grant Edwards wrote:
I've noticed that msp430-gcc 3.2.3 often generates
unnecessarily large frame sizes?
Can you post some compilable code that demonstrates these issues? I
haven't been able to reproduce them with simple test code - in every
case, independent branches have re-used stack a
Grant Edwards wrote:
On 2007-02-15, David Brown wrote:
I've noticed that msp430-gcc 3.2.3 often generates
unnecessarily large frame sizes?
Can you post some compilable code that demonstrates these issues?
I'm trying.
I think part of the recipe might be to allow one or tw
Christian Böhme wrote:
thereza wrote:
Also, with the built in frequency multiplier can I get a stable 8Mhz (or 16)
with just a watch crystal -- enough for some high speed serial communication
via the uart/spi?
The User's Guide goes into minute detail about the available clock modules and
th
thereza wrote:
William -
Thanks for the excellent information. My only confusion is that my adviser
(I'm a grad student) mentioned that the load capacitance of a crystal has to
be equal to what the MCU expects. I had thought that it didn't matter as
long as you got the values equal to what the
Grant Edwards wrote:
On 2007-04-11, wh_f...@telus.net wrote:
The latest compiler supports the extended CPU; the problem is
actually in the linker--I can't seem to make it recognise both
chunks of code space (that below and above the vectors).
Below is my original posting. I'm hoping someone k
Grant Edwards wrote:
On 2007-04-12, Grant Edwards wrote:
I've been thinking more about the problem. I think with the
degenerate case of only 2 bins, the problem isn't actually that
hard. If I've got it figured correctly, doing it optimally is
O(N^B), where N is the number of input sections a
Before you go any further, you should probably have a look through the
avr-gcc mailing list archives, and possibly look at their
implementations. They have recently gone through a similar process for
the newer AVR cores with larger memories.
If you are only using 16-bit data pointers (and I
age to do.
mvh.,
David
I think all of this is far too complicated for someone who hasn't ever
used/worked with these stuff.
I'll check the avr-gcc mailing list, thanks for the tip.
Best regards,
Oszkar
*David Brown *
Sent by: mspgcc-users-boun...@lists.sourcefo
Grant Edwards wrote:
On 2008-04-22, Przemek Klosowski wrote:
Cast one or both operands to 32-bit and C will give you a 32
bit result. Or copy one to a 32-bit and use that as the
result.
but, if you promote operands to 32-bit, the compiler will use
32x32->32 multiply, which is not implemented
Kris Heidenstrom wrote:
AFAIK and as has been pointed out, operand sizes for
multiplication in C determine the width of the result:
16 x 16 gives a 16-bit result
32 x 32 gives a 32-bit result.
The MSP's hardware multiplier does 16 x 16 with a
32-bit result, but there's no general way to ask
for
Grant Edwards wrote:
On 2008-04-22, Przemek Klosowski wrote:
Cast one or both operands to 32-bit and C will give you a 32
bit result. Or copy one to a 32-bit and use that as the
result.
but, if you promote operands to 32-bit, the compiler will use
32x32->32 multiply, which is not implemented
Kris Heidenstrom wrote:
AFAIK and as has been pointed out, operand sizes for
multiplication in C determine the width of the result:
16 x 16 gives a 16-bit result
32 x 32 gives a 32-bit result.
The MSP's hardware multiplier does 16 x 16 with a
32-bit result, but there's no general way to ask
for
Chris Liechti wrote:
Sergey A. Borshch schrieb:
Chris Liechti wrote:
It would be great when some of you could take the time and test this
installer and give feedback. In a test project I noticed code changes,
and it got smaller, but i did not yet fully checked that everything
still runs as ex
Peter Jansen wrote:
Hi Ivan,
The bigger code problem in your case is caused by GCC4 inlining
some functions by default. For example, an non-static inline
function, that is used only a single time (such as init_SPI
in your case), is included in the object file twice (the function
it
N. Coesel wrote:
- Original Message -
From: "Peter Jansen"
To: "Ivan Shcherbakov" ; "GCC for MSP430 -
http://mspgcc.sf.net"; ;
Sent: Wednesday, September 09, 2009 8:52 AM
Subject: Re: [Mspgcc-users] Announcement: MSP430-GCC 4.3.4
Hi Ivan,
Excellent news..
I tested it on a large
Ivan Shcherbakov wrote:
Hi, All,
Please be informed that GCC 4.3.4 was ported to MSP430 platform.
The port is available at http://mspgcc4.sourceforge.net/
This wonderful news! I haven't used msp430's very much in recent times,
but I might well be using them again soon. It will be good
Yann Ramin wrote:
Just did a test run on an application we have on the F1611.
-fno-inline -Os on 4.3.4
textdata bss dec hex filename
45314 247968 53306d03a app.bin
-Os on 3.2.3
textdata bss dec hex filename
43738 727940 51750
N. Coesel wrote:
At 14:34 14-11-2009 -0700, you wrote:
Does msp430-gcc provide any systematic way, such as a generated symbol, from
which a C source file can determine the size of a function? I have a
function
for field reprogramming, which is moved to RAM before use, and need to know
how many
Wayne Uroda wrote:
No there is no real way to do this from my experience (especially not
at compile time). I did have success with using an empty function
after my flash writer and then doing pointer arithmetic to find the
size of the flash func, eg
void A() { ... }
void B() {}
//find size of
JMGross wrote:
It's a tricky thing. In the early days of compilers, I'd just had
done function pointer arithmetics (subtract the start address from
the start address of the following function) but today with all these
optimisations, the compiler can rearrange everything. It' s not even
sure wheth
N. Coesel wrote:
At 15:40 17-11-2009 -0700, you wrote:
On Tuesday 17 November 2009 15:33:24 Nico Coesel wrote:
Why is your flash programming routine so large? Only the part that does the
actual flash programming has to be in ram. This is just a few lines of
code. Perhaps you need to split the
N. Coesel wrote:
N. Coesel wrote:
At 15:40 17-11-2009 -0700, you wrote:
On Tuesday 17 November 2009 15:33:24 Nico Coesel wrote:
Why is your flash programming routine so large? Only the part that does
the
actual flash programming has to be in ram. This is just a few lines of
code. Perhaps you
N. Coesel wrote:
- Original Message -
From: "Peter Jansen"
To: "GCC for MSP430 - http://mspgcc.sf.net";
Sent: Wednesday, November 18, 2009 11:43 AM
Subject: Re: [Mspgcc-users] Size of functions
You could have several seperate C files for several functions. Hash.c,
decrypt.c, encryp
N. Coesel wrote:
At 15:54 18-11-2009 +, you wrote:
On 2009-11-18, David Brown wrote:
N. Coesel wrote:
The old "security by obscurity" trick, that has /such/ a good reputation?
Any means of security is security by obscurity by definition.
All protections schemes come down t
On 24/02/2010 05:18, Grant Edwards wrote:
On 2010-02-24, Carl wrote:
Sorry, here is the code for the msp430:
#include
int main(void)
{
short x = -32768;
unsigned long y = -x;
LPM0;
}
And same code as my previous posting for the PC:
#include
int main()
{
short x
On 03/09/2010 02:31, William "Chops" Westfield wrote:
On Sep 2, 2010, at 12:35 PM, Andres Vahter wrote:
mov.w R12,R13 ; The operand "input" in
register R12
rla.w R13
add.w R12,R13 ; X1=X*2^1+X
rla.w R13
On 11/10/2010 12:40, JMGross wrote:
> - Ursprüngliche Nachricht - Von: William "Chops"Westfield
> Betreff: Re: [Mspgcc-users] Use of mspgcc* in critical production
> environment
>
>>> The problem is that there are too many new bugs in mspgcc4, so I
>>> cannot switch from mspgcc3 to 4 withou
Hi,
There is a bug in the file python-mspgcc-tools/mspgcc/memory.py - the
Intel Hex file loader can interpret line type 0x02 for extended memory
addressing, but not line type 0x04. Code Composer Studio uses type 0x04
("Extended Linear Address Record") rather than type 0x02 ("Extended
Segment
start of the function
fixes this.
mvh.,
David
On 29/10/2010 14:56, David Brown wrote:
> Hi,
>
> There is a bug in the file python-mspgcc-tools/mspgcc/memory.py - the
> Intel Hex file loader can interpret line type 0x02 for extended memory
> addressing, but not line type 0x04.
Hi,
It's been a while since I've built a cross-gcc, and I haven't yet tried
it with the latest mspgcc4. If I get time, then I too will try it. But
in the meantime, let me make a few general points that might be of
interest or help.
There is no doubt that it is easier to build a cross-gcc usi
On 23/02/2011 13:13, M. Andree wrote:
> Am 22.02.2011 09:40, schrieb David Brown:
>
>> There is no doubt that it is easier to build a cross-gcc using cygwin
>> rather than mingw. This is because cygwin has a very thick interface
>> layer between the programs and the un
On 24/02/2011 15:19, JMGross wrote:
>
>
>
>
> - Ursprüngliche Nachricht - Von: Aaron Spike An: Mike Van
> Emmerik Gesendet am: 23 Feb 2011 16:07:29
>
>> NTFS only sort-of supports hard links - you can use them, but you
>> will quickly confuse other windows programs (including Explorer).
>>
On 06/04/11 17:58, JMGross wrote:
>> Not all "RISC" architectures have all of the above, but simply having
>> a small instruction count just isn't good enough IMO.
>
> On the contrary, that's the only criteria. A small instruction count of
> fast instructions compared to a high instruciton count of
east),
but I am not going to be able to put it together myself from scratch.
regards,
David Brown
Norway
Hi Dmitry,
Thanks for the fast response.
>
> Well, windoze build is a bit outdated, cause recently we have fixed some
bugs
> which might be vital. So, try to build it yourself or ask the community to
build
> a recent snap under win.
Well, so far I've only tried once, and that was on my home Win9
>
> On Thursday, June 20, 2002, at 03:34 AM, David Brown wrote:
>
> > I understood that the jtag interface specification was available, but
> > only
> > under an NDA. Is that correct? Or if not, have you any idea about
> > when you
> > might be expecting
version changes?
David Brown
Norway
nonym...@cvs.mspgcc.sourceforge.net:/cvsroot/mspgcc
co binutils
will download all new files as needed? Or does it just update files that
are already there, in which case it is safest for me to delete the entire
download directory before doing a full rebuild?
Many thanks.
David Brown
Norway
Hi,
(Is this the best way to report small bugs? Or is there a different address
that would be better?)
The include file "msp430\include\msp430x13x.h" is missing a line to include
the adc12 peripheral (i.e., it's missing an #include line).
mvh.
David Brown
Norway
patch
gcc to produce iar assembly rather than gas assembly? Or maybe write a
post-processor that converts gas syntax to iar syntax? I could probably do
this last option myself, someday when I get the time (although probably by
then TI will have finished their jtag spec's and we'll all b
route - does anyone have any other
suggestions?
Thanks,
David Brown
Norway
1 - 100 of 324 matches
Mail list logo
