PX41CX

[goosnarrggh]

(11-02-2022 05:18 AM)Sylvain Cote Wrote:  4) you also have three USART that can be used for RS232 transmission

There aren't enough free pins to add an practical general-purpose bidirectional communication port to the current ATmega328 based design. Interaction with the outside world is only available via the 6-pin programming interface while the micro is being held in reset so the alternate functions of some of those pins are rendered inactive.

Since the AVR128D28 part has the same pin count, and all the rest of the hardware (keyboard, LCD) is also the same, very similar limitations would also apply.

Workarounds would include moving up to a part with a higher pin count, or adding I/O expander chips. But the PDIP variant of this new chip is only available in a maximum of 28 pins; moving up to a higher pin count would mean moving to surface mount would be a DIY killer. I guess adding an I/O expander might be viable. But it would also add to the complexity of what is, right now, admirable for its simplicity.

[rprosperi]

(06-07-2023 04:33 PM)agarza Wrote:  

(06-07-2023 11:39 AM)rprosperi Wrote:  Thanks but not sure I follow the 2 statements - above it says "...can hold about 18 pages of extra modules in it's flash memory". Does this mean the Flash can hold a 'library' of 18 images, but only 1 or 2 can be 'plugged-in' to the 41 for use at a time?

What I mean is that in flash memory you can store up to 18 pages (18 4K ROMS).
In RAM you could, in theory, store an additional 2 pages ( of 4K ROMS). But I'm not sure if this is practical, since there are plenty of modules that use more than 2 pages.

I have only tested it loading these modules : Advantage Pac (3 pages), Stat, Math , Games, Survey, Finance and Aviation. All loaded at the same time (pages 8 thru f).

Thanks. When testing it, did you check all the Fns of the Advantage ROM? I think (and Sylvain will correct me here if wrong) that this ROM uses bank-switched pages, which, if working correctly in PX41CX, would be a very good sign of ROM and machine compatibility.

[agarza]

(06-07-2023 05:24 PM)goosnarrggh Wrote:  Perhaps you could come up with a scheme to allow those "plugged in" modules to be installed as hex file overlays, rather than being linked into the main application hex file?

When the device is first programmed from an erased state, the main hex file could be programmed in the main address rage, and all the "slots" for individual modules could be "blank" (all 0xFF's) which hopefully could be safely interpreted as meaning "unplugged".

When you want to "plug in" a module, you'd need to decide which "slot" you want to install it in, then modify the base address of its hex overlay to have the appropriate start address. Then use Microchip Studio to program that hex file into its selected slot *without* erasing the rest of the chip.

Rinse and repeat for each additional module you want to plug in.

Problems would arise, however, when the time came to "un-plug" a module after it was already installed. Because I don't think Microchip Studio's programming interface offers an option to selectively erase just one region of Flash memory, it's all or nothing. So I guess you'd have no choice but to erase the whole chip, re-program the main code again, and start over with installing your new selection of modules.

I have not studied the avr documentation regarding flashing, but would be nice if you could erase and flash only certain pages.

[agarza]

(06-07-2023 05:37 PM)goosnarrggh Wrote:  moving up to a higher pin count would mean moving to surface mount would be a DIY killer.

exactly, it's so hard to keep it simple!

[goosnarrggh]

(06-07-2023 09:32 PM)agarza Wrote:  

(06-07-2023 05:24 PM)goosnarrggh Wrote:  Perhaps you could come up with a scheme to allow those "plugged in" modules to be installed as hex file overlays, rather than being linked into the main application hex file?

When the device is first programmed from an erased state, the main hex file could be programmed in the main address rage, and all the "slots" for individual modules could be "blank" (all 0xFF's) which hopefully could be safely interpreted as meaning "unplugged".

When you want to "plug in" a module, you'd need to decide which "slot" you want to install it in, then modify the base address of its hex overlay to have the appropriate start address. Then use Microchip Studio to program that hex file into its selected slot *without* erasing the rest of the chip.

Rinse and repeat for each additional module you want to plug in.

Problems would arise, however, when the time came to "un-plug" a module after it was already installed. Because I don't think Microchip Studio's programming interface offers an option to selectively erase just one region of Flash memory, it's all or nothing. So I guess you'd have no choice but to erase the whole chip, re-program the main code again, and start over with installing your new selection of modules.

I have not studied the avr documentation regarding flashing, but would be nice if you could erase and flash only certain pages.

From first hand experience, I can say that you definitely can use Microchip Studio to flash different regions using separate hex files in separate operations. But each region has to start out initially empty.

If you are trying to use Atmel/Microchip Studio to reporgram a region that was already programmed with something else previously (essentially, even one single bit within that region being non-1), then you need to erase the whole chip in order to be able to reliably reprogram anything.

If you want to selectively reprogram individual pages without erasing everything, then you'd need to move beyond Atmel/Microchip Studio, and instead start looking into controlling the Non-Volatile Memory Controller from software -- that is, writing a bootloader.

But, to effectively use a bootloader for this sort of purpose, you would also need enough free pins to support a bidirectional communication port, such as a UART. Given what I've seen of your previous PX15C design (I bought/built one of your kits, and also studied the schematic), you don't have enough free pins to be able to do that.

[agarza]

(06-07-2023 09:02 PM)rprosperi Wrote:  Thanks. When testing it, did you check all the Fns of the Advantage ROM? I think (and Sylvain will correct me here if wrong) that this ROM uses bank-switched pages, which, if working correctly in PX41CX, would be a very good sign of ROM and machine compatibility.

Advantage ROM does use bank switching. And as far as I know, it's working fine.

[agarza]

(06-07-2023 09:40 PM)goosnarrggh Wrote:  From first hand experience, I can say that you definitely can use Microchip Studio to flash different regions using separate hex files in separate operations. But each region has to start out initially empty.

If you are trying to use Atmel/Microchip Studio to reporgram a region that was already programmed with something else previously (essentially, even one single bit within that region being non-1), then you need to erase the whole chip in order to be able to reliably reprogram anything.

If you want to selectively reprogram individual pages without erasing everything, then you'd need to move beyond Atmel/Microchip Studio, and instead start looking into controlling the Non-Volatile Memory Controller from software -- that is, writing a bootloader.

I'm not using Atmel/Microchip Studio. I'm using pymcuprog, with a Serial-UPDI adaptor. But still don't know if it's posible to erase and flash certain pages.
The help says "use -m to erase only a specified memory region (if available)"

(06-07-2023 09:40 PM)goosnarrggh Wrote:  But, to effectively use a bootloader for this sort of purpose, you would also need enough free pins to support a bidirectional communication port, such as a UART. Given what I've seen of your previous PX15C design (I bought/built one of your kits, and also studied the schematic), you don't have enough free pins to be able to do that.

You're right, the AVR128DA does not have enough pins to add UART. So I'm multiplexing the SPI and UART ports (display and serial).

[goosnarrggh]

(06-07-2023 10:35 PM)agarza Wrote:  I'm not using Atmel/Microchip Studio. I'm using pymcuprog, with a Serial-UPDI adaptor. But still don't know if it's posible to erase and flash certain pages.
The help says "use -m to erase only a specified memory region (if available)"

I've dug through that tool's source code. Essentially, the -m option allows you to pick whether the erase will impact the whole chip (Flash + EEPROM), or just the Flash, or just the EEPROM. The tool doesn't seem to allow anything more fine-grained than that. This is also consistent with what you'd be able to do via the Studio.

[Eric Rechlin]

(06-07-2023 09:38 PM)agarza Wrote:  

(06-07-2023 05:37 PM)goosnarrggh Wrote:  moving up to a higher pin count would mean moving to surface mount would be a DIY killer.

exactly, it's so hard to keep it simple!

Maybe I'm not normal, but I find SMD to be easier to solder than through-hole. As long as you use enough flux it's really easy to solder a TSSOP or similar.

[goosnarrggh]

(06-08-2023 01:06 AM)goosnarrggh Wrote:  I've dug through that tool's source code. Essentially, the -m option allows you to pick whether the erase will impact the whole chip (Flash + EEPROM), or just the Flash, or just the EEPROM. The tool doesn't seem to allow anything more fine-grained than that. This is also consistent with what you'd be able to do via the Studio.

After digging a little deeper, it appears that the back-end code in that tool will vary depending on which series of microcontroller you are programming, which type of programming adapter you are using, and as a consequence, which variant of the UPDI protocol is in use. If you're using the simple RS232 serial programming adapter, with the modern AVR UPDI backend, it looks like the bulk erase (Flash + EEPROM + User Signature) is executed in a single atomic command.

But when you are erasing just the Flash space in isolation, it falls back to a loop in which it sends individual debugger commands to erase each page in sequence. The section in the device datasheet describing the UPDI debugger command set is pretty obtuse, but my gut says that it might be feasible to break up that loop. You could probably hack the tool so that it can selectively erase individual ranges of pages in isolation. It would probably also involve adding new command line arguments to allow you to specify an optional start address and length parameters to the selective flash memory erase command.

[revwillie]

just catching up on this. Alex, you are an animal! I can't wait to see and possibly build one of these kits in the near future. I recently stumbled upon Guido Socher's blog post with modified key shapes to be 3d printed for the original PX enclosure http://tuxgraphics.org/npa/px15c-with-bevelled-keys and I had already been experimenting with a possible multicolor print for my first PX.
I am new to 3d printing and I don't have a fancy multi-material printer, so there isn't much to report. I'm just excited to see where the PX is going. Awesome work!

[agarza]

(06-11-2023 04:10 PM)revwillie Wrote:  I recently stumbled upon Guido Socher's blog post with modified key shapes to be 3d printed for the original PX enclosure http://tuxgraphics.org/npa/px15c-with-bevelled-keys

Guido not only created an excellent tutorial on 3D printing the case but also helped with extensive debugging and improvements.

[comabereni]

I recently joined the forums after purchasing an assembled PX calculator (PX41C) and two kits (PX15C, PX16C) from Alex and just wanted to say that dealing with Alex directly is a top-notch experience and these calculators/kits are very high quality. I am also on Alex's PX41CX wait-list as well and can't wait to see more updates. Thank you, Alex, for your excellent work. How about a PX48GX next? Just, wow! :-)

[agarza]

Just a quick brief on the PX41CX status.

I know it’s been a long time since last update. But real work always gets in the way.

The hardware changed a bit:

• Tactile Switches: New tactile switches with a force of 70gf (compared to the previous 240gf).
• Keycaps: Now with color keycaps! The final version will sport blue, yellow, grey, black, and white keys, reminiscent of the iconic HP-45 color scheme.
• Battery: Currently, the calculator can use one or two CR2032 coin batteries. Thinking of removing the second battery.
• Display: Ultra-low power monochrome reflective LCD with a resolution of 250x122 pixels. (No backlight)
• Connectivity: For programming and data transfer, supports Serial RS232 connectivity. The connector is a standard female USB mini B. While this choice may seem unconventional, USB-to-serial (RS232) cables with USB-A to USB-mini “plugs” are readily available.
• Size: The 3D-printed case dimensions are 73.5mm x 137.5mm x 14.6mm.
  

Currently, I’m waiting for the parts to arrive and re-test again.

If you have any comments or suggestions, feel free to share! ?


*The shifted legends are going to be gold color.

[Dave Britten]

Wow, that looks cool! I would almost certainly buy one of these kits if it's made available.

[Pierre]

Hi Alex,
Great!!! As usual!
For USB transfer: transfer via DUMP and/or RAW and/ or TXT?
In any case, I'm looking forward to being able to buy one!
All I'm gonna miss is the PX10C, PX32S and PX42S...

[thenozone]

definitely looks well, and the gold colour for shifts will tie in well with the yellow shift key; good work.

[Helix]

I would have liked backlight, but of course it won’t stop me from buying one.

I like the font, and the display of the 4-level stack.
Will the letters be blue?

My dream would be a PX-74S:
http://www.jeffcalc.hp41.eu/emu71/emu72.html

[Garth Wilson]

(04-30-2024 10:16 PM)Helix Wrote:  I would have liked backlight,

Backlights and color displays are power hogs, and would require a rechargeable battery that you have to recharge regularly like people do their phones every night.  I much prefer reflective LCDs and handheld computers & calculators that let me go months or even years without thinking about the batteries.

[PeteMoore]

Hi - love your work.
Like a lot of people who bought an HP-41 new back in the 80s my eyesight is getting worse. I wonder if you've thought about a desktop version with all the bells and whistles (large oled screen etc). Perhaps USB powered for a desk environment.
Thanks - Pete
p.s. I would buy one of your kits immediately but unfortunately here in the UK we get hammered by VAT and fines by the post office for administering it, more than doubling the price.