mxli-3.0 released

[lpcware]

Content originally posted in LPCWare by MarcVonWindscooting on Mon Apr 28 18:17:12 MST 2014
I finally finished a re-write of the open source LPC ISP flash utility mxli. 
At the moment it's Linux only. It supports nearly every LPC microcontroller from built-in tables and should support virtually every (future) LPC ARM microcontroller by command-line definition. mxli is made for the command line and designed specifically for use in scripts.  As an example: you can dump mxli's full device database (in mxli command line syntax) with a one-line shell loop  :bigsmile: :

$ mxli -Q --deviceList | while read d; do mxli --deviceDefinition -Qu"$d" ; done

A comprehensive manual is provided (PDF and Unix man page). Only by reading this manual you can get an idea of the possibilities offered by mxli.
Most testing was performed on LPC4357, LPC176x and LPC81x.

mxli can be found here:
http://www.windscooting.com/softy/mxli.html#Latest

If you compile mxli on any other platform than Linux, I'd like to know. In fact, I expect porting to a new platform to be an effort of half a day. The Linux-specific part of mxli is concentrated into the first 105 lines of code - that's it!

[ashinde555]

I am getting 

bash: mxli: command not found

please help..

[lpcware]

Content originally posted in LPCWare by MarcVonWindscooting on Mon Jul 13 04:52:31 MST 2015
Hi Luca,

mxli-3.0 seems to have problems with hex-images. Try plain bin instead.
I'm using the hex file format very rarely, that's why I don't have much testing of this part.
I'm not very happy with my hex file implementation, to be honest. That was a rush job.

Marc

PS: I know it's time to provide an update, but I'm a very busy guy  0:)

[lpcware]

Content originally posted in LPCWare by lollobrigido on Wed Jul 01 06:48:07 MST 2015
Hi guy, I'm attempting to use the last mxli with a lpc1517.
I get this:

[luca@localhost mxli3]$ ./mxli -c 12 -g -v sc8c.hex
Loading images.
Image=sc8c.hex (bank) offset 0x00000000
Image details:segment 0: addr=0x00000000, size=0x4C80, data=0x00
entryPoint=0x000001B5
Executable32:
  segment: address=0x00000000, size=0x00004C80
Writing image(s).
Segmentation fault (core dumped)


Can help me?
Luca

[lpcware]

Content originally posted in LPCWare by MarcVonWindscooting on Mon Oct 20 10:25:36 MST 2014
Hi Martin,

thanks for the link.

Examples: No, I said it in a misleading way. Not the devices cause the invalid data. My table contained the invalid data!
I mean invalid data I'm responsible for. LPC17 has been my main controller for a while an right within this family I failed to update the device data correctly, after adding new features :(

It seems to become increasingly difficult to support all the devices because of their number and differences in protocol and speeds....
Some work fine without echo, some work fine only with echo turned on (LPC21xx IIRC). And I wished, NXP could just use \r or \n as a
separator ALWAYS...  ;-)

Marc

[lpcware]

Content originally posted in LPCWare by capiman on Thu Oct 16 23:19:16 MST 2014
What do you mean by "caused by invalid data of some devices"? Can you give examples?

Have you seen this one?
http://www.lpcware.com/content/forum/lpc11u67-isp-serial

[lpcware]

Content originally posted in LPCWare by MarcVonWindscooting on Thu Oct 16 19:59:50 MST 2014
I finally made available an update of the program.
It should now support LPC1500 from the internal table and the 'floating point exception'-bug fixed (caused by invalid data of some devices).

Has anyone used it on LPC1500 or any other 'unsupported' device so far? I mean: is there a human on this planet, who ever used mxli's command-line device definition feature (besides myself)??  ;-) 

[lpcware]

Content originally posted in LPCWare by MarcVonWindscooting on Wed Jun 25 07:04:46 MST 2014

---

Quote: Pacman

You can also divide sizeof by sizeof...

#define ARRAY_SIZE(a) ((sizeof((a)) / sizeof((a)[0])))

---

I don't like macros, but this is definitely one of the few exceptions  :bigsmile: , see 'macros.h' (ELEMENTS). There's no replacement for it!
However, I'm sloppy about the parentheses, partly because I suggest to use it on top-level arrays only.

Today, I'm tempted to remove even more of the remaining #defines in that header, because inline static functions can replace most of them. In a little less generic way, though.

[lpcware]

Content originally posted in LPCWare by Pacman on Sat Jun 21 10:09:39 MST 2014

---

Quote:  MarcVonWindscooting
I could/should have used a union instead, maybe.

---

I second that. I've done this myself, when I had an address-pointer in a structure...

typedef struct MyStruct MyStruct;
struct MyStruct
{
    union{
        void *address;
        uint8_t *address8;
        uint16_t *address16;
        uint16_t *address32;
    };
    uint32_t length;
    ... other stuff ...
};

It's been very handy, because if you have a screen address, you don't always know if the pixels are 8-bit, 16-bit or 32-bit. So setting the address, you'd just use myPointer->address = 0xa0000000;
But if you have a specific routine, that sets a 16-bit pixel, you'd read myPointer->address16;

---

Quote:
There is very, very little code dependend on the pointer size.

---

I expected that.

---

Quote:
I wonder, what that guy had been thinking at that time.

---

...You're not alone; when I look back on my old code, I too feel my better knowledge.

Remember that you can always subtract two pointers. Pointer - Pointer = integer.
You can also divide sizeof by sizeof...

#define ARRAY_SIZE(a) ((sizeof((a)) / sizeof((a)[0])))

...I hope I placed the parantheses correctly. The above should give you the number of elements in an array; no matter what type of array it is; eg. an array of any kind of structure can be used as well.

[lpcware]

Content originally posted in LPCWare by MarcVonWindscooting on Sat Jun 21 03:41:55 MST 2014

---

Quote: Pacman

-What I meant was the code that relies on it.

My guess is that you would need the pointer size, because you need to convert a pointer to an integer or an integer to a pointer.
...

---

Recently I try to avoid casting between pointers and integers. Especially strict aliasing awareness changed my way of dealing with pointers. Nowadays I prefer that 'array access' style. Or else the 'pointer+index' (or ++), with index not beeing byte offset but rather an element count.

IIRC the very origin of the code was the wish to display some pointer values for debugging, which involved passing a suitable integer type to a hexadecimal output function. Casting to Uint32 wasn't suitable any more on my first 64bit machine.
Another part is seqio.h - the abstract workhorse for my I2C drivers. There, I needed some integer type that can hold data but sometimes a pointer instead. I could/should have used a union instead, maybe.
There is very, very little code dependend on the pointer size.

Some parts of the library are rather old (6+ years) and sometimes I wonder, what that guy (me, really ??? :~ ) had been thinking at that time....

But for one thing, I stick to single byte calculation: Initialization of buffer size fields of structures. I mean, if I will ever implement a (object-oriented like) Stack of 8-byte pointers in C, then the initialization will most probably set the allocated buffer size measured in bytes, not as the total number of pointers. Just because passing 'sizeof buffer' is so handy  :)

[lpcware]

Content originally posted in LPCWare by Pacman on Fri Jun 20 13:58:15 MST 2014
I'm sorry for not being clear.
-What I meant was the code that relies on it.

My guess is that you would need the pointer size, because you need to convert a pointer to an integer or an integer to a pointer.
For instance, imagining that you have a uint32_t * that needs to have the value distance added.
A few years ago, I would typecast it to a uint32_t and then add the value, and typecast it back to uint32_t *:

    uint32_t temp;
    uint32_t *p;

    temp = (uint32_t) p;
    temp += distance;
    p = (uint32_t *) temp;

...But I never do that anymore. Instead, if really necessary, I would typecast it to a uint8_t *...

    p = (uint32_t *) &((uint8_t *)p)[distance];

(Ignoring any alignment problems completely in this post).

[lpcware]

Content originally posted in LPCWare by MarcVonWindscooting on Fri Jun 20 11:36:07 MST 2014
I used the __SIZEOF_POINTER because to me, that's only a piece of text that happens to look like a number. That fits better to the preprocessor's text/symbol-oriented functionality. sizeof(void*) on the other hand is something the C compiler knows, not the preprocessor and it's really a number.
I use __SIZEOF_POINTER at 'preprocessing time' for conditional #define .

[lpcware]

Content originally posted in LPCWare by Pacman on Mon Jun 16 07:31:13 MST 2014
Ah, that's why. Thank you for the information on that. :)
Too bad that I can't just switch to 4.3 (gcc-4.2 is Apple-modified and integrated with distributed builds, etc.)

Making things portable can be painful.
Yesterday I had to modify my Makefile (for LPC1788), so that it would be possible to build on a Windows platform. In short: I just had to translate slashes to backslashes. Turned out after a couple of hours, that it would build without errors, but... the startup code and the entire program was missing (I only got a warning that Reset_Handler wasn't found). [Oh, and to make matters worse, I don't have Windows myself; I have to ask a fellow to do the builds].

I don't know why you need the __SIZEOF_POINTER__, perhaps it's for va_arg somewhere ?
Sometimes I typecast between pointers and integers, but after a while, I find a better solution and can clean up any typecasts.

[lpcware]

Content originally posted in LPCWare by MarcVonWindscooting on Mon Jun 16 05:43:40 MST 2014
Pity! I should have used something more backward compatible for this test. I clearly remember, the conditional and the Int/Uint types were a quick-hack, when first porting to a 64-bit system. I should clean that mess up, soon.

'startpage.com' revealed, __SIZEOF_POINTER__ was introduced in gcc-4.3  :O

[lpcware]

Content originally posted in LPCWare by Pacman on Sat Jun 14 11:06:23 MST 2014
Thanks for the post.
I just tried to see if it would build out-of-the-box on a PPC Mac.

Unfortunately I got this error:

  ../c-any/integers.h:48:2: error: #error "Invalid pointer size in the author's opinion."

I know that the size of a pointer on a PPC Mac is 32-bit (4 bytes).
It seems that '__SIZEOF_POINTER__' is not set by my gcc; perhaps it's a post gcc-4.2 feature ?