Lazarus USBasp serial window on demand

[d.ioannidis]

  I am playing with an alternative USBasp firmware ( I didn't write it ), which supports UART communication ( can be used for serial debugging ) ( https://github.com/akrasuski1/usbasp-uart ).

  I wrote a simple client using libusb ( it's a custom HID class ) to connect to it and I can say that it's working great ( linux and Windows 10 )! Now, I was thinking how can I intergrate it to Lazarus and create an Arduino like behavior.

  Something like,  you opened the serial window in Lazarus which will connect to USBasp and then, when you need to upload new firmware it will  disconnect the client ( hook when the project compile ? build ? run ? run without debugging ? all of them ? ), upload the firmware and when the upload is finished reconnect .

  I need to hook the IDE events but I'm not familiar with the code. Any hint, sample project, advice on how to proceed ? ( currently reading https://wiki.freepascal.org/Extending_the_IDE ).

PS: FYI, in my private repo ( https://scm.nephelae.eu/Nephelae/usbasp-uart ) I patched the USBasp firmware to allow programming of AVR chips with 256k also.

[MarkMLl]

Just to try to establish some context: the ASP is one of the programmers for AVR chips, isn't it? Note this page http://irq5.io/2017/07/25/making-usbasp-chinese-clones-usable/ which highlights an incompatibility between the genuine article and the "compatibles" available cheaply from China.

MarkMLl

[ccrause]

One option is to create tool menu items to launch & control the serial monitor.  Not as nice as an IDE integrated tool but it doesn't require much knowledge of Lazarus internals.

Another random thought - can you configure this serial monitor to program the target controller without avrdude?  It would be useful to not rely on an external tool, but would probably require a lot of work to support the very long list of AVR controllers.

[d.ioannidis]

Just to try to establish some context: the ASP is one of the programmers for AVR chips, isn't it?

  Yes. USBasp it's a very cheap ICSP ( In Circuit Serial Programming ) programmer for Atmel / Microchip AVR MCU's from Thomas Fischl ( https://www.fischl.de/usbasp/ ).

Note this page http://irq5.io/2017/07/25/making-usbasp-chinese-clones-usable/ which highlights an incompatibility between the genuine article and the "compatibles" available cheaply from China.

I used 4 different USBasp's bought from AliExpress and Banggood. I didn't had any problem flushing the UART firmware .... so far . Anyway after I read the article they claim that the problem was that the manufacturer read a buggy datasheet and mixed up the USB D- D+ pins of the mcu.

IMO for any clone bought from China, who knows if it 100% compatible or not. Even if the USBasp hardware is a very simple one ( IMO of course ) ...

[MarkMLl]

As a general thought: somewhere I've got partial code to detect a hotplug event raised by the Linux kernel, I used it to recognise when a particular type of enhanced mouse was plugged in.

It might be possible to add a general facility to the IDE:

* If you see /this/ being plugged in you do /that/.

* At startup, if you see /this/ already plugged in you simulate a hotplug event so that /that/ happens.

I don't know what else it would be useful for other than programmers.

MarkMLl

[MarkMLl]

IMO for any clone bought from China, who knows if it 100% compatible or not.

The Chinese certainly don't :-)

MarkMLl

[d.ioannidis]

One option is to create tool menu items to launch & control the serial monitor.  Not as nice as an IDE integrated tool but it doesn't require much knowledge of Lazarus internals.

After reading https://wiki.freepascal.org/Extending_the_IDE I think that all I need to do is to hook to those events, LazarusIDE.AddHandlerOnProjectBuilding, LazarusIDE.AddHandlerOnProjectBuildingFinished.

 ( see: https://wiki.freepascal.org/Extending_the_IDE#Other_IDE_events ).

Currently I'm searching for an example on how to use them ...

Another random thought - can you configure this serial monitor to program the target controller without avrdude?  It would be useful to not rely on an external tool, but would probably require a lot of work to support the very long list of AVR controllers.

I can't think a reason why can't be done. I don't know either how hard can be or how much time is required. Even with the covid-19 outbreak, a programmer simple switches the location ( office -> home ) and continue to work, so no free time ....

My goal at the moment is to do a simple connect / disconnect in accordance with those Lazarus IDE events.

[d.ioannidis]

< snip >

My goal at the moment is to do a simple connect / disconnect in accordance with those Lazarus IDE events.

Update, I manage to find time to implement a proof of concept.

Currently it uses the LazSerialPort as a dependency and disconnects from the com port when the IDE runs ( with or without debugger ) a project and reconnects to the com port when it stop running / debugging a project.

You can find the package in my personal scm https://scm.nephelae.eu/Nephelae/lazserialmonitor.

I surely welcome any feedback on how to proceed .

[MarkMLl]

Currently it uses the LazSerialPort as a dependency and disconnects from the com port when the IDE runs ( with or without debugger ) a project and reconnects to the com port when it stop running / debugging a project.

Does it have to have that external dependency, or could it use FPC's standard serial.pp?

MarkMLl

[d.ioannidis]

Currently it uses the LazSerialPort as a dependency and disconnects from the com port when the IDE runs ( with or without debugger ) a project and reconnects to the com port when it stop running / debugging a project.

Does it have to have that external dependency, or could it use FPC's standard serial.pp?

As its a proof of concept and I'm not familiar with the serial.pp unit, I took the easy way to use something ready .

To answer your question, I don't think why not if the serial.pp its stable enough for the task .

[ccrause]

Currently it uses the LazSerialPort as a dependency and disconnects from the com port when the IDE runs ( with or without debugger ) a project and reconnects to the com port when it stop running / debugging a project.

Does it have to have that external dependency, or could it use FPC's standard serial.pp?

As its a proof of concept and I'm not familiar with the serial.pp unit, I took the easy way to use something ready .

To answer your question, I don't think why not if the serial.pp its stable enough for the task .

serial.pp is definitely stable, I use it for serial communication in my projects.  The disadvantage over elaborate components such as synaser and LazSerialPort is that the programmer needs to decide how to handle the asynchronous nature of the communication.  Either blocking or threaded with events/callbacks etc.

I agree with MarkMLI that it would be better (for the end user) to reduce the dependence on external components.

[MarkMLl]

To answer your question, I don't think why not if the serial.pp its stable enough for the task .

I believe that serial.pp is rock-solid. If I found problems on Linux I'd fix them, since I believe I was the last person to do any maintenance on it.

One change I do want to work on- and I think it might be relevant to what you're doing if you use Linux- is to make sure that when a port is opened it's exclusive and that other programs can't muscle in (that's the default on Windows but not on Linux).

MarkMLl

[MarkMLl]

The disadvantage over elaborate components such as synaser and LazSerialPort is that the programmer needs to decide how to handle the asynchronous nature of the communication.  Either blocking or threaded with events/callbacks etc.

I agree, but that was by intention. When I last worked on it- fixing a number of issues and making sure it worked with Linux, Solaris (on SPARC) and Windows (possibly W2K- it was that long ago) I was looking at some fairly fancy multi-port protocol monitoring stuff and I specifically wanted to have full control of thread management etc.

MarkMLl

[d.ioannidis]

< snip >

I agree with MarkMLI that it would be better (for the end user) to reduce the dependence on external components.

< snip >

I believe that serial.pp is rock-solid. If I found problems on Linux I'd fix them, since I believe I was the last person to do any maintenance on it.

< snip >

Good points, I'll switch to fpc's serial .

regards

[MarkMLl]

Good points, I'll switch to fpc's serial .

It's a very thin wrapper around the OS, particularly in Linux, /except/ for the last couple of functions (which even on unix have to cope with API variations).

I'm watching this thread carefully, so please yell if you have problems.

MarkMLl