Using ActiveComPort in other scripting languages

TodWulff · Joined: 01 Mar 2008 Posts: 8

Good day folks.

I am developing an Win32 IDE for a microcontroller.

I am using Notepad++ as the front end. I am currently using AutoHotKey (AHK) to generate the IDE interface as I don't possess enough knowledge to actually write a proper plugin for Notepad++ - that will come later, if I can get things to work properly with my hacka$$ approach.

Anyways, AHK doesn't have native support for serial port connectivity or control. Obviously, that is where ActiveComPort (ACP) could come to the rescue.

One of the requirements for the IO between the development target device and the host PC is that the programming application independently control the DTR and RTS lines, irregardless of the TXD and RXD lines. (i.e. DTR is pulsed low to affect a reset - RTS is pulled low (within 500ms of reset, and held low) to put and keep the target device in a programming mode - so in this case, basically, DTR/RTS are used as Target-Device State Control lines vs. traditional serial flow control).

My questions are:

1) Does the acp dll facilitate independent control of the TXD, RTS, & DTR lines, as well as being able to report the state of RXD, CTS, DSR, DCD, & RI, independently?

2) Has anyone used ActiveComPort with AutoHotKey? i.e. Does anyone know if AHK's dll calling functionality is robust enough to pass control/data to/from the acp dll?

Please review and advise, if able. Thanks, in advance, for your time, consideration, and response.

-Tod Wulff

Leon · Joined: 11 Jul 2007 Posts: 408

Hello Todd,

First of all, on which microcontroller are you working, because the activecomport toolkit can only be used on X86 or X64 platforms.

Best regards,

Leon Steijger
ActiveXperts Software

TodWulff · Joined: 01 Mar 2008 Posts: 8

Hey Leon,

Thanks for your reply.

Maybe I confused the issue a bit... Smile

My host development system is a Win32 box. This is the box in which the ACP tool set would be deployed as part of the IDE.

As info, the target MCUs are ARM based products, but they will just be connected to the host. I am not expecting to run ACP on them... Smile

I hope that this clears this up a bit. If not, please let me know. If so, please advise if I can make use of the IO lines independently.

Thanks!!!

-t

Leon · Joined: 11 Jul 2007 Posts: 408

Hi Todd,

I see, i had a look at the AHK website, and it seems to support COM/ActiveX, so it should be possible to use the ActiveComport component with this software.

Leon

TodWulff · Joined: 01 Mar 2008 Posts: 8

Yes, I concur - I too suspect that it will work because, as you have noted, AHK does indeed support COM (I don't even want to think about trying to muddle my way through ActiveX... Smile

).

I still have a need for confirmation, before I consider investing in the tool, as it related to the capabilities of the ACP dll. Are there calls built in that facilitate the user being able to programmatically control the RTS/DTR outputs independently while data is being transmitted on the TXD, or received on the RXD lines?

The target hooked to the host needs to have DTR toggled to initiate a reset and then, within 500ms of reset, I need to pull RTS low and keep it low while communicating with the target device, in order to program it's flash.

I have tried a number of different tools and most of them, while having options for no handshaking, don't have a path to make use of the hardware signals independently. The ones that do work, for whatever reason, seem to be gawd-awful slow when it comes to the IO - i.e. sending 1 byte @ 19200 takes 15.6ms...

^^^This^^^ is what I am needing to know. Please review and advise. Thanks.

-t

TodWulff · Joined: 01 Mar 2008 Posts: 8

<bump>

Leon · Joined: 11 Jul 2007 Posts: 408

Hello Tod,

I do not know if we can control these lines fast enough to perform data transfer on these lines. The best is to write a simple script to test this. We do not have measuring equipment to check out the maximum speed of these lines

Leon

TodWulff · Joined: 01 Mar 2008 Posts: 8

Understood. I don't think overall speed will be a problem as the target comms only take place at 19200 baud.

I am more interested in determining one simple thing: If there are ACP dll calls that allow the developer to simply control DTR and RTS independently. i.e. In the following code snippet, I can call the dll (currently port.dll) and set DTR and or RTS as needed, and then transmit a string without the dll hijacking the hardware flow control lines when it is called to send a byte:

TodWulff · Joined: 01 Mar 2008 Posts: 8

I just found this.

So I see where I can query and control the RTS/DTR signals independantly...

This leads me to another question - when using software flow control, I presume that the RTS/CTS signal states are not altered during WRITEBYTE or WRITESTRING. Is my presumption correct?

Thanks, Leon, for putting up with my ignorance. It is appreciated.

-t

TodWulff · Joined: 01 Mar 2008 Posts: 8

Things are starting to come together...

[19:11:48] OPEN DEVICE [ActiveComport Build 3.0.7.1212], Device=[COM3], Baudrate=[default], settings=[D,D,D], HWFlowCtrl=[default], SWFlowCtrl=[default], result=[Error #0: Success]
[19:11:48] SET DTR [HI], result=[Error #0: Success]
[19:11:49] SET DTR [LO], result=[Error #0: Success]
[19:11:50] SET DTR [HI], result=[Error #0: Success]
[19:11:50] SET DTR [LO], result=[Error #0: Success]
[19:11:51] CLOSE DEVICE

I find it amusing to step back and realize how much excitement I get from watching a flipping LED turn on & off and realized just how much time it took to get there, and the excitement leaves me almost instantly.

Ya know, some say 'ignorance is bliss.' - I've got only one response for that ... "BS!" I hate wasting my time and the time of others because of my ignorance...

Thanks for the help.

-t

TodWulff · Joined: 01 Mar 2008 Posts: 8

Is there a method or property that will allow a host app to query the object to see if there is data waiting in the receive buffer before trying to receive and having to wait for a timeout in the event that it is empty?

Better yet would be to have a property that will return the # of bytes in the Rx buffer, so that one could poll it to see if anything is in there, and if so, grab the contents or, if needed, wait until a predetermined amount of data is ready to be read by the object's host application...

Please review and advise if this functionality can be programmatically implemented with current constructs, or if it is a good enough suggestion to warrant adding it to the To-Do list.

If said fuctionality is not realizable with today's tool, and it is determined that said functionality will be added, please advise what a reasonable expectation for a new revision's release date should be.

Thank you.

-t