HP41 TULIP4041 update

[MeindertKuipers]

Thanks for the clarification Christoph! Learned something again.

Some have been playing with the TULIP already, and I wanted to share some of the design trade-offs.

FI input
The FI input is used only for tracing the FI line, and does not have any real function for the TULIP. The FI output of course is critical for the operation of some modules, including HP-IL. The final module version will not have the FI input because it requires an extra level shifter and there is simply not enough space on the module PCB. There will be an FI output of course. And based on this output you will still be able to see when the FI line is driven by the TULIP, but you cannot see any FI activities from outside the TULIP (like TIME on the 41CX). If you still wish to trace FI, than simply use the TULIP DevBoard.
The FI input has a jumper. This can be used to isolate FI and and expose GPIO2. This can then be used as an SPI or I2C port to connect a display, RTC or other goodies with your own TULIP firmware version
IR out and PWO outputs
The TULIP uses almost all available GPIOs, and the Pico2 module does not expose all RP2350 GPIO's. Therefore the IR and PWO outputs are shared, and also jumpered to expose GPIO3 to able able to offer SPI or I2C together with GPIO2.
The TULIP module version will have its own independent IR and PWO outputs, with a solder jumper on PWO for just an extra spare GPIO.
UART on GPIO0 and GPIO1
This is a remnant from the first development cycle, and it is still used by me to experiment in situations where a USB connection is not desired (power mode testing). I normally connect this to the UART on the Pico Probe. This UART will be available on the module version. As a possible use it is foreseen to be connected with the new PILBox to have a real HP-IL loop interface.
TULIP Power
On the DevBoard there is a FET to allow power switching between USB power and HP41 power. The FET is there to allow the TULIP to be powered from USB even when HP41 power (which has a higher voltage) is present to prevent draining the HP41's battery. It is not intended to power the HP41 from USB. There is a jumper on the HP41 VBAT line to prevent the TULIP to be powered from the calculator when there is no USB connection, this is your choice. On the final module this will be a solder jumper, which is bridged by default. Cut the trace if you do not want this.
And I still have to do tests on the low-power modes of the RP2350.
TULIP module version
I have a draft schematic and layout of the module. The main differences with the DevBoard are:
- maximum amount of FLASH, 16 MByte, hand solderable SOIC-8 footprint
- USB-C connector, micro SD card holder
- no FI input, only FI output tracing
- an RTC is foreseen for TIME emulation,. This requires an external battery and adapted housing
- IR led, on-board LED (considering multi-colour) and PWO driving
- connections (for 2mm header) with I2C/UART/debug/BOOT/RUN/spare. I2C shared with RTC
- 3D printed housing

Always happy to get feedback. In a next post I will point out some of the plans I have with the firmware and functionality.

[GertSanders]

Any images of an assembled TULIP ?

[MeindertKuipers]

(10-31-2024 05:13 PM)GertSanders Wrote:  Any images of an assembled TULIP ?

Sure, here it is. And I am planning to make a new video in the next few days
   

[John Keith]

(10-31-2024 11:26 AM)MeindertKuipers Wrote:  - an RTC is foreseen for TIME emulation,. This requires an external battery and adapted housing

You might want to adapt the RTC battery that RPi sells for the Pi 5 if it is compatible with the Tulip circuitry.

Also, at the risk of heresy, I note that you have here a dual-core ARM CPU with an SD card connected to the HP-41. This would allow the 41 to call external programs written in C or Python if a suitable software interface could be provided.

Please ignore the comment above if this is already part of the design, I am not an HP-41 person and I haven't been following Tulip development that closely.

[MeindertKuipers]

(11-02-2024 12:33 PM)John Keith Wrote:  

(10-31-2024 11:26 AM)MeindertKuipers Wrote:  - an RTC is foreseen for TIME emulation,. This requires an external battery and adapted housing

You might want to adapt the RTC battery that RPi sells for the Pi 5 if it is compatible with the Tulip circuitry.

Also, at the risk of heresy, I note that you have here a dual-core ARM CPU with an SD card connected to the HP-41. This would allow the 41 to call external programs written in C or Python if a suitable software interface could be provided.

Please ignore the comment above if this is already part of the design, I am not an HP-41 person and I haven't been following Tulip development that closely.

Thanks for the battery tip. I was indeed considering such a solution, but did not look into anything specific yet.
And calling stuff (in C) from the HP41 is indeed on my list of goodies.

[foldedtoad]

Here are some images of the module encased with sacrificed module case.
The module case was trimmed a bit on bottom half to allow for the PCB to fit.
I used kapton tape to temporary hold the module case halves together; later will glue them together.

[foldedtoad]

(11-02-2024 07:04 PM)foldedtoad Wrote:  Here are some images of the module encased with sacrificed module case.
The module case was trimmed a bit on bottom half to allow for the PCB to fit.
I used kapton tape to temporary hold the module case halves together; later will glue them together.

I don't know why the pics didn't show up, but here are links to them.
https://github.com/foldedtoad/tech_image...G_7976.JPG
https://github.com/foldedtoad/tech_image...G_7975.JPG
https://github.com/foldedtoad/tech_image...G_7977.JPG
https://github.com/foldedtoad/tech_image...G_7980.JPG

[Thomas Klemm]

(11-03-2024 05:48 PM)foldedtoad Wrote:  I don't know why the pics didn't show up, but here are links to them.

You have to link to the raw images:

[Etienne Victoria]

A bit late to the party but another happy TULIP4041 live here !!!

All checks passed.

Thank you Meindert !!

   

[Edit : succeeded in embedding a picture ; what a chore]

[twoweims]

Another late to the game success here, too.
My first attempt at surface mount soldering...
All tests passed.

   

   

[MeindertKuipers]

Good work assembling the TULIP and remember to have fun with it!

Let me share some of the things I am currently working on for the TULIP.
First of all, do not expect any new firmware updates anytime soon, unless there is a serious bug. I have been working on a file system in FLASH memory to handle ROM images and decided it is better to first get things organized and write down what I am going to do. Some time has now been spent on writing the documentation. After that I will go back to coding again. In the meantime I will be moving to another house and switching to a new computer, so please be a bit patient. At least I am now retired and work does not interfere anymore.

The next firmware update will be a big one and has the following new functionality:
- FLASH file system for ROM and MOD files (imported from the uSD card)
- plug and unplug ROM and MOD based ROM images
- supporting functions to manage images in FLASH, list, remove, update

After that the next version will focus on FRAM functionality:
- extension of FLASH file system for FRAM
- HEPAX support
- support for QROM (MLDL RAM) and HEPRAM

In between I will possibly add functionality to the tracer:
- mnemonics type choice
- pass or block samples in a user specified address range
- trigger, to start and end tracing at a user specified address
- add the current Bank to the trace listing

Furthermore some existing functionality needs to be fixed (non-critical):
- RFC and CMD handling of the PILBox emulation
- Enable HP-IL device mode support
- Fix the HP82143A printer emulation to ensure correct operation with the Printer Service Module
- Add non-graphic HP82143A printing to a terminal emulator (not a fix but something I want to have)

Issues, bugs or feature requests are best reported on my GitHub page, but do not hesitate to start a discussion here on the forum.

[Etienne Victoria]

Just upgraded to firmware 0.5.

We'll be patient :-)

Now let's go build the IR receiver and a case for the TULIP.

Cheers

E.

(11-17-2024 09:52 AM)MeindertKuipers Wrote:  Good work assembling the TULIP and remember to have fun with it!

Let me share some of the things I am currently working on for the TULIP.
First of all, do not expect any new firmware updates anytime soon, unless there is a serious bug. I have been working on a file system in FLASH memory to handle ROM images and decided it is better to first get things organized and write down what I am going to do. Some time has now been spent on writing the documentation. After that I will go back to coding again. In the meantime I will be moving to another house and switching to a new computer, so please be a bit patient. At least I am now retired and work does not interfere anymore.

The next firmware update will be a big one and has the following new functionality:
- FLASH file system for ROM and MOD files (imported from the uSD card)
- plug and unplug ROM and MOD based ROM images
- supporting functions to manage images in FLASH, list, remove, update

After that the next version will focus on FRAM functionality:
- extension of FLASH file system for FRAM
- HEPAX support
- support for QROM (MLDL RAM) and HEPRAM

In between I will possibly add functionality to the tracer:
- mnemonics type choice
- pass or block samples in a user specified address range
- trigger, to start and end tracing at a user specified address
- add the current Bank to the trace listing

Furthermore some existing functionality needs to be fixed (non-critical):
- RFC and CMD handling of the PILBox emulation
- Enable HP-IL device mode support
- Fix the HP82143A printer emulation to ensure correct operation with the Printer Service Module
- Add non-graphic HP82143A printing to a terminal emulator (not a fix but something I want to have)

Issues, bugs or feature requests are best reported on my GitHub page, but do not hesitate to start a discussion here on the forum.

[rocket.scientist]

(11-17-2024 09:52 AM)MeindertKuipers Wrote:  . . . I will be moving to another house and switching to a new computer, so please be a bit patient. At least I am now retired and work does not interfere anymore.

Congratulations on both your retirement and the new house. Just know my honey-do and to-do lists both got longer at exactly the same time as my retirement. :-)

[born2laser]

(11-17-2024 09:52 AM)MeindertKuipers Wrote:  Good work assembling the TULIP and remember to have fun with it!

Let me share some of the things I am currently working on for the TULIP.
First of all, do not expect any new firmware updates anytime soon, unless there is a serious bug. I have been working on a file system in FLASH memory to handle ROM images and decided it is better to first get things organized and write down what I am going to do. Some time has now been spent on writing the documentation. After that I will go back to coding again. In the meantime I will be moving to another house and switching to a new computer, so please be a bit patient. At least I am now retired and work does not interfere anymore.

Finally after some busy weeks at work and a business trip to Gottingen I was able to do my clumsy soldering last weekend, it all worked as advertised (except for a backwards connected LED that was easy to fix, duh). It of course left me hungry for more features, but I will be patient. There are some experiments I wanted to do that the adapter board is making easier for me to do and will keep me busy while you do your thing
Here is a picture of mine, who lives in a salvaged Gel-Pak
   
Juan

[foldedtoad]

I am seeing an alignment fault with TULIP when built on Ubuntu 22.04 + Pico-SDK.
I don't believe this is an issue with TULIP per-se, but rather something in the Pico-SDK.
I would be interested in hearing if others have experience a similar problem.

Some context:
Ubuntu 22.04 LTS
gcc 10.3.1 arm-none-eabi-gcc
Pico-SDK 2.0.0 (I know there is a newer version: 2.1.0, but not relevant here IMO)
newlib version 3.3.0-1.3 (newlib-arm-none-eabi) the library with memcpy() function.

Details:
The alignment fault occurs when the tinyusb module rp2040_usb.c function sync_ep_buffer() attempts a memcpy() from hw_data_buf (device memory) to user_buf (normal memory) for a length of 7 bytes (when receiving a CDC Set_Line_Coding packet on EP0). When the memcpy() attempts to copy the tail-end of the 7 bytes and used a LDRH asm instruction to load a half-word (16-bits) from device memory (USB Controller memory), the fault occurs.

If i replace the memcpy() call in sync_ep_buffer() with a byte-by-byte copy (for loop) in rp2040_usb.c, then I don't see this issue, as the half-word LDRH instruction is not used.
With this temporary workaround I have a working TULIP system.

I have also loaded the tullip4041.uf2 binary found in the github project and it works without problem.
This would indicate there is something in my build environment which is marking the Pico2/RP2350 USB Controller's device memory differently from how it is being build in a Windows environment.

Attached is a text file which shows the disassemble memcpy() for ARM V7.m.

https://raw.githubusercontent.com/folded..._debug.png

[MeindertKuipers]

I seem to recall that there is a compiler/linker option to ensure correct alignment of variables. Maybe check in the relevant Rapsberry Pi forums if this issue has been see by others. I only use Windows for development, I know that Thomas uses Linux. Maybe he can comment

[ThomasF]

(12-08-2024 03:44 PM)MeindertKuipers Wrote:  I seem to recall that there is a compiler/linker option to ensure correct alignment of variables. Maybe check in the relevant Rapsberry Pi forums if this issue has been see by others. I only use Windows for development, I know that Thomas uses Linux. Maybe he can comment

Hi,

Yes, I use Linux as my main developing environment.
I was was also using Ubuntu 22.04 and had no problems building and running Tulip.
I have recently upgraded to 23.04 but have not yet tried to build on that system, but I can check again and try to list my setup.

Cheers,
Thomas

[Hiwi]

I have finished soldering and it works as expected.
Perfect HP-IL & bus trace functionality.
Nice project.
Ralf
   

[foldedtoad]

Just to let people know, I have resolved the "unaligned fault" problem I posted prior.

The following is for those interested in building TULIP on a Linux system; Ubuntu in particular.

In communicating with ThomasF, he indicated that his Ubuntu system was building w/o issues. (Thanks again, Thomas!)
This pointed to something in my build environment was amiss.

So I decided to completely reinstall the pico-sdk.
This install (Version 2.1.0 is now latest) went without any problems.
But when I tried to actually build TULIP, i received an error message indicating that picotool version was not at the 2.1.0 level.
By running the CLI command below, you can get the version of the picotool in your ${PATH}.

$ picotool version -s

In my case this indicated a picotool version of 2.0.0.
So I downloaded (from github), built and installed the latest version of picotool.
Now the "picotool version -s" command showed 2.1.0.

A minor change was made to ./TULIP-DevBoard/TULIP4041-P2/CMakeList.txt to bump the pico-sdk version number to 2.1.0.
With these changes, my TULIP build environment (on Ubuntu 22.04) is working per normal...no unaligned-fault issues and all CDC instances work as expected.

I am still not 100% clear as to how picotool influenced the "unaligned" issue.
From a cursory looking at the picotool code, I see that it contains a number of post-link functions.
So, my guess is that somehow the attributes(align) declarations were different or ???

Hope this info helps anyone else with a similar situation.