Android emulator? Windows emulator? Linux emulator? iOS emulator?

This would be awesome to have because it would make it so that we could make rustworks work in a fully open source platform, like, for example, creating our own calculator hardware (fully open source unlike Numworks).

using branch split (or master) I get ERROR - Task dfu not found.

[cargo-make] INFO - cargo make 0.35.15
[cargo-make] INFO - Build File: Makefile.toml
[cargo-make] INFO - Task: dfu
[cargo-make] INFO - Profile: development
[cargo-make] INFO - Running Task: legacy-migration
[cargo-make] INFO - Running Task: workspace
/Data/Repositories/rustworks
[cargo-make][1] INFO - Build File: Makefile.toml
[cargo-make][1] INFO - Task: dfu
[cargo-make][1] INFO - Profile: development
[cargo-make][1] ERROR - Task dfu not found
[cargo-make][1] WARN - Build Failed.
[cargo-make] ERROR - Error while running duckscript: Source: Unknown Line: 5 - Error while executing command, exit code: 1
[cargo-make] WARN - Build Failed.

Any idea why? Thanks!

The output ns_to_cycles function was off by a factor of 1000. The resulting values are later cast to u8 which masks the problem that the output of ns_to_cycles is larger than 255.

The WE signal is now low for 28 ns instead of 376 ns, which is closer to the minimum timing. The overall drawing performance hasn't improved as much (only 10% - 30%), but I think the bottleneck is now the software and not the FMC controller. With the old timing values the CS line didn't toggle during a display clear, which probably means that the write FIFO was never empty. But with the new values the CS line toggles for each byte and I believe that the software isn't fast enough to keep the FIFO filled.

This might help you get the QSPI flash working. I didn't have time to look at the actual QSPI communication, but this should be a step in the right direction.

I've hooked up my calculator to a logic analyzer to check the QSPI communication and noticed that it seemed that there was no activity on the clock output. After increasing the speed setting for the QSPI pins the clock signal works correctly.

The display output has changed from all 00s to all ffs, but I didn't try to execute the mass erase or flashing operations yet.

Hello, I'm trying to use rustworks on my numworks (n110) from my Raspberry Pi 4 (with Raspberry Pi OS, I don't know if it matters) but when I run cargo make dfu I get the following error message:

[cargo-make] INFO - Execute Command: "dfu-util" "-d" "0483:df11" "-a" "0" "-s" "0x08000000:leave" "-D" "target/thumbv7em-none-eabihf/debug/rustworks.bin"
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: File size is too big: Success
[cargo-make] ERROR - Error while executing command, exit code: 74
[cargo-make] WARN - Build Failed.

Before running rustworks, I installed dependencies:

rustup target add thumbv7em-none-eabihf
sudo apt-get install gcc-arm-none-eabi binutils-arm-none-eabi 
sudo apt-get install dfu-util

rustup component add llvm-tools-preview
cargo install cargo-binutils
cargo install cargo-make

Then I cloned rustworks repository and ran cargo make dfu .

The bin file (target/thumbv7em-none-eabihf/debug/rustworks.bin) has a size of 2, 28 GB which seems effectively too big to flash on the numworks.

did I do something wrong?

This PR updates e-g to 0.7.

I wanted to try some e-g features on real hardware and needed version 0.7 for that. The st7789 driver isn't released yet and I had to use a git dependency. I'm not sure if you want to merge this now or wait until the driver is released.

First of all, sorry for the large PR. I hadn't intended to rewrite the entire file, but it turned out to be easier this way. By starting over I was able to test each function while implementing it. The code still needs some cleanup and contains a lot of duplication.

Erasing, programming and reading (in indirect and memory mapped modes) all seem to work now. The main method demonstrates this by erasing the first flash block and programing 8 bytes into it. I haven't yet tested programming of other blocks.

This PR fixes the FMC based LCD interface and changes the clock configuration. Previously the processor only ran at 16 Mhz (according to the clocks struct).

The cause of the FMC issue was related to caching and speculative execution. By disabling these features using the MPU the display works as expected and updates very fast.

The code in this PR is kind of messy and the MPU configuration probably isn't optimal, but it should be a starting point for further development. It could be improved a lot by implementing a higher level abstraction around the MPU (which I don't think exists yet).

I just tried to run this project on my Numworks calculator and the non FSMC version did work instantly. It's great to see embedded-graphics working on a calculator.

But I have noticed that the lcd_tearing_effect signal is incorrectly initialized as an output instead of an input.

Split the code up into crates to improve compile times and make the definition of each part more obvious. Also allows for cleaner use of the board support crate outside of the OS crate. This also begins work on a DFU bootloader (still need working external flash drivers for memory mapped mode).

Command: crate build

Full warning:

warning: use of deprecated associated function `cortex_m::peripheral::MPU::ptr`: Use the associated constant `PTR` instead
   --> board-support/src/lib.rs:140:26
    |
140 |         let mpu = &*MPU::ptr();
    |                          ^^^
    |
    = note: `#[warn(deprecated)]` on by default

warning: `nw-board-support` (lib) generated 1 warning

All code (especially code that deals with complex thing specific to embedded development like modifying registers) should be documented with comments explaining what's going on to make it easier for other people to understand and contribute to the project.

Need to finish QSPI flash and then create a boot loader so RustWorks can be flashed to external flash. Potentially useful links:

• flashAlgorithm docs: https://www.keil.com/pack/doc/CMSIS/Pack/html/flashAlgorithm.html
• flashAlgorithm for RP2040: https://github.com/rp-rs/flash-algo

Todo:

• [ ] Read external flash
• [ ] Write external flash
• [x] Flash algorithm implementation so that cargo flash can access external flash (done in willemml/rsworks-flash-algo)
• [ ] Make probe-rs and cargo-embed use flash algorithm
• [x] Enable writing external flash using dfu-util