LDmicro is under semi-active development, but my time is limited. So you can ask, but there's currently no shortage of desirable features to add, probably starting with something like a PIC18 back end.

Hi,
I think the donation thing is great idea I always fell that
Jonathan is giving up to much of his time and getting no help with it. so I will give.
Regards
David

Jonathan!

I know you informed me in a private email about how you feel about the donation story. But, nevertheless, I still stand with the guys in this idea! I therefore pledge, even though the South African Rand is a baby compared to the US$!

My intent is that those would be handled in the same way as on many real PLCs, with specially named variables.

For example, you could decide that X0 to X31 were inputs (corresponding to micro pins, or to pins on some GPIO expander, or to something else entirely). Then when you parsed the .int file generated by LDmicro, the virtual machine would map those bit variables to the physical inputs.

It's likewise possible to define special output bit variables, or special integer variables for stuff like PWM outputs or ADC inputs. Or to make the virtual machine interpret all variable names of the form Pxxx as persistent variables, and save them to EEPROM, or something else.

It would be possible to add a less general mechanism, more similar to the I/O list for the PIC or AVR targets. But this means that LDmicro would have to be customized to the particular bytecode interpreter, which I would like to avoid.

"... you could decide that X0 to X31 were inputs (corresponding to micro pins, or to pins on some GPIO expander, or to something else entirely)..."
It's exactelly what I mean

"...But this means that LDmicro would have to be customized to the particular bytecode interpreter, which I would like to avoid. "
I agree with that and my idea go to this direction : the 'virtual' mcu will abstract the hardware.
The need I have is to map the virtual i/O (ex. : X0 to X31 above) to real mcu pins. When you select a mcu (not Interpretable byte code), you provide to user a way to choose pin assignement (in the table below the shematic view) and you store these information in your .ld file.

The request is to have the same with 'virtual mcu', but instead of producing .hex file, produce a .int file with same code as 'Interpretable byte code', but with adding at the end the 'virtual i/o, integer variable....' mapping, example :

$$bits
Xnew,4,vp7
Xnew2,5,vp3
Xnew3,7,rb3
Xnew4,8,i2c328_1
$$int16s

where vp3,vp7,rb3,i2c328_1 are the 'virtual pins' selected by the user like with real mcu.
With these information, it's easy to build a command-line tool that produce final code for VM without the need of an additonnal file for mapping info. Example : rb3 can be directely mapped to PortB.3 pin of PIC Mcu, i2c328_1 can be mapped to a external IC on i2c bus...

I don't know if it's a problem to change the .ld syntax to :

MICRO=VIRTUAL
IO LIST
Xnew at "vp7"
Xnew2 at "vp3"
Xnew3 at "rb3"
Xnew4 at "i2c328_1"
END

for handling this new feature

Best regards

I am very reluctant to make any changes to the .ld file format, especially just cosmetic ones. There are many thousands of .ld files already in existence with the current syntax, so any change must preserve backwards compatibility. This means that LDmicro would have to read both versions, which adds complexity.

It's already possible to map the I/Os as I describe above. The command-line tool just has to read the .int file, and look at the $$bits and $$int16s sections.

See ldinterpret.c--which supplies the bit 'Xosc' to the program as an input, and reads the int16 'a' from the program as an output--for an example of this.