That is something serious

It is not that I do not want to use SPI or I2C, but because it is not possible because I only work with PICs.

But keep up the good work, maybe I switch to Atmel if I run out of PICs ;-)

Some think that ldmicro should remain a "black box" in which one draws a ladder and gets a ready made hex file.
It made me think about the future of ldmicro:

On the one hand, it's true that ldmicro should remain a "black box" because most users are not developpers and need a simple software.

But on the other hand, we can wonder about the future for little MCUs like PIC16 and old AVRs ; all the more as Microchip has bought Atmel, so that there is no longer any competition between them !

I personnaly believe - but I may be wrong - that these little MCUs may disappear in a near future, to be replaced for instance by 8 bit ARMs, with much more memory and, why not, format and pin compatibilities with old targets, so that users can replace them in their applications after reprogramming ?

In such a case, I think that ldmicro should evolve towards 2 directions to survive:

1) externalize all MCU definitions, in xml files for instance, to make new definitions easier, and choose target in a dynamic list instead of static one.

2) forget any direct generation of hex files from ladder (too complex and target specific), and compile only via C langage + external libs and external compiler for choosen target. Using flashMCU-like scripts allows to build .hex without exiting from ldmicro, and even to load it into the target with different command line tools.

This way of doing offers more evolutivity without recompiling ldmicro sources, and without depending on developpers.
A few families of MCUs (PIC16, PIC18, AVR, ARM8, ARM32...) and compilers would just have to be supported, the remainder being managed in libraries !

Here's my point of view...
JG

wow, this is a great decision, i think one of the advantages of ldmicro is that it is intuitive for most cases, simply and easy to use but behind that it implies a lot of work for developer, i think that´s why we say "how long will the developer continue updating ldmicro?" i agree that new and more advance mcu´s should be included and also other functions (spi, i2c, etc) for those mcu that ldmicro may include if thinking about future but this is a lot of work doing only via ldmicro, i think the point of José GUILLES is a good one, we would need to make a "how to install" ? something like that and there are some ladder programs that need external programs for using, for example:

http://soapboxautomation.com/products/soapbox-snap/

or:

https://github.com/f1oat/LDuino

but those 2 programas are only for arduino, including FLPROG:

https://flprog.ru/chto-takoe-flprog/

you can use pic, avr and arm stm32 with ldmicro it is such a great program, we could use free compiler from Microship and free program from atmel for calling "flashMcu" but the essence of ldmicro will be lost? i think ldmicro should give a try using external compiler with ldmicro32

Let me wade into this discussion:

My stated preference is for the black box approach which drags everything else with it

I would have no objection to C only output but the solution would need to generate self contained project with all the include libraries within the project folder.

It is not difficult for someone who "speaks" C to read the source code and provide the required libraries or set up the machine to correctly compile to hex but LDmicro is not an environment where knowledge of C is necessarily required,

The advantage of C only approach is it also offers possibility of generating a more optimised hex file.

C only is a possibility but no magic scripts please, let us expose the process of compilation and let source code contain all necessary project files without hidden steps. This means even the makefile.
Let LDmicro cause the user to learn C.

José,

Any development work is welcome I am sure.

But instead of relying on individual's heroism why not start a new project with LDmicro experiences at the heart of it all led by someone who is versed in a particular high level language which would allow a group development effort to take place.

For example defining microprocessor definitions so that people familiar with the particular micro could contribute in that direction.
People familiar with low level programing of the micro could perhaps write libraries as needed.

Make this a bit more of a community effort and not a heroic super human effort it has been to date.

In a roundabout way thank You Jonathan and Ihor.