Discussion around the Swiss Micros DM42 calculator.
Vitasam
Posts: 235
Joined: Thu Jun 01, 2017 11:51 am
Location: Finland
Contact:

Michael wrote:
Mon Jun 04, 2018 8:59 pm
Nope, it's not broken, but RTFM my friend. In the readme it says:
Add GNU ARM toolchain and bin/ directory path to PATH.
The file check_qspi_crc is in the /bin/ directory and you need to put that directory in your PATH.
Yep, after RTFM I've found it But /bin folder is a part of the same GIT repository - why not add a PATH variable in to the Makefile?
With this git diff

Code: Select all

.../DM42PGM$git diff diff --git a/Makefile b/Makefile index 2deed67..e359b3f 100644 --- a/Makefile +++ b/Makefile @@ -18,6 +18,8 @@ endif BUILD_DIR = build # Free42 header files FREE42DIR = free42 +# check_qspi_crc path +CHECK_QSPI_CRC_DIR = bin ###################################### # source @@ -139,8 +141,8 @@$(BUILD_DIR)/$(TARGET).elf:$(OBJECTS) Makefile
$(OBJCOPY) --remove-section .qspi -O binary$@  $(BUILD_DIR)/$(TARGET)_flash.bin
$(OBJCOPY) --only-section .qspi -O ihex$@  $(BUILD_DIR)/$(TARGET)_qspi.hex
$(OBJCOPY) --only-section .qspi -O binary$@  $(BUILD_DIR)/$(TARGET)_qspi.bin
-       check_qspi_crc $(TARGET) dm/qspi_crc.h || ($(MAKE) clean && false )
-       add_pgm_chsum build/$(TARGET)_flash.bin build/$(TARGET).pgm
+       $(CHECK_QSPI_CRC_DIR)/check_qspi_crc$(TARGET) dm/qspi_crc.h || ( $(MAKE) clean && false ) +$(CHECK_QSPI_CRC_DIR)/add_pgm_chsum build/$(TARGET)_flash.bin build/$(TARGET).pgm
$(SIZE)$@

$(BUILD_DIR)/%.hex:$(BUILD_DIR)/%.elf | \$(BUILD_DIR)
I was able to build the project:

Code: Select all


...
arm-none-eabi-objcopy --only-section   .qspi -O binary  build/DM42PGM.elf  build/DM42PGM_qspi.bin
bin/check_qspi_crc DM42PGM dm/qspi_crc.h || ( make clean && false )
SHA1: 8fc7253dc7a4df9b4fe46630efae0d91d66362f5
arm-none-eabi-size build/DM42PGM.elf
text    data     bss     dec     hex filename
2030704    2208    4272 2037184  1f15c0 build/DM42PGM.elf
Elektronika MK-61, Elektronika MK-52, HP15c LE, DM42 SN#16 FW 3.18

Michael
Posts: 240
Joined: Wed Apr 05, 2017 11:31 pm

Michael wrote:
Mon Jun 04, 2018 9:12 pm
Many different licenses were used for the DM42 and some of the code can not be open sourced, not our decision.

Vitasam
Posts: 235
Joined: Thu Jun 01, 2017 11:51 am
Location: Finland
Contact:

I have created pull-request #1
Elektronika MK-61, Elektronika MK-52, HP15c LE, DM42 SN#16 FW 3.18

Michael
Posts: 240
Joined: Wed Apr 05, 2017 11:31 pm

Vitasam wrote:
Mon Jun 04, 2018 11:23 pm
I have created pull-request #1
Changes requested before pull

emece67

Michael wrote:
Mon Jun 04, 2018 9:12 pm
Many different licenses were used for the DM42 and some of the code can not be open sourced, not our decision.
The 100+ functions are system functions which can be called from the loaded program.
Using GPL software from the very beginning was Swissmicros's decision. Of course I'm not infallible here, but I think this approach does not fulfill the GPL license at all.

A pity, but I cannot support Swissmicros's products anymore. A double pity indeed as, albeit being the DM42 an interesting product, I find the WP43s project a really interesting one, but now it is also dead for me.

Well, that's all on my part. Bye.

Michael
Posts: 240
Joined: Wed Apr 05, 2017 11:31 pm

emece67 wrote:
Mon Jun 04, 2018 11:54 pm
... but I think this approach does not fulfill the GPL license ...
You must be a expert coming to this well founded explanation!
emece67 wrote:
Mon Jun 04, 2018 11:54 pm
Well, that's all on my part. Bye.
emece67 wrote:
Mon Jun 04, 2018 11:54 pm
Sorry, but I do not want to be in this forum any more.

EDIT: the last sentence of emece67 was his signature, which is not displayed anymore after I escorted him to the exit.

gmac42
Posts: 42
Joined: Fri Jun 01, 2018 11:30 am

Hi,

First off, I am rather new to this discussion and haven't read up entirely on the topic yet, so please bear with me if I got something entirely wrong.

I reckon that SwissMicros was violating the GPL, and, because of the binary blob stuff, maybe still is - not sure about that.
It took them some time (which is probably not surprising, given the complexity of the task and the available manpower) to make the source release that we see now. The delay would have been avoidable, had they opened their sources from the beginning, no doubt. But the fact that they finally delivered gives me the impression that they are really trying to make things right.

The way I see it is:
Honest attempts to fix them have also been made.
Maybe the work is not done yet. (I am not a GPL expert.)
In any case it seems that a lot has been achieved already.

If the binary blob is indeed a problem, could it be reimplemented als GPL-compliant code? I don't know how complex it is, but maybe this is a feasible community effort?

I am currently eagerly waiting for the DM42 to become available again. When I get mine, I'm willing to try and help fixing any remaining issues. Not because I particularly like to reinvent wheels, but because I hate so see this project suffer from this.

Regards
Gert
DM42 #650, DM41L #801, HP 41CX, HP 41CV, HP 50G, TI 89

ijabbott
Posts: 187
Joined: Fri Dec 15, 2017 2:34 pm
Location: GB-MAN

I have no problem with the way the program has been split into DMCP and DM42PGM. The separation seems pretty clean, although there are some oddities in the user interface, such as some things that you think would be part of DM42PGM are actually part of DMCP. The "Help" browser springs to mind.

I was wondering if some parts of DMCP could be open sourced in the near future? I realize that some parts need to be binary only, but source code would be useful for spotting, reporting, and/or fixing bugs in DMCP. For example, some of the Unicode mappings are a bit messed up, and it would be nice to see exactly how messed up they are.

mcc
Posts: 217
Joined: Fri Jun 23, 2017 5:10 am

Michael wrote:
Mon Jun 04, 2018 8:59 pm
mcc wrote:
Mon Jun 04, 2018 6:33 pm
... I know, that the STM32F103 is nearly unbrickable as long as one dont plan exactly how to brick the chip. This is due to the bootloader being in the
ROM and therefore not alterable.

How is the situation when it comes to the DM42?
That's the same with the STM32L476. On the PCB there are two buttons, RESET and PGM. If PGM is pressed during pressing RESET, the bootloader kicks in the dm_tool can be used to flash it with a good firmware.
Vitasam wrote:
Mon Jun 04, 2018 8:20 pm
mcc wrote:
Mon Jun 04, 2018 6:04 pm
Maybe the makefile could use the PATH into that bin-folder
I also noticed the same error when trying to build the project:
...[/code]

So the bottom line is: HEAD from GIT /master is broken now
Nope, it's not broken, but RTFM my friend. In the readme it says:
Add GNU ARM toolchain and bin/ directory path to PATH.

The file check_qspi_crc is in the /bin/ directory and you need to put that directory in your PATH.
Hi Michael,

Oh YEAH!
I know that the DM42 is nearly unbreakable (see story of its flight from a moving car to the ground...
as far I can remember posts in this forum) and to hear it is unbrickable also is great!
I like this concept of the "unmodifiable last resort bootloader" of the STM32-chips!

path to PATH." as "Add GNU ARM toolchain and bin/ directory path *of it* to PATH."
I now understand, what bin/ path was meant.

Cheers!
Meino
DM 42 - SN: 00373, Firmware release v.:3.18. / 3.18. as compiled by SwissMicros

Vitasam
Posts: 235
Joined: Thu Jun 01, 2017 11:51 am
Location: Finland
Contact: