Discussion:
Need help fixing a "previously defined" error
Add Reply
Peabody
2017-04-08 13:07:20 UTC
Reply
Permalink
Raw Message
As will shortly be obvious, I'm completely new to C. I'm trying to
modify and recompile a Texas Instruments program called BSLDEMO2.exe
which is used to flash new firmware to some of their MSP430
microprocessors using a boot-strap loader. I need to invert the DTR line.
They provide the source code, which they compiled using a Microsoft
compiler. I'm using LCC. And this is C, not C++.

Before addressing the change I want to make, I'm just trying to get the
original source to compile in LCC. I'm getting a "previously defined"
error that I don't quite know how to deal with.

The file is TI_TXT_Files.h, and it starts off this way:

---------------------------------------------------------

#ifndef _TI_TXT_Files_H_
#define _TI_TXT_Files_H_

/***********************/
/* Function prototypes */
/***********************/

char* strtrim(char* lpszA);
BOOL GetAddress(char* Record, unsigned long* ulAddress);
BOOL GetBytes(char* Record, BYTE Bytes[], unsigned int* ByteCnt);

long Load_Ti_Txt(LPTSTR File);

//-- StartTITextOutput

--------------------------------------------------------

LCC says "strtrim" is previously defined in the #included <string.h>.

I guess the first question is what that char* line is doing. The second
question is why didn't TI get this error when they compiled it. But
the main question is how to fix it.

LCC's string.h has this:

#ifndef __ANSIC__ONLY__
short * memshort(const short *,short,size_t);
unsigned short *memushort(const unsigned short *,unsigned short,size_t);
int * memint(const int *,int,size_t);
unsigned int *memuint(const unsigned int *,unsigned int,size_t);
long long *memll(const long long *,long long,size_t);
unsigned long long *memull(const unsigned long long *,unsigned long
long,size_t);
char *strupr(char *);
char *strlwr(char *);
char *strnupr(char *,size_t);
char *strnlwr(char *,size_t);
int strtrim(char *); <============= here
char *strrev(char *);
#endif

On the surface there seems to be a conflict between the char* and the int
declarations. But that's probably because I don't understand what's
going on.

There are no other instances of "strtrim" appearing anywhere in the TI
source code.

It seems that the safest way to deal with this might be to make a copy of
string.h with the strtrim declaration commented out, and move it up to
the source code folder, and change all <string.h> #includes to
"string.h". Would that work? Is there a better way?

I would appreciate any suggestions.
James Kuyper
2017-04-08 14:47:55 UTC
Reply
Permalink
Raw Message
Post by Peabody
As will shortly be obvious, I'm completely new to C. I'm trying to
modify and recompile a Texas Instruments program called BSLDEMO2.exe
which is used to flash new firmware to some of their MSP430
microprocessors using a boot-strap loader. I need to invert the DTR line.
They provide the source code, which they compiled using a Microsoft
compiler. I'm using LCC. And this is C, not C++.
Before addressing the change I want to make, I'm just trying to get the
original source to compile in LCC. I'm getting a "previously defined"
error that I don't quite know how to deal with.
...
Post by Peabody
char* strtrim(char* lpszA);
...
Post by Peabody
LCC says "strtrim" is previously defined in the #included <string.h>.
I guess the first question is what that char* line is doing. ...
It declares that strtrim identifies a function that takes one argument
of type char*, and returns a value of type char*. The "lpszA" is purely
decorative as far as C itself is concerned. It uses prefixes that tell
you something about the meaning of the string that it points at, but I'm
not familiar with those prefixes.
Post by Peabody
... The second
question is why didn't TI get this error when they compiled it. ...
Most likely because they used the Microsoft compiler, while you used
LCC. The C standard gives implementations a lot of freedom to differ
from each other, and "strtrim" is one example of that. strtrim() is NOT
part of the C standard library, so this might seem to be a
non-conforming implementation of <string.h>. However, 7.31.13 says that
names beginning with "str", "mem", or "wcs" followed by a lower case
letter may be added to future versions of <string.h>, and according to
7.1.3p1, all such names are therefore reserved for use as identifiers
with external linkage. strtrim matches that pattern. Because such names
are reserved, LCC is entitled to add such names to it's own version of
<stdio.h>, and the TI code has undefined behavior.
"Undefined behavior" means that Microsoft compiler is free to accept
such code and have it execute exactly as expected, but it also means
that LCC is allowed to reject such code.
Post by Peabody
... But
the main question is how to fix it.
#ifndef __ANSIC__ONLY__
...
Post by Peabody
int strtrim(char *); <============= here
...
Post by Peabody
#endif
On the surface there seems to be a conflict between the char* and the int
declarations. ...
That is precisely the conflict that is causing the problem. There are
implementations where char* and int can be successfully type-punned for
each other, but it's not anything you can count on portably. They're not
even remotely compatible types as far as the C standard is concerned.
Post by Peabody
There are no other instances of "strtrim" appearing anywhere in the TI
source code.
The TI code declares strtrim(), but makes no use of it? That's weird,
but unused declarations are not uncommon in code that has a lot of
history. If so, that's trivial to deal with - just remove the declaration.
If you made a mistake while searching for other uses of strtrim,
removing that declaration will help you find them. If you do end up
finding some, the problem gets much more complicated. In that case, let
us know precisely how it is used, and we might be able to suggest a
work-around.
Post by Peabody
It seems that the safest way to deal with this might be to make a copy of
string.h with the strtrim declaration commented out, and move it up to
the source code folder, and change all <string.h> #includes to
"string.h". Would that work? Is there a better way?
Modifying standard headers is job to be done only by experts, and most
experts know enough to not do it. You're much better off changing the TI
code.
Peabody
2017-04-08 17:51:08 UTC
Reply
Permalink
Raw Message
James Kuyper says...
Post by James Kuyper
It declares that strtrim identifies a function that
takes one argument of type char*, and returns a value of
type char*. The "lpszA" is purely decorative as far as C
itself is concerned. It uses prefixes that tell you
something about the meaning of the string that it points
at, but I'm not familiar with those prefixes.
Most likely because they used the Microsoft compiler,
while you used LCC. The C standard gives implementations
a lot of freedom to differ from each other, and
"strtrim" is one example of that. strtrim() is NOT part
of the C standard library, so this might seem to be a
non-conforming implementation of <string.h>. However,
7.31.13 says that names beginning with "str", "mem", or
"wcs" followed by a lower case letter may be added to
future versions of <string.h>, and according to 7.1.3p1,
all such names are therefore reserved for use as
identifiers with external linkage. strtrim matches that
pattern. Because such names are reserved, LCC is
entitled to add such names to it's own version of
<stdio.h>, and the TI code has undefined behavior.
"Undefined behavior" means that Microsoft compiler is
free to accept such code and have it execute exactly as
expected, but it also means that LCC is allowed to
reject such code.
Ok, but what's confusing me is that "StrTrim" is a legit
Microsoft string function, although possibly (only) for C++:

https://msdn.microsoft.com/en-us/library/windows/desktop/bb773454
(v=vs.85).aspx

So is this just a mistake - the wrong case chosen for the
letters - and TI is really trying to call the MS
function to trim a string? But what string would that be?
"lpszA" doesn't appear anywhere else in the source code
either, but I think it also has some kind of special meaning
involving Unicode.
Post by James Kuyper
The TI code declares strtrim(), but makes no use of it?
That's weird, but unused declarations are not uncommon
in code that has a lot of history. If so, that's trivial
to deal with - just remove the declaration. If you made
a mistake while searching for other uses of strtrim,
removing that declaration will help you find them.
I did try that, and the compile worked. But somehow I'm not
comfortable with it not needing to be there. This part of
the code has to do with writing strings to a .txt file where
you would not want trailing spaces or null terminations.
Ben Bacarisse
2017-04-08 19:03:21 UTC
Reply
Permalink
Raw Message
Peabody <***@yahoo.com> writes:
<snip>
Post by Peabody
Ok, but what's confusing me is that "StrTrim" is a legit
https://msdn.microsoft.com/en-us/library/windows/desktop/bb773454
(v=vs.85).aspx
C (and C++) are case-sensitive so that's not the same function at all.
Post by Peabody
So is this just a mistake - the wrong case chosen for the
letters - and TI is really trying to call the MS
function to trim a string?
The code you posted is not calling the function (i.e. using it) it is
merely declaring it -- in this case, telling the compiler what the
arguments types to expect and what type the return value has.

Almost certainly there will be at least other uses of that name. One
will a definition of the function and another will be a call to it. Of
course, there may be many calls but there should be only one definition.
Post by Peabody
But what string would that be?
"lpszA" doesn't appear anywhere else in the source code
either, but I think it also has some kind of special meaning
involving Unicode.
It's fake name. A declaration does not need to name the arguments but
people often put one in to "help out" or sometimes the first line of the
function definition (which does need names) is copied to make the
declaration. One way or another all of these are the same:

char* strtrim(char* lpszA);
char* strtrim(char*);
char* strtrim(char* string);
char* strtrim(char* long_pointer_to_start_of_zero_terminated_ASCII_string);

That last one is a guess at what "lpszA" is suppose to convey to those
who have been initiated (or indoctrinated) into the cabal.

<snip>
--
Ben.
Spiros Bousbouras
2017-04-08 19:06:25 UTC
Reply
Permalink
Raw Message
On Sat, 08 Apr 2017 12:51:08 -0500
Post by Peabody
James Kuyper says...
Post by James Kuyper
It declares that strtrim identifies a function that
takes one argument of type char*, and returns a value of
type char*. The "lpszA" is purely decorative as far as C
itself is concerned. It uses prefixes that tell you
something about the meaning of the string that it points
at, but I'm not familiar with those prefixes.
Most likely because they used the Microsoft compiler,
while you used LCC. The C standard gives implementations
a lot of freedom to differ from each other, and
"strtrim" is one example of that. strtrim() is NOT part
of the C standard library, so this might seem to be a
non-conforming implementation of <string.h>. However,
7.31.13 says that names beginning with "str", "mem", or
"wcs" followed by a lower case letter may be added to
future versions of <string.h>, and according to 7.1.3p1,
all such names are therefore reserved for use as
identifiers with external linkage. strtrim matches that
pattern. Because such names are reserved, LCC is
entitled to add such names to it's own version of
<stdio.h>, and the TI code has undefined behavior.
"Undefined behavior" means that Microsoft compiler is
free to accept such code and have it execute exactly as
expected, but it also means that LCC is allowed to
reject such code.
Ok, but what's confusing me is that "StrTrim" is a legit
https://msdn.microsoft.com/en-us/library/windows/desktop/bb773454
(v=vs.85).aspx
So is this just a mistake - the wrong case chosen for the
letters - and TI is really trying to call the MS
function to trim a string?
From your link in does look like C++ .In any case , C is case sensitive
and StrTrim is a different identifier than strtrim .So the presence of
the strtrim declaration does not affect anything the code might want
to do with a StrTrim function.
Post by Peabody
But what string would that be?
Not enough evidence to even speculate.
Post by Peabody
"lpszA" doesn't appear anywhere else in the source code
either, but I think it also has some kind of special meaning
involving Unicode.
You wouldn't necessarily expect lpszA to appear in the definition
of the function. A declaration
char* strtrim(char* lpszA);
could equally well be written as
char* strtrim(char*);

The definition of the function may be using something other than
lpszA as the name of the passed argument.
Post by Peabody
Post by James Kuyper
The TI code declares strtrim(), but makes no use of it?
That's weird, but unused declarations are not uncommon
in code that has a lot of history. If so, that's trivial
to deal with - just remove the declaration. If you made
a mistake while searching for other uses of strtrim,
removing that declaration will help you find them.
I did try that, and the compile worked. But somehow I'm not
comfortable with it not needing to be there. This part of
the code has to do with writing strings to a .txt file where
you would not want trailing spaces or null terminations.
The code would have to be doing something very weird to accidentally
write NUL bytes when it only tries to write text. As for trailing
spaces , couldn't you just test that part of the code ?
James Kuyper
2017-04-08 19:17:41 UTC
Reply
Permalink
Raw Message
Post by Peabody
James Kuyper says...
Post by James Kuyper
It declares that strtrim identifies a function that
takes one argument of type char*, and returns a value of
type char*. The "lpszA" is purely decorative as far as C
itself is concerned. It uses prefixes that tell you
something about the meaning of the string that it points
at, but I'm not familiar with those prefixes.
Most likely because they used the Microsoft compiler,
while you used LCC. The C standard gives implementations
a lot of freedom to differ from each other, and
"strtrim" is one example of that. strtrim() is NOT part
of the C standard library, so this might seem to be a
non-conforming implementation of <string.h>. However,
7.31.13 says that names beginning with "str", "mem", or
"wcs" followed by a lower case letter may be added to
future versions of <string.h>, and according to 7.1.3p1,
all such names are therefore reserved for use as
identifiers with external linkage. strtrim matches that
pattern. Because such names are reserved, LCC is
entitled to add such names to it's own version of
<stdio.h>, and the TI code has undefined behavior.
"Undefined behavior" means that Microsoft compiler is
free to accept such code and have it execute exactly as
expected, but it also means that LCC is allowed to
reject such code.
Ok, but what's confusing me is that "StrTrim" is a legit
C is case sensitive, so StrTrim is a completely different identfier from
strtrim.
Post by Peabody
https://msdn.microsoft.com/en-us/library/windows/desktop/bb773454
(v=vs.85).aspx
So is this just a mistake - the wrong case chosen for the
letters - and TI is really trying to call the MS
function to trim a string?
That's quite unlikely. It was probably intended to call some other
function named strtrim (and NOT StrTrim) to trim a string. That
particular name is fairly popular.
Post by Peabody
... But what string would that be?
If you found no other occurrences of strtrim() in the code, then it
isn't currently being called for any string. In code that has been
around for a long time, this is not uncommon - there used to be a call
to strtrim(), but it got removed, but the person who removed it forgot
to remove the declaration for strtrm().
Post by Peabody
"lpszA" doesn't appear anywhere else in the source code
As I said, that's purely decorative - it has no meaning that matters as
far as C code is concerned. In particular, it doesn't have to match
anything else (in fact, if if did match a macro name, the results could
be disastrous).
Post by Peabody
either, but I think it also has some kind of special meaning
involving Unicode.
No.
Post by Peabody
Post by James Kuyper
The TI code declares strtrim(), but makes no use of it?
That's weird, but unused declarations are not uncommon
in code that has a lot of history. If so, that's trivial
to deal with - just remove the declaration. If you made
a mistake while searching for other uses of strtrim,
removing that declaration will help you find them.
I did try that, and the compile worked. But somehow I'm not
comfortable with it not needing to be there.
Get comfortable with it when looking at other people's code - there's a
lot of sloppy coding practices out there. Removing all uses of a
declaration, without remembering to remove the declaration itself, is an
unfortunately common occurrence. In your own code you should try to
avoid doing that, but it's pretty much unavoidable in other people's code.
Spiros Bousbouras
2017-04-08 15:29:13 UTC
Reply
Permalink
Raw Message
On Sat, 08 Apr 2017 08:07:20 -0500
Post by Peabody
As will shortly be obvious, I'm completely new to C. I'm trying to
modify and recompile a Texas Instruments program called BSLDEMO2.exe
which is used to flash new firmware to some of their MSP430
microprocessors using a boot-strap loader. I need to invert the DTR line.
They provide the source code, which they compiled using a Microsoft
compiler. I'm using LCC. And this is C, not C++.
Before addressing the change I want to make, I'm just trying to get the
original source to compile in LCC. I'm getting a "previously defined"
error that I don't quite know how to deal with.
---------------------------------------------------------
#ifndef _TI_TXT_Files_H_
#define _TI_TXT_Files_H_
/***********************/
/* Function prototypes */
/***********************/
char* strtrim(char* lpszA);
BOOL GetAddress(char* Record, unsigned long* ulAddress);
BOOL GetBytes(char* Record, BYTE Bytes[], unsigned int* ByteCnt);
long Load_Ti_Txt(LPTSTR File);
//-- StartTITextOutput
--------------------------------------------------------
LCC says "strtrim" is previously defined in the #included <string.h>.
So somewhere in your source there is a line
#include <string.h>

Try putting at some point in the code *before* that line (possibly that point
in the code should be before any other lines of the
form
#include <some-standard-C-header.h>

) the following

#ifndef __ANSIC__ONLY__
#define __ANSIC__ONLY__
#endif
Post by Peabody
I guess the first question is what that char* line is doing. The second
question is why didn't TI get this error when they compiled it. But
the main question is how to fix it.
#ifndef __ANSIC__ONLY__
short * memshort(const short *,short,size_t);
unsigned short *memushort(const unsigned short *,unsigned short,size_t);
int * memint(const int *,int,size_t);
unsigned int *memuint(const unsigned int *,unsigned int,size_t);
long long *memll(const long long *,long long,size_t);
unsigned long long *memull(const unsigned long long *,unsigned long
long,size_t);
char *strupr(char *);
char *strlwr(char *);
char *strnupr(char *,size_t);
char *strnlwr(char *,size_t);
int strtrim(char *); <============= here
char *strrev(char *);
#endif
On the surface there seems to be a conflict between the char* and the int
declarations. But that's probably because I don't understand what's
going on.
No , you understand fine ; that's indeed why you're getting an error message.
Post by Peabody
There are no other instances of "strtrim" appearing anywhere in the TI
source code.
It seems that the safest way to deal with this might be to make a copy of
string.h with the strtrim declaration commented out, and move it up to
the source code folder, and change all <string.h> #includes to
"string.h". Would that work? Is there a better way?
I would appreciate any suggestions.
Barry Schwarz
2017-04-08 16:21:47 UTC
Reply
Permalink
Raw Message
On Sat, 08 Apr 2017 08:07:20 -0500, Peabody
Post by Peabody
As will shortly be obvious, I'm completely new to C. I'm trying to
modify and recompile a Texas Instruments program called BSLDEMO2.exe
which is used to flash new firmware to some of their MSP430
microprocessors using a boot-strap loader. I need to invert the DTR line.
They provide the source code, which they compiled using a Microsoft
compiler. I'm using LCC. And this is C, not C++.
Before addressing the change I want to make, I'm just trying to get the
original source to compile in LCC. I'm getting a "previously defined"
error that I don't quite know how to deal with.
<snip>
Post by Peabody
#ifndef __ANSIC__ONLY__
<snip>
Post by Peabody
#endif
The above conditional compilation is LCC's way of acknowledging that
everything in that block is an extension to the language as defined by
the standard. If you need any of those extensions, then you do not
define the macro __ANSI__ONLY__. If you don't want the LCC
extensions, then you do define that macro.

Since your project was not originally created with LCC, it seems very
likely that you do not need any of LCC's extensions. In that case, it
would make sense to define the macro.

This completely ignores the question of whether the original code
required any Microsoft-unique compiler features. This includes
extensions and compiler eccentricities. For example, the code may
depend on long and int being the same size or size_t being an unsigned
int.

Even if the code uses only standard features, there are additional
potential issues due to the evolution of the standard over the years.
For example, it used to be permitted to omit the return type in a
function declaration and the compiler was required to assume the type
was int. This is now a constraint violation.

The bottom line is merely getting a clean compile should be only the
first step before attempting any modifications. You also need to
verify that the newly compiled program behaves reasonably similar to
the original program.
Post by Peabody
On the surface there seems to be a conflict between the char* and the int
declarations. But that's probably because I don't understand what's
going on.
There are no other instances of "strtrim" appearing anywhere in the TI
source code.
In that case, you should be able to turn the declaration in the TI
header to a comment. This will allow LCC to double check your manual
search. If you missed an occurrence, LCC will issue a diagnostic
because the call statement in the TI source will not match the
prototype in the LCC header. (Or if you define the macro, it will
report the absence of a prototype.)
Post by Peabody
It seems that the safest way to deal with this might be to make a copy of
string.h with the strtrim declaration commented out, and move it up to
the source code folder, and change all <string.h> #includes to
"string.h". Would that work? Is there a better way?
As others have pointed out, changing any part of the compiler, other
than as directed in its user manual, is not something a beginner
should do, or even contemplate. Even simple changes to the TI header
could have unintended consequences.

As Spiros suggested, defining the macro in every source and TI header
file that includes string.h, directly or indirectly, is the safest
approach.
--
Remove del for email
Peabody
2017-04-08 18:04:09 UTC
Reply
Permalink
Raw Message
Barry Schwarz says...
Post by Barry Schwarz
The above conditional compilation is LCC's way of
acknowledging that everything in that block is an
extension to the language as defined by the standard.
If you need any of those extensions, then you do not
define the macro __ANSI__ONLY__. If you don't want the
LCC extensions, then you do define that macro.
Since your project was not originally created with LCC,
it seems very likely that you do not need any of LCC's
extensions. In that case, it would make sense to define
the macro.
This completely ignores the question of whether the
original code required any Microsoft-unique compiler
features. This includes extensions and compiler
eccentricities. For example, the code may depend on
long and int being the same size or size_t being an
unsigned int.
Doesn't it also raise the question of whether just defining
the macro might cause the program to behave differently even
if it successfully compiles? In other words, if TI had
included the macro originally, would the code still work the
way it does? I guess I don't understand whether ANSIC__ONLY
just limits the functions that can be called, or whether it
changes behavior (like long vs int as you described).

Anyway, the idea is that by defining the macro, I can
otherwise leave TI's code the way it is, and leave LCC's
string.h the way it is, but eliminate the error.
Post by Barry Schwarz
Even if the code uses only standard features, there are
additional potential issues due to the evolution of the
standard over the years. For example, it used to be
permitted to omit the return type in a function
declaration and the compiler was required to assume the
type was int. This is now a constraint violation.
The bottom line is merely getting a clean compile should
be only the first step before attempting any
modifications. You also need to verify that the newly
compiled program behaves reasonably similar to the
original program.
The program does lots of different things, and I don't
really have a way to test all of them because I don't have
the chips they apply to. Actually, I don't even understand
all of them. So you're saying that I would have to find the
same version of Visual C that was used originally, which I
don't think I know unless it's in the exe somewhere, to be
sure that it behaves the same.
Post by Barry Schwarz
As Spiros suggested, defining the macro in every source
and TI header file that includes string.h, directly or
indirectly, is the safest approach.
Ok.
James Kuyper
2017-04-08 19:33:07 UTC
Reply
Permalink
Raw Message
Post by Peabody
Barry Schwarz says...
Post by Barry Schwarz
The above conditional compilation is LCC's way of
acknowledging that everything in that block is an
extension to the language as defined by the standard.
If you need any of those extensions, then you do not
define the macro __ANSI__ONLY__. If you don't want the
LCC extensions, then you do define that macro.
...
Post by Peabody
Doesn't it also raise the question of whether just defining
the macro might cause the program to behave differently even
if it successfully compiles?
Yes. That macro has a well-defined meaning for LCC - in principle, it
might have a completely different meaning (or none at all) when using
any other compiler (though with this particular name, it's unlikely to
do something completely different). Therefore, don't #define the macro
unless you first check the LCC documentation to verify what it means.

In general, turning ON C compliance should not be something done in your
code. My experience with other compilers (I have none with LCC itself)
suggests that LCC might automatically #define __ANSI_ONLY__ if you
choose the right command line option, so you don't need to #define it
yourself. Read the documentation for LCC to find out. -ansi is a popular
name for an option that turns on ANSI conformance.
Post by Peabody
... In other words, if TI had
included the macro originally, would the code still work the
way it does?
It's quite likely that TI used a compiler that either didn't pay any
attention to __ANSI_ONLY__, or which automatically pre-#defines it when
appropriate options are selected. Either way, explicitly #defining it
would probably not have had an affect on the compiler they were using.
Post by Peabody
... I guess I don't understand whether ANSIC__ONLY
just limits the functions that can be called, or whether it
changes behavior (like long vs int as you described).
The only way to be sure is to read the LCC documentation. It's not a
general feature of C, it's compiler-specific.
Post by Peabody
Anyway, the idea is that by defining the macro, I can
otherwise leave TI's code the way it is, and leave LCC's
string.h the way it is, but eliminate the error.
That would work, but I recommend removing the spurious declaration
instead. If it isn't actually being used, removing it is harmless. If it
is being used, removing it is a quick and simple way of finding out
where it's being used - doing so will almost certainly trigger an error
message if it is, in fact, being used.

...
Post by Peabody
Post by Barry Schwarz
The bottom line is merely getting a clean compile should
be only the first step before attempting any
modifications. You also need to verify that the newly
compiled program behaves reasonably similar to the
original program.
The program does lots of different things, and I don't
really have a way to test all of them because I don't have
the chips they apply to.
You only need to test the parts you plan to use.
Post by Peabody
... Actually, I don't even understand
all of them. So you're saying that I would have to find the
same version of Visual C that was used originally, which I
don't think I know unless it's in the exe somewhere, to be
sure that it behaves the same.
That would help, if it's easy to arrange. If not, you'll just have to
try it and see whether it works as intended.
Spiros Bousbouras
2017-04-08 19:51:38 UTC
Reply
Permalink
Raw Message
On Sat, 8 Apr 2017 15:33:07 -0400
Post by James Kuyper
Post by Peabody
Anyway, the idea is that by defining the macro, I can
otherwise leave TI's code the way it is, and leave LCC's
string.h the way it is, but eliminate the error.
That would work, but I recommend removing the spurious declaration
instead. If it isn't actually being used, removing it is harmless. If it
is being used, removing it is a quick and simple way of finding out
where it's being used - doing so will almost certainly trigger an error
message if it is, in fact, being used.
Whichever option he chooses , he should add a comment in the code. I've been
meaning to say this and kept forgetting.
Post by James Kuyper
Post by Peabody
The program does lots of different things, and I don't
really have a way to test all of them because I don't have
the chips they apply to.
You only need to test the parts you plan to use.
Post by Peabody
... Actually, I don't even understand
all of them. So you're saying that I would have to find the
same version of Visual C that was used originally, which I
don't think I know unless it's in the exe somewhere, to be
sure that it behaves the same.
That would help, if it's easy to arrange. If not, you'll just have to
try it and see whether it works as intended.
I don't think that relying on a specific version of a specific compiler is
serviceable in the long run. If the code relies on a specific compiler better
to find this out sooner than later.
--
What will the successor of the ipod be called ? Bipod !
Peabody
2017-04-08 21:24:30 UTC
Reply
Permalink
Raw Message
James Kuyper says...
Post by James Kuyper
In general, turning ON C compliance should not be
something done in your code. My experience with other
compilers (I have none with LCC itself) suggests that
LCC might automatically #define __ANSI_ONLY__ if you
choose the right command line option, so you don't need
to #define it yourself. Read the documentation for LCC
to find out. -ansi is a popular name for an option that
turns on ANSI conformance.
In LCC each project has configuration settings that include
the option to use ANSI-C only. I haven't checked that box.
But it might be interesting to see whether the exe differs
in any way if that box is checked or not.
Post by James Kuyper
So you're saying that I would have to find the same
version of Visual C that was used originally, which I
don't think I know unless it's in the exe somewhere, to
be sure that it behaves the same.
That would help, if it's easy to arrange. If not, you'll
just have to try it and see whether it works as
intended.
Since they had no use in LCC, I've ignored four files
included in the TI source code, with these extensions:

.ncb
.opt
.DSP
.dsw

And the .DSP starts with these lines:

# Microsoft Developer Studio Project File - Name="BSLDEMO" - Package
Owner=<4>
# Microsoft Developer Studio Generated Build File, Format Version 6.00

With one exception, all of the source files, including the
ones with the extensions listed above, are dated 2001-2006.
The exception is BSLDEMO.C, which includes the MAIN, and
it's dated 2/6/2013. The exe is also dated that day. But I
think version 6 of Visual Studio goes back to the earlier
period. However, the .DSP file which refers to version 6
was last chnaged in 2006. I guess there's no way to tell
what they actually used to compile the exe ni 2013. I looked
through it with my hex editor, and saw nothing about that.
Keith Thompson
2017-04-09 01:45:56 UTC
Reply
Permalink
Raw Message
Barry Schwarz <***@dqel.com> writes:
[...]
Post by Barry Schwarz
The above conditional compilation is LCC's way of acknowledging that
everything in that block is an extension to the language as defined by
the standard. If you need any of those extensions, then you do not
define the macro __ANSI__ONLY__. If you don't want the LCC
extensions, then you do define that macro.
Since your project was not originally created with LCC, it seems very
likely that you do not need any of LCC's extensions. In that case, it
would make sense to define the macro.
[...]

It's likely that such a macro would be predefined by the compiler in
response to a command-line option, one that causes it to (attempt to)
conform to a particular edition of the C standard. I recall that
lcc-win has a "-ansic" option; I don't know whether its predecessor
LCC has the same option.
--
Keith Thompson (The_Other_Keith) kst-***@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
bartc
2017-04-08 16:46:15 UTC
Reply
Permalink
Raw Message
Post by Peabody
There are no other instances of "strtrim" appearing anywhere in the TI
source code.
It seems that the safest way to deal with this might be to make a copy of
string.h with the strtrim declaration commented out, and move it up to
the source code folder, and change all <string.h> #includes to
"string.h". Would that work? Is there a better way?
I would appreciate any suggestions.
You can try just commenting out the strtrim declaration in TI_TXT_Files.h.

If there is a problem, then it might show up when building the project.

(I downloaded the files for BSLDEMO from github, and making that change
made it compile under lccwin, which is the only compiler where it was a
problem. Other C compilers (excluding one or two such as clang which I
wasn't able to run for technical reasons) didn't care about it.

But I don't know how to build or run the project.)
--
bartc
Peabody
2017-04-08 18:19:52 UTC
Reply
Permalink
Raw Message
bartc says...
Post by bartc
(I downloaded the files for BSLDEMO from github, and
making that change made it compile under lccwin, which
is the only compiler where it was a problem. Other C
compilers (excluding one or two such as clang which I
wasn't able to run for technical reasons) didn't care
about it.
But I don't know how to build or run the project.)
I appreciate your doing that. I think the version on github
was done by FlyingCampDesign for the hardware interface they
sell to do this flashing. And they did exactly what I need
to do, except that they reversed the polarity of both DTR
and RTS, and exchanged their functions. So the same idea,
but no cigar.

It's comforting that it compiled under the other compilers.
As far as the build is concerned, in LCC all I know to do is
click on Make at the top of the Compile tab, and somehow it
miraculously crates a Make and runs it. I would be in deep
doodoo if it didn't do that.

What I'm having trouble dealing with is that unlike the
low-level assembly code I deal with with these
microprocessors, in C, and particularly with different
compilers, there's no way to just compare two versions and
see where they differ. I strongly suspect, for example,
that the changes I want to make could be accomplished by
changing exactly two bytes, or maybe words, in the
original exe. But I have no way to find them. I can easily
find the differences between the TI source code and the FCD
source code. But I can't compare the exe's and do that -
they're not even anywhere near the same size files - maybe
one has the debug stuff, and the other not, or optimization.
Steve Carroll
2017-04-08 19:46:08 UTC
Reply
Permalink
Raw Message
Facts about Steve "Steven Petruzzellis" Carroll

Steve "Steven Petruzzellis" Carroll is a nearly 60 year old guy who is single, broke and has no skills. He blames Snit for his loss of his wife and girlfriend. Steven is jealous of what Snit has and in a narcissistic rage repeatedly works to take it away from him. For over 10 years he has failed at even this. Steve "Steven Petruzzellis" Carroll is an utter failure in life.

Of his online life Steven says

I've been booted off by past providers before because people
complain about me and all my bullshit. I don't want to lose my ISP
*again* but I still need my army of sock puppets so I continually
search usenet for whatever servers I haven't yet been booted
from.

Some examples where Steven has been booted

X10 Hosting booted Steven for inappropriate activity
http://tinyurl.com/z92qmz4

Comcast booted Steven for inappropriate activity
http://tinyurl.com/h75nh9l

FreeHostingEU booted Steven for copyright infringement http://devsite.eu.pn

AwardSpace (atwebpages.com) booted Steven for breaking terms of service
http://demsites.atwebpages.com/pokeman

Imgur took down an image for breaking terms of service http://imgur.com/yv2XppE

Had a GigaNews account which was removed for harassing Snit

Stopped posting from his fretwizzen Google account since shortly after I complained. Seems he lost that too.

His wife booted Steven to the curb for cheating on her



Only site Steven Petruzzellis has pointed to that has ever been available
http://www.oldneighborhoodrestaurant.net
http://tinyurl.com/zgby6mp

Made by the Go Daddy Website builder and is utter crap. Later he denied he said he was merely taking credit for someone else's work but Steven is the contact person http://tinyurl.com/hcw6dul
http://tinyurl.com/hc7ee9q

He also bragged he was working on an update and showed it here https://vid.me/u6RK

The business still failed.

He likely went to the Go Daddy Website Builder after he failed to get WordPress installed.

https://mu.wordpress.org/forums/topic/13879


This is why Steve "Steven Petruzzellis" Carroll attacks Snit.


Steven Petruzzellis was is divorced because his wife caught him screwing another woman.

Snit is married and by all appearances happily so.
He never complains about his wife in COLA.


Steven Petruzzellis is living on charity of a friend in a single room.

Snit does not live in a mansion or even a high end home but has a house and a yard.


Steven Petruzzellis has two kids but no respect. He repeatedly called Ryan his "little screwup" and refers to his son Steve as a "dick" and worse. He says at least one of them likely hacked his computer and is a "mentally deficient child." He mocks his possible future daughter-in-law as someone who takes too many selfies and is focused only on herself

Snit has two kids (or more) and never speaks poorly of them in public.
No reason to think they are not a happy family.


Steven Petruzzellis claims to be a stay at home dad who pays thousands of dollars for day care. Steven has no job and no purpose in life. Steven has given up and now seeks a mother-figure to date.

Snit has his own business doing technical work and also teaches.
Snit offers a true contribution to society.
Teachers are truly under appreciated.

-
E-commerce Simplified
http://www.allabolag.se/bolagslista/eklundh-hans-erik/717ee384c1c4c850ef582dd2daec1976
http://www.5z8.info/nic_cage_naked_y8b5qk_torrentEverything
Jonas Eklundh
Steven Petruzzellis
2017-04-09 05:18:25 UTC
Reply
Permalink
Raw Message
You guys can only think from the perspective of a psychopath. What is your evidence? Sandman lies. Here is a list of names Jonas Eklundh has admitted he attributes to Snit "Cactus Pete", "Donald", "Donald Miller", "Horace McSwain", "Hymen", "Mike Weaver", "Modena IV Drid", "Omar Murad Asfour", "Rhino Plastee", "Soapy", "SopwithCamel", "Sunny Day", "Takuya Saitoh", "The Letter Q", "tmelmosfire", "zevon". Most of those are names of his buddy Steven Petruzzellis. And in response Jeff has nothing but an attempt to start a circus. You just mastered the way Jeff debates!

Proof Steven Petruzzellis is obsessed with Sandman's CSS:


You refuse to take responsibility for your own actions. Actions that are easily quoted and pointed out. I'm getting more posts hidden then show. I'm guessing the Snit nonsense is in its brain damage mode again. Drives the trolls crazy when they do not get attention. So Marek focuses on his ego. The herd does not complain. How Steven Petruzzellis determines when to use his stupid flood script to best emulate the style of Odd Bidkin's posts http://usenet.sandman.net/misc/snit_flood.

-
I Left My Husband & Daughter At Home And THIS happened!
https://www.facebook.com/profile.php?id=100012978552519
http://www.5z8.info/peepshow_z9s9ht_dogporn
Jonas Eklundh Communication
Steven Petruzzellis
2017-04-09 09:35:02 UTC
Reply
Permalink
Raw Message
Facts about Steve "Steven Petruzzellis" Carroll

Steve "Steven Petruzzellis" Carroll is a nearly 60 year old guy who is single, broke and has no skills. He blames Snit for his loss of his wife and girlfriend. Steven is jealous of what Snit has and in a narcissistic rage repeatedly works to take it away from him. For over 10 years he has failed at even this. Steve "Steven Petruzzellis" Carroll is an utter failure in life.

Of his online life Steven says

I've been booted off by past providers before because people
complain about me and all my bullshit. I don't want to lose my ISP
*again* but I still need my army of sock puppets so I continually
search usenet for whatever servers I haven't yet been booted
from.

Some examples where Steven has been booted

X10 Hosting booted Steven for inappropriate activity
http://tinyurl.com/z92qmz4

Comcast booted Steven for inappropriate activity
http://tinyurl.com/h75nh9l

FreeHostingEU booted Steven for copyright infringement http://devsite.eu.pn

AwardSpace (atwebpages.com) booted Steven for breaking terms of service
http://demsites.atwebpages.com/pokeman

Imgur took down an image for breaking terms of service http://imgur.com/yv2XppE

Had a GigaNews account which was removed for harassing Snit

Stopped posting from his fretwizzen Google account since shortly after I complained. Seems he lost that too.

His wife booted Steven to the curb for cheating on her



Only site Steven Petruzzellis has pointed to that has ever been available
http://www.oldneighborhoodrestaurant.net
http://tinyurl.com/zgby6mp

Made by the Go Daddy Website builder and is utter crap. Later he denied he said he was merely taking credit for someone else's work but Steven is the contact person http://tinyurl.com/hcw6dul
http://tinyurl.com/hc7ee9q

He also bragged he was working on an update and showed it here https://vid.me/u6RK

The business still failed.

He likely went to the Go Daddy Website Builder after he failed to get WordPress installed.

https://mu.wordpress.org/forums/topic/13879


This is why Steve "Steven Petruzzellis" Carroll attacks Snit.


Steven Petruzzellis was is divorced because his wife caught him screwing another woman.

Snit is married and by all appearances happily so.
He never complains about his wife in COLA.


Steven Petruzzellis is living on charity of a friend in a single room.

Snit does not live in a mansion or even a high end home but has a house and a yard.


Steven Petruzzellis has two kids but no respect. He repeatedly called Ryan his "little screwup" and refers to his son Steve as a "dick" and worse. He says at least one of them likely hacked his computer and is a "mentally deficient child." He mocks his possible future daughter-in-law as someone who takes too many selfies and is focused only on herself

Snit has two kids (or more) and never speaks poorly of them in public.
No reason to think they are not a happy family.


Steven Petruzzellis claims to be a stay at home dad who pays thousands of dollars for day care. Steven has no job and no purpose in life. Steven has given up and now seeks a mother-figure to date.

Snit has his own business doing technical work and also teaches.
Snit offers a true contribution to society.
Teachers are truly under appreciated.

-
I Left My Husband & Daughter At Home And THIS happened!
http://tinyurl.com/gsleb4p
Jonas Eklundh
David Brown
2017-04-09 10:38:22 UTC
Reply
Permalink
Raw Message
Post by Peabody
As will shortly be obvious, I'm completely new to C. I'm trying to
modify and recompile a Texas Instruments program called BSLDEMO2.exe
which is used to flash new firmware to some of their MSP430
microprocessors using a boot-strap loader. I need to invert the DTR line.
They provide the source code, which they compiled using a Microsoft
compiler. I'm using LCC. And this is C, not C++.
For a completely different solution, you could look at the Python BSD
program. It has been a while since I used it myself, but its immediate
advantages for you over the C code here are:

1. It is in Python, not C, so making a small change is easy. It is far
easier to make a small change in a Python program when you don't know
Python, than a small change in a C program when you don't know C.

2. It already supports inverting the DTR line.

<http://processors.wiki.ti.com/index.php/Open_Source_Projects_-_MSP430#Python_BSL_Module>
Peabody
2017-04-09 12:52:35 UTC
Reply
Permalink
Raw Message
David Brown says...
Post by David Brown
For a completely different solution, you could look at
the Python BSD program. It has been a while since I
used it myself, but its immediate advantages for you
1. It is in Python, not C, so making a small change is
easy. It is far easier to make a small change in a
Python program when you don't know Python, than a small
change in a C program when you don't know C.
2. It already supports inverting the DTR line.
<http://processors.wiki.ti.com/index.php/Open_Source_Pro
jects_-_MSP430#Pytho n_BSL_Module>
Yes, I saw that. But whatever I end up with may be used by
other civilians like me who don't necessarily have Python
installed on their computers. Or Java.

They will have to have a USB-to-Serial driver installed, but
otherwise just the exe.
David Brown
2017-04-09 15:02:06 UTC
Reply
Permalink
Raw Message
Post by Peabody
David Brown says...
Post by David Brown
For a completely different solution, you could look at
the Python BSD program. It has been a while since I
used it myself, but its immediate advantages for you
1. It is in Python, not C, so making a small change is
easy. It is far easier to make a small change in a
Python program when you don't know Python, than a small
change in a C program when you don't know C.
2. It already supports inverting the DTR line.
<http://processors.wiki.ti.com/index.php/Open_Source_Pro
jects_-_MSP430#Pytho n_BSL_Module>
Yes, I saw that. But whatever I end up with may be used by
other civilians like me who don't necessarily have Python
installed on their computers. Or Java.
Java always seems makes life more complicated - people have to have the
right Java versions installed. I don't know why you bring that up here
- there may be Java implementations of the BSL protocol, but Java is not
any easier than C for making quick modifications.

But it's usually a very simple matter to install Python. I don't know
if you are interested only in Windows here, or also Linux - but any
Linux system will have Python already. And if you want to make a
standalone exe file from Python, there are plenty of tools for that.
"py2exe" will combine your Python code with the minimal Python libraries
needed to interpret it. I have used the msp430 BSL Python code along
with my own project-specific Python code, and packaged it up as an exe
file for Windows users - it is typically a couple of MB.

I find C an excellent language for its purpose - and use it extensively
at work (such as for programming msp430 devices). But for a task such
as this, involving reading, parsing and manipulating text files such as
the program files here, a high level language makes life much, much easier.
Post by Peabody
They will have to have a USB-to-Serial driver installed, but
otherwise just the exe.
Peabody
2017-04-09 23:20:46 UTC
Reply
Permalink
Raw Message
David Brown says...
Post by David Brown
I find C an excellent language for its purpose - and use
it extensively at work (such as for programming msp430
devices). But for a task such as this, involving
reading, parsing and manipulating text files such as the
program files here, a high level language makes life
much, much easier.
The problem is that I just told you everything I know about
the Windows API. But Silabs, the maker of the CP2102 that
I'm using, has an excellent app note containing all the
calls needed to deal with COM ports in Windows. And it's
all in C. Without that, I would have been dead in the
water.

So I went looking for a small, hopefully simple, C compiler,
and found LCC. I could essentially copy and paste all the
serial port stuff from the AN, but I had to do the file
handling and flashing stuff myself. It's been like pulling
teeth, and all the problems came from not knowing the
format, grammar and structure of C.

But now I'm going to do what General Westmoreland should
have done in Viet Nam - declare victory and withdraw. The
program is finished, and it works. And I was able to
include parsing of both Intel-Hex and TI-TXT formats, which
took me a good part of today, what with my adventures with
sscanf.

I really appreciate everyone's comments and suggestions
here. I hope I haven't been too much of a pest Now I need
to write up a long-winded PDF about this, then figure out
where to post all of it online, which I'm sure will be yet
another execise in frustration because I just told you
everything I know about Git.

One thing: sscanf does not really work right, at least in
LCC. Well I probably did something wrong, but in the end I
gave up on it and wrote my own ASCII-hex to binary code,
which works perfectly (so long as they don't use lower
case). :-)

The file is 41K, and that's with no debug stuff included. I
didn't optimize. Don't know what that would do, but it's
already plenty fast, and, you know, 41K.
James Kuyper
2017-04-10 02:06:30 UTC
Reply
Permalink
Raw Message
On 04/09/2017 07:20 PM, Peabody wrote:
...
Post by Peabody
One thing: sscanf does not really work right, at least in
LCC. Well I probably did something wrong, ...
That's almost certainly the case. I'm not saying that their
implementation of sscanf() is perfect - it's just that at your current
level of C experience, a mistake on your part is much more likely than a
mistake on the part of the library implementor.
David Brown
2017-04-10 07:07:45 UTC
Reply
Permalink
Raw Message
Post by Peabody
David Brown says...
Post by David Brown
I find C an excellent language for its purpose - and use
it extensively at work (such as for programming msp430
devices). But for a task such as this, involving
reading, parsing and manipulating text files such as the
program files here, a high level language makes life
much, much easier.
The problem is that I just told you everything I know about
the Windows API. But Silabs, the maker of the CP2102 that
I'm using, has an excellent app note containing all the
calls needed to deal with COM ports in Windows. And it's
all in C. Without that, I would have been dead in the
water.
But rather than any of that, you could have used the Python tools as-is.
They support the DTR inversion already.

<https://pypi.python.org/pypi/python-msp430-tools>
<http://pythonhosted.org/python-msp430-tools/>

There is a ready-to-run command line Python script "msp430-bsl" that has
a switch "--invert-reset" to invert the DTR line (used to reset the
msp430 microcontroller, for those that are not familiar with the chip).

<http://pythonhosted.org/python-msp430-tools/commandline_tools.html#msp430-bsl>

The Python code here is written and maintained by Chris Liechti, who has
been developing open source msp430 tools for a decade or so - it is good
quality stuff.
Peabody
2017-04-10 14:11:24 UTC
Reply
Permalink
Raw Message
David Brown says...
Post by David Brown
Post by Peabody
The problem is that I just told you everything I know
about the Windows API. But Silabs, the maker of the
CP2102 that I'm using, has an excellent app note
containing all the calls needed to deal with COM ports
in Windows. And it's all in C. Without that, I would
have been dead in the water.
But rather than any of that, you could have used the
Python tools as-is. They support the DTR inversion
already.
I guess I haven't been clear that there are two programs
involved here. One is TI's BSLDEMO tool that works with the
G2553's embedded BSL code. As far as I know, DTR polarity
is the only problem that needs fixed. That was the one
where I was trying to compile TI's source using LCC so I
could make that change. And for that one, those who do
Python could certainly use Chris Liechti's stuff instead of
BSLDEMO.

But the other thing I wanted to do is provide a program on
the Windows side that implements TI's "custom BSL" for the
G2231, which has no embedded BSL. TI provided a very
primitive BSL for that chip which can be flashed into INFO
memory which isn't used much by anyone. But TI didn't
provide a Windows program comparable to BSLDEMO for the
custom BSL, and the protocol is completely different. I may
have missed it, but I didn't see anything on Chris's site,
or actually anywhere else, related to the custom BSL. Well,
it's not something for which there would be a lot of demand.

With respect to that site, it may be a dumb question, but
can you tell me what the "targeted" files are, as opposed to
the command line files?

The other part of the project is the idea of embedding a
USB-to-serial adapter chip, or a module containing one,
within an MSP430 project, so that flashing firmware updates
would only require a USB cable and some software, but no
Launchpad or USB adapter. But that's all hardware, not C.
David Brown
2017-04-10 15:31:41 UTC
Reply
Permalink
Raw Message
Post by Peabody
David Brown says...
Post by David Brown
Post by Peabody
The problem is that I just told you everything I know
about the Windows API. But Silabs, the maker of the
CP2102 that I'm using, has an excellent app note
containing all the calls needed to deal with COM ports
in Windows. And it's all in C. Without that, I would
have been dead in the water.
But rather than any of that, you could have used the
Python tools as-is. They support the DTR inversion
already.
I guess I haven't been clear that there are two programs
involved here. One is TI's BSLDEMO tool that works with the
G2553's embedded BSL code. As far as I know, DTR polarity
is the only problem that needs fixed. That was the one
where I was trying to compile TI's source using LCC so I
could make that change. And for that one, those who do
Python could certainly use Chris Liechti's stuff instead of
BSLDEMO.
But the other thing I wanted to do is provide a program on
the Windows side that implements TI's "custom BSL" for the
G2231, which has no embedded BSL. TI provided a very
primitive BSL for that chip which can be flashed into INFO
memory which isn't used much by anyone. But TI didn't
provide a Windows program comparable to BSLDEMO for the
custom BSL, and the protocol is completely different. I may
have missed it, but I didn't see anything on Chris's site,
or actually anywhere else, related to the custom BSL. Well,
it's not something for which there would be a lot of demand.
I don't see any references to that device or a mention of a custom BSL.
So I can see why you can't use the Python code directly. And while it
is /much/ easier to write this sort of code with Python than C, adapting
existing C code is going to be less effort than writing new Python code.
Post by Peabody
With respect to that site, it may be a dumb question, but
can you tell me what the "targeted" files are, as opposed to
the command line files?
"Target files" are ones that run on the msp430. I'm not sure what you
mean by "command line files" - that could either be target files
specified on the command line, or the command line programs (python
scripts) themselves.
Post by Peabody
The other part of the project is the idea of embedding a
USB-to-serial adapter chip, or a module containing one,
within an MSP430 project, so that flashing firmware updates
would only require a USB cable and some software, but no
Launchpad or USB adapter. But that's all hardware, not C.
What about using a msp430 F5x/F6x with a USB interface in the chip? I
haven't used these devices myself.

Other than that, I prefer FTDI's USB to serial chips - they are the
nearest thing to a standard that exists there. But as you say, that is
not c - and comp.arch.embedded is probably a better place for
discussions than comp.lang.c.
Peabody
2017-04-10 17:48:19 UTC
Reply
Permalink
Raw Message
David Brown says...
Post by David Brown
I don't see any references to that device or a mention
of a custom BSL. So I can see why you can't use the
Python code directly. And while it is /much/ easier to
write this sort of code with Python than C, adapting
existing C code is going to be less effort than writing
new Python code.
I looked at the BSLDEMO source, and concluded it would
probably take me longer to understand it and extract what
I could use than to begin with the Silabs COM routines and
write the rest myself. I may have been wrong about that.
In any case, I finished the program yesterday, so it doesn't
really matter now if I could have done it an easier way.
Post by David Brown
"Target files" are ones that run on the msp430. I'm not
sure what you mean by "command line files" - that could
either be target files specified on the command line, or
the command line programs (python scripts) themselves.
His site has software divided into two major groups - target
files and command line files. They both look like command
line files to me, with switches and options, and none of
them look like what would be flashed to the chip. It
doesn't matter. I was just curious.
Post by David Brown
What about using a msp430 F5x/F6x with a USB interface
in the chip? I haven't used these devices myself.
I think most hobbyists use the "Value Line" MSP430G chips,
some of which are available in DIP packages. But certainly
there are a large number of models to choose from.
Steven Petruzzellis
2017-04-10 06:38:30 UTC
Reply
Permalink
Raw Message
Having to suffer the use of downloading Scrivener is too much for vallor to deal with.

Not going point by point over this with you, vallor. Everyone uses socks from time to time: We all know Silver Slimer uses different names to defend Trump bragging about sexually assaulting women. For a good time click <http://tinyurl.com/gsleb4p>. My uptime is almost ninety-six days and Rene Lamontagne is a better man than you will even be!

Drinking game: everyone takes a shot whenever someone mentions the term "LCD" but is just whining. Please stop trolling me. The content is a bunch of rambling bullshit we know there are only a few people who do that. GNU is based on Linux. vallor's done a pretty good job with (I am betting) the Baum–Welch method to regurgitate posts which are made to sound like are response from a previous post in the group. You refuse to take responsibility for your own actions. Actions that are easily quoted and pointed out.

My patience is getting just old. You are as dumb as a shoe. Cry harder, vallor!

-
This Trick Gets Women Hot For You

https://www.facebook.com/jenny.eklund
Jonas Eklundh Communication AB
Steven Petruzzellis
2017-04-11 01:45:08 UTC
Reply
Permalink
Raw Message
How Snit screwed up: <http://www.5z8.info/--INITIATE-CREDIT-CARD-XFER--_k7s1jt_inject_worm>. No-one gets it, I ain't done gone got it. Spoken like a typical herd member. Proof of the website skills of Sandman, Jonas Eklundh:
What is your evidence? A hopeless dream, out of my reach. You have no idea how much a fool of yourself you are making.

Spoken like an MSM junkie.

We are not alone: <http://www.5z8.info/dogs-being-eaten_g0w7hf_molotovcocktail>.

Invalid CSS shown on sandman.net
http://youtu.be/5OfWsoPAg7o

<div style="padding: 3px; align: center;">

Same errors noted at the time (proving not from WBM changes):

Message-ID: <C0A30BB5.502C7%***@CABLE0NE.NET.INVALID>
-----
Line: 373
Property align doesn't exist : center
Line: 412
Property align doesn't exist : center
Line: 431
Property align doesn't exist : center
-----

Jonas Eklundh lied. Period.


You guys can only think from the perspective of a sociopath. Cry harder Marek!

Snit's developed an AI system with (I'd guess) the Baum–Welch method to regurgitate posts which are made to sound like are response from a previous post in the group.

--
What Every Entrepreneur Must Know
http://www.5z8.info/php-start_GPS_tracking-user_j3m3lg_whitepower
Jonas Eklundh Communication

Loading...