Serial Port Downloads to 41CL

[rprosperi]

Can anyone describe and recommend a reliable process for downloading images to a 41CL via serial port?

I have tried using CLWRITER from the 41CL Software page (compiled by Mark Hardman here) without success, running on Win-7 x64. The program runs fine (no crashing, display is as expected, etc.) but seems to not actually be sending bytes out the port. My PC has real COM1 and COM2 ports, COM1 is in use.

I get the PC command line ready (in a CMD session with Administrative rights) with "clwriter filename com2 4800 5" to send filename out on com2 at 4800 baud with a 5 ms inter-character delay. I have varied the delay to no effect.

On the 41CL, I XEQ "DLD48" from the PowerCL module, give it "80D" to specify target address of 80D000, and the 41CL waits for data. (Note: I have also used the equivalent manual CL commands SERINI BAUD48 TURBO50 "80D000-0FFF" YIMP with the same (lack of) results).

I then press Enter on the PC to launch CLWRITER and the PC display begins displaying the bytes being "sent" out the com2 port.

But after 5-10 seconds, the 41CL reports TIMEOUT, seemingly never receiving data.

If I run DLD48 without launching anything on the PC, it times out in the same timeframe as if I do so, hence my conclusion nothing was received.

Can anyone recommend a process to make this work on Win7 x64, or recommend an alternate method to download?

[Sylvain Cote]

Hello Robert,
Did you tried the clio python script from Bernd Grubert here.
The program indicate Linux, OSX & Windows support.
It need Python 2.7.X available here.
Sylvain

[Sylvain Cote]

(02-24-2015 02:08 AM)Geir Isene Wrote:  Or you can use my pc41 program (Ruby):

Sorry Geir for not mentioning your program, I was under the impression that it was not compatible with Windows.
Sylvain

[rprosperi]

(02-24-2015 01:16 AM)Sylvain Cote Wrote:  Hello Robert,
Did you tried the clio python script from Bernd Grubert here.
The program indicate Linux, OSX & Windows support.
It need Python 2.7.X available here.
Sylvain

I saw this but thought this was a Linux only solution, but I will give it a try as looking at the script now, I see it does indeed reference use on windows. I've never user Python, but the usage indicated in the script implies it's pretty simple.

Thanks for pointing this out.

[rprosperi]

(02-24-2015 02:08 AM)Geir Isene Wrote:  Or you can use my pc41 program (Ruby):

http://isene.me/hp-41/pc41/

Geir - I did look into this, but right in the program code it says "...to facilitate
connection between an HP-41 and a PC running Linux/Unix/Mac OSX." with no mention of Windows.

Does this work as-is under Win-7 x64?

[Frido Bohn]

Hi Robert,

What do you mean by?

(02-24-2015 12:04 AM)rprosperi Wrote:  COM1 is in use.

COM1 is in use for another application than the serial connection to the 41CL I hope, otherwise addressing COM2 in the manual command you wrote wouldn't make sense.

I use the CLWRITER/CLREADER pair in Win7 and got it working, even without the inter-char delay option. Possible problems may come from the COM port settings in Win7 hardware settings, accessible e.g. via the "device manager". Just check the settings there and adjust them to the CLWRITER commands.
Have you tried the other way with CLREADER? May be worthwhile to look if sending of data to the PC works. You can also use a terminal program and check if it receives any signal from the 41CL.
Eventually, you may check whether there are some hardware issues, for example to look at the wiring of the 41CL. Does the COM port in the PC work at all?

Just a few ideas.
Cheers
Frido

[rprosperi]

(02-24-2015 09:18 AM)Frido Bohn Wrote:  Hi Robert,

What do you mean by?

(02-24-2015 12:04 AM)rprosperi Wrote:  COM1 is in use.

COM1 is in use for another application than the serial connection to the 41CL I hope, otherwise addressing COM2 in the manual command you wrote wouldn't make sense.

I use the CLWRITER/CLREADER pair in Win7 and got it working, even without the inter-char delay option. Possible problems may come from the COM port settings in Win7 hardware settings, accessible e.g. via the "device manager". Just check the settings there and adjust them to the CLWRITER commands.
Have you tried the other way with CLREADER? May be worthwhile to look if sending of data to the PC works. You can also use a terminal program and check if it receives any signal from the 41CL.
Eventually, you may check whether there are some hardware issues, for example to look at the wiring of the 41CL. Does the COM port in the PC work at all?

Just a few ideas.
Cheers
Frido

Thanks for the comments and suggestions Frido.

COM1 is already in use connected to my UPS, so I'm using COM2 for 41CL. COM2 is known to work OK.

Are you using 64-bit windows? If so, could you email me the 2 programs?

I did set Baud rate to 4800 in Device Manager. I assumed N-8-1 as well.

I will try uploading a file, an obvious and simple step I missed.

After that if the Python program doesn't work, a terminal program is next.

Thanks!

[rprosperi]

(02-24-2015 01:24 PM)Geir Isene Wrote:  Actually, I have no idea. But I could hope for someone with access to a Windows computer to try the program :-)

Thanks for replying. No disrespect, but with all the existing unknowns, I don't want to also add installing/learning Ruby and your script into the mix, at least until I have verified all the h/w is indeed working OK. Thanks though.

[rwiker]

(02-24-2015 02:30 PM)rprosperi Wrote:  

(02-24-2015 09:18 AM)Frido Bohn Wrote:  Hi Robert,

What do you mean by?

COM1 is in use for another application than the serial connection to the 41CL I hope, otherwise addressing COM2 in the manual command you wrote wouldn't make sense.

I use the CLWRITER/CLREADER pair in Win7 and got it working, even without the inter-char delay option. Possible problems may come from the COM port settings in Win7 hardware settings, accessible e.g. via the "device manager". Just check the settings there and adjust them to the CLWRITER commands.
Have you tried the other way with CLREADER? May be worthwhile to look if sending of data to the PC works. You can also use a terminal program and check if it receives any signal from the 41CL.
Eventually, you may check whether there are some hardware issues, for example to look at the wiring of the 41CL. Does the COM port in the PC work at all?

Just a few ideas.
Cheers
Frido

Thanks for the comments and suggestions Frido.

COM1 is already in use connected to my UPS, so I'm using COM2 for 41CL. COM2 is known to work OK.

Are you using 64-bit windows? If so, could you email me the 2 programs?

I did set Baud rate to 4800 in Device Manager. I assumed N-8-1 as well.

I will try uploading a file, an obvious and simple step I missed.

After that if the Python program doesn't work, a terminal program is next.

Thanks!

Are you sure that the cable and internal connections are working as they should?

It should not be necessary to do any setup in Device Manager, as CLWriter/CLReader both set up the serial port with 8 bits, no parity, 1 stop bit and no hardware handshaking.

You should also be able to compile the programs yourself – if you have the .NET runtime installed, the C# compiler should also be available. (That's one of the reasons that these two small programs are published as source; the other is that source code distributions are a bit safer than binary distributions – at least for trivial code like this.)

[rprosperi]

(02-24-2015 09:11 PM)rwiker Wrote:  

(02-24-2015 02:30 PM)rprosperi Wrote:  Thanks for the comments and suggestions Frido.

COM1 is already in use connected to my UPS, so I'm using COM2 for 41CL. COM2 is known to work OK.

Are you using 64-bit windows? If so, could you email me the 2 programs?

I did set Baud rate to 4800 in Device Manager. I assumed N-8-1 as well.

I will try uploading a file, an obvious and simple step I missed.

After that if the Python program doesn't work, a terminal program is next.

Thanks!

Are you sure that the cable and internal connections are working as they should?

It should not be necessary to do any setup in Device Manager, as CLWriter/CLReader both set up the serial port with 8 bits, no parity, 1 stop bit and no hardware handshaking.

You should also be able to compile the programs yourself – if you have the .NET runtime installed, the C# compiler should also be available. (That's one of the reasons that these two small programs are published as source; the other is that source code distributions are a bit safer than binary distributions – at least for trivial code like this.)

Thank you for these insights Ray. I had no idea the .NET runtime included the C# compiler! I was wondering why such a useful contribution would be in source only, so the joke's on me for not knowing this. Another member is sending them as well in .exe format but I will try this as well.

I am not 100% sure of the hardware. I think it's all OK as it assembled easily w/o any issues, but until I get a absolutely known good config to not work, it's impossible to blame h/w vs s/w, etc. This is why I've been asking if your programs are known to work on 64-bit Win-7 (it's amazing how many folks are still running XP here...), and seems like the answer is yes.

I will test this tonite.

It also appears the posted version of the programs handles the byte-swapping needed as noted in one of Angels manuals. I guess this is an improved version

Note: as all the other serial transfer solutions on the CL File Area web-page are source only (mostly scripts for other runtimes) I assumed there was some unstated reason for not posting binaries. Maybe ask Monte to add a note clarifying the runtime includes the compiler and anyone can simply use the commands as stated. Sometimes, we over-think the simple things...

Thank you!

[rprosperi]

(02-24-2015 09:49 PM)rprosperi Wrote:  I will test this tonite.

Well, no joy.

Built the 2 programs without any issues, verified COM2 settings, but still no evidence of any communication up or down.

So, looks like it is h/w after all. Bummer. And I was so happy with how well the installation surgery went, no cracked posts, etc. and the serial cable seemed to go in so easily. Hrmph!

Although not resolved, as usual I learned a bunch in the process of trying. Will report some good news once resolved.

Thanks to all that offered comments, files, insights and suggestions!

[Monte Dalrymple]

It IS possible to check the CL serial port hardware with a V4 board, but it requires some care. You just need to create a loopback connection. At the DB9 end of the serial cable somehow connect the RX signal to the TX signal. A piece of wire might work, but you'll get a better connection if you have a gender-changer so that you can connect to pins directly. Set the baud rate (any will do) and enable the serial port (this is the step that requires a V4 board) using the SERON function in YFNX. Then if you YPOKE a byte directly to the transmit buffer the byte will be transmitted. Then you just need to YPEEK the serial port status register to verify that the tx buffer is empty and the rx buffer is full. Then YPEEK the receive buffer to check that the byte arrived. You'll need to look at the NEWT manual to find the addresses of the serial port registers, and the YPEEK/YPOKE description in the manual to see the proper formatting for a peripheral address. This is how I first tested the serial port, although I had to use an external power supply to transiently force a valid RS232 level on the wire to enable the serial port.

[Sylvain Cote]

For serial port diagnostic I normally use a break out box like the one here.
The led's on the box allow you to see if there is a communication (RX & TX) going on and if the handshaking lines (RTS/CTS, etc) are working as expected.
In the case of the 41CL only the RX & TX lines are mapped.
Sylvain

[rwiker]

(02-24-2015 11:36 PM)rprosperi Wrote:  

(02-24-2015 09:49 PM)rprosperi Wrote:  I will test this tonite.

Well, no joy.

Built the 2 programs without any issues, verified COM2 settings, but still no evidence of any communication up or down.

So, looks like it is h/w after all. Bummer. And I was so happy with how well the installation surgery went, no cracked posts, etc. and the serial cable seemed to go in so easily. Hrmph!

Although not resolved, as usual I learned a bunch in the process of trying. Will report some good news once resolved.

Thanks to all that offered comments, files, insights and suggestions!

It may also be the cable itself... if you have a multimeter, you should be able to check the cable (check that there are no shorts between the rings on the minijack, and that the signals from the minijack appears at the expected pins on the DB9 end).

[rprosperi]

(02-25-2015 05:40 AM)rwiker Wrote:  It may also be the cable itself... if you have a multimeter, you should be able to check the cable (check that there are no shorts between the rings on the minijack, and that the signals from the minijack appears at the expected pins on the DB9 end).

This is simple enough and a good idea; I found the section at the back of the CL manual late last night on the serial cable and had the same thought, though for a manufactured cable one wouldn't expect this type of problem. While I hope it's not this, I hope it is this, if you know what I mean.

I'm not sure I have the intestinal fortitude for Monte's suggestion, my going-in postition was to never need to look into the Newt manual , but upon re-reading his suggestion today it looks simpler than it did last night.

Thank you again.

[rwiker]

(02-25-2015 02:07 PM)rprosperi Wrote:  

(02-25-2015 05:40 AM)rwiker Wrote:  It may also be the cable itself... if you have a multimeter, you should be able to check the cable (check that there are no shorts between the rings on the minijack, and that the signals from the minijack appears at the expected pins on the DB9 end).

This is simple enough and a good idea; I found the section at the back of the CL manual late last night on the serial cable and had the same thought, though for a manufactured cable one wouldn't expect this type of problem. While I hope it's not this, I hope it is this, if you know what I mean.

Could it be that the cable you have is simply wrong for connecting the HP41CL to a PC-style RS232 port? I'm pretty sure I've heard of cables that that appear identical to the one that works for the HP41CL, but has different internal connections.

Back in 2011, one of the early HP41CL owners had problems that may have been caused by the cable (which was also a manufactured cable); I'm not sure if buying a new cable solved his problems.

[rprosperi]

(02-25-2015 08:47 PM)rwiker Wrote:  

(02-25-2015 02:07 PM)rprosperi Wrote:  This is simple enough and a good idea; I found the section at the back of the CL manual late last night on the serial cable and had the same thought, though for a manufactured cable one wouldn't expect this type of problem. While I hope it's not this, I hope it is this, if you know what I mean.

Could it be that the cable you have is simply wrong for connecting the HP41CL to a PC-style RS232 port? I'm pretty sure I've heard of cables that that appear identical to the one that works for the HP41CL, but has different internal connections.

Back in 2011, one of the early HP41CL owners had problems that may have been caused by the cable (which was also a manufactured cable); I'm not sure if buying a new cable solved his problems.

The cable I'm using came from Monte, so it's the correct configuration. I just tested it with a multi-meter and it's OK, no shorts and Tip, Mid and Ring all connect to the appropriate DB9 pins.

I'm pretty convinced I must have damaged the wiring on the internal serial connector during assembly, but I'm plowing through all the other possibilities, testing, etc. because I'm learning a lot in the process. Once it's history, it will seem like it was fun, but right now, not so much

Thanks for your suggestions and comments.

[Michael Fehlhammer]

Hi Bob,
I encountered a similar problem with the serial interface of one of my CLs;
the cause was simple:

From the CL manual:
14. Carefully plug the connector on the cable into the connector jack on the 41CL circuit
board with the “CP” label next to it. This is the programming connector for the CPLD.
The connector used is very fragile and was not really designed for multiple insertions,
so take your time, but make sure the plug is fully seated in the connector on the 41CL
circuit board.

In my case the plug was not fully seated, although this wasn't obvious at all.
I suggest you check that.

[rprosperi]

(02-26-2015 01:14 AM)Michael Fehlhammer Wrote:  Hi Bob,
I encountered a similar problem with the serial interface of one of my CLs;
the cause was simple:

From the CL manual:
14. Carefully plug the connector on the cable into the connector jack on the 41CL circuit
board with the “CP” label next to it. This is the programming connector for the CPLD.
The connector used is very fragile and was not really designed for multiple insertions,
so take your time, but make sure the plug is fully seated in the connector on the 41CL
circuit board.

In my case the plug was not fully seated, although this wasn't obvious at all.
I suggest you check that.

Thanks Michael, I wondered about this, but dismissed it since it seemed like wishful thinking. Since this is indeed a problem that someone has actually experienced, it's feasible that it's my trouble too. I honestly hope this is the cause, as that means I didn't break anything!

My current plan is to do the other testing Monte suggested first, but I may not have the patience and just open the case to check...

I'll let you know.

Thanks Michael!

[rprosperi]

(02-26-2015 01:50 AM)rprosperi Wrote:  I'll let you know.

So, being completely impatient, I just had to know.

And yes indeed this is exactly what the problem has been, so thank-you Michael!!

To sum up:

Good news: Serial transfers to/from my 41CL now work!

Better news: I did not damage any of the delicate wiring while installing the internal serial port.

Best news: I'm not crazy (well...)

Slightly bad news: It now works, but another small problem has emerged, but I'll start a new thread to discuss it.

THANK YOU to all that offered feedback, ideas, programs, suggestions, etc. Learned a lot in the process.