Prox / RFID
Ladder Logic
[interfacing] †
Tube Joints
Key Code From Photo
SolveSpace (3d CAD)
SketchFlat (2d CAD)
Resume / Consulting
Contact Me

LDmicro Forum - New versions of LDmicro

(you are viewing a thread; or go back to list of threads)

New versions of LDmicro (by MGP)
We have a big problem, LD files are being posted that can not be opened by the latest version of LDmicro, for the moment that is still V4430.

This is the latest version where all instructions apply to all controllers in the menu.

Perhaps it is time to think about how we are going to handle that... a new name or extension of these new versions.

Something to think about.
Mon Jan 7 2019, 02:26:10
(no subject) (by Alex)
That is something serious
Mon Jan 7 2019, 02:36:49
(no subject) (by JosÚ GILLES)
Don't worry !

You can't open these ld files with 4.4.3 version because they include new functions (I2C or SPI) not supported.
Thats the only pb and it's normal !
In ldmicro32, I have made things in such a way not to disturb - as far as I know - previous behaviour of ldmicro with existing functions and targets.

But why would you like to open these files, as you don't want to use I2C or SPI ?
If you really want to have a look, try ldmicro32 or open ld file in a text editor. If you remove manually the I2C / SPI lines in error you'll be able to open the remainder of the file as usual with your 4.4.3 version.

That's not a file format pb but a function pb...
Mon Jan 7 2019, 09:29:50
(no subject) (by MGP)
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 ;-)
Mon Jan 7 2019, 13:06:34
(no subject) (by Alex)
unless we have 18f :)
Mon Jan 7 2019, 13:27:23
What future for ldmicro ? (by JosÚ GILLES)

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...
Wed Jan 9 2019, 02:58:48
(no subject) (by MGP)
I think LDmicro owes its popularity to its black box structure.

The biggest fear is always, how long will the developer continue updating LDmicro, usually that is one person who is committed to it and I know it is a huge amount of work.

As you can see now, Ihor, who did a very good job, has dropped out with a version V4430 with a not so nice 'termination bug'.

I agree that we have to switch to newer processors, but in many countries these are difficult or impossible to get and I think that there are many users of LDmicro in those countries.

Therefore, I would also suggest to use a new name such as LDmicro32 or delete the controllers in the menu that are not supported, or ... I dont know ..

For the time being I stay with the PICs because my stock is still large including PCB's for them.

But continue your work you did already a very good job.
Wed Jan 9 2019, 06:52:48
(no subject) (by Alex)
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:




but those 2 programas are only for arduino, including 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
Wed Jan 9 2019, 09:28:41
(no subject) (by Alex)
i think old mcus should be kept as MGP said there are a lot of countries where old pic and avr are still used, such as mine, and worst here we can use only pic(they are very cheap btw), there is no other atmel mcu than arduino popular boards
Wed Jan 9 2019, 09:34:13
(no subject) (by Ziggy)
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.
Wed Jan 9 2019, 11:06:45
(no subject) (by JosÚ GILLES)

I can see that my point of view aroused many reactions !

If ever I haven't been clear enough, I dont intend to be THE
ldmicro developper who will make all these transforms...
It's just a suggestion for the actual developpers ; but who are these developpers ?
Jonathan Westhues created the software, Ihor Nehrutsa make a lot to bring it from 2.3 to 4.4 version, but seems now to be far away from the forum.

Its difficult to work on ldmicro sources because there are many lines of code, not really optimized - should have been written in true C++ with object. The most difficult parts are pic.cpp, avr.cpp, with made to mesure coding for different targets, intcode.cpp, and ansi.cpp for C generation.

By externalizing many things, it would be easier to find developpers to create new targets and/or adapt existing libraries of the same MCU family, without needing to assimilate all the source code.

For my part, I'll probably try to make I2C and SPI available for some PIcs via C, so that everybody can use it and see the advantages of externalizing.

I didn't say that little and old targets should be removed one day ; with a dynamic list or submenus, its possible to keep all the targets and add new ones.

Best regards
Wed Jan 9 2019, 14:00:17
(no subject) (by Ziggy)

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.
Wed Jan 9 2019, 17:50:00
Post a reply to this comment:
Your Name:
Your Email:
(no HTML tags; use plain text, and hit Enter for a line break)
Attached file (if you want, 5 MB max):