The mk404 from vintagepc

Flash display progress bar does not work

Progress bar on the bootloader flash screen doesn't work.

Bootloader hangs if trying to flash languages

The bootloader seems to get stuck in a serial waitloop not unlike main Marlin if you try to flash languages.

TODO: get a .afx build of the bootloader in order to disassemble and inspect it with the PC trace.

Bed starts PWMing as soon as the firmware boots

For some reason the bed PWM is active/toggling as soon as the firmware boots, causing the bed temperature to creep up.

Figure out what is going on. I suspect it's related to the invert mode on Timer0, and possibly some of the soft PWM tricks in use for the heatbed.

Reset not working

The reset key seems to not work most of the time. If you press R when you boot with the bootloader, it works correctly, but when the bootloader is skipped the firmware will just get stuck.
Also, is the uart DTR line creating reset signals?

Watchdogs/Optiboot is not working

@vintagepc I just finished a very basic W25X20CL implementation. It answers correctly to the initial Device ID and Manufacturer commands, enough to make the firmware recognize the spi flash.
The problem is that the firmware won't boot anymore. It gets stuck somewhere. It is not because of the W25X20CL since the CS is high when it gets stuck. I think that it now gets stuck inside optiboot_w25x20cl_enter(), but I didn't check exactly.

SD card sim

Simulate the SD card. Lower priority since can in theory print via USB with pronterface.

Compile error on HEAD

alex@alex-ubuntu:~/Desktop/simavr/examples/board_einsy$ make
CC ./hwDefs/fan.c
./hwDefs/fan.c:108:1: fatal error: opening dependency file obj-x86_64-linux-gnu/fan.d: No such file or directory
 }
 ^
compilation terminated.
../..//Makefile.common:183: recipe for target 'obj-x86_64-linux-gnu/fan.o' failed
make: *** [obj-x86_64-linux-gnu/fan.o] Error 1

License compliance

Review everything and make sure we satisfy licenses of any code we use /modify from other sources before we release it publicly

review license options for releasing our developed extensions and select one. (probably just GPL it.)

Performance profiling

Input seems sluggish. Investigate why things are slow and see if we can improve things.

Findings so far:
Adding

avr_extint_set_strict_lvl_trig(avr,0,false);
avr_extint_set_strict_lvl_trig(avr,1,false);

blocks the held-low interrupt trigger polling on INT0/INT1, which makes the simulator feel a little snappier. These are SCL and SDA (P3/filament sensor), so I don't think we use them for actual external interrupts.

Visuals for simulated printer

Look into some GL visuals to show the simulated printer in action, esp. the axes.

Quite a ways down the road, but very nice to have.

(Side note, I can do this as the LCD stuff reminded me I do have a GL class under my belt so should be able to get back up to speed on that in short order. Actually producing the models might be a different story, but hey, STLs are triangles... so are openGL meshes...)

Remaining todos:

Bonus points:

'make clean' deletes the bootloader hex file

An exception must be made to that hex file.

Persist EEPROM contents

Define and persist the internal EEPROM used to store calibration/firmware data.

Then we can poke it directly and do things like bypass the setup wizard during early bringup.

Streamline build/test process.

Setup a build chain that compiles both firmware and the simulator for faster and easier cycling of changes and investigating firmware issues.

Support base for Prusa printer variants

Implement a base platform on which additional printer models can be supported.
Implement a printer factory for instancing the requested model at startup.

Encoder CW and CCW pulse is only 1/4 of the actual encoder rotation

Because of the way the encoder works, we need 4 CW or CCW pulses for one movement to be registered by the fw.

Simulator waitlocks in Delay2 (Suspect Micro/Timer2 issue)

The firmware does not boot past any _delay() calls due to a timer issue.
There are some known documented timer bugs with simavr.

Figure out timer defaults

The timers are not initialized to anything (i.e. not running).

This means things like PWM control on PWM pins doesn't actually do anything.

It would be helpful if someone could dump the values of the timer control registers (prior to timer0_init) from a real einsy.

In particular, TCCRxA and TCCRxB, for x0...5

Option to disable the bootloader

There could be some way to provide an argument to the executable which skips over all the bootloader waiting and just jumps to address 0x0000

Implement heaters

Implement heaters/thermistors for the bed and hotend.

Probably just do a linear time ramp for now, can get fancy with overshoot later if we want.

Also, allow for overriding thermistor readings so you can fake things like thermal runaway.

Get CI working

Get a CI setup implemented to autobuild PRs/commits.

Improve SD card user experience

Ability for the user to specify a gcode file which is added to the image file at startup. Simplifies a lot running a gcode from the SD card in the sim.
Ability to specify path to SD card image.
Automatic image size detection. Default to 128MB when creating file.
Automatically format new image to fat32.
Option to plug/unplug virtual SD card (aka toggle SD_DETECT).
Option to unmount and remount SD image while running.
Ability to disable the SD sorting with argument. Just write a value to an EEPROM address.

Last character on the screen is most of the time broken or not cleared

Something seems to be broken with the last character on the lcd

Pressing 'R' results in factory reset

For some reason, pressing the R key makes the board enter factory reset on reboot. Could the encoder become stuck in the "pressed" state?

Serial output is blocked by M_UDREx not resetting

Stock firmware does not boot, it waitspins in MarlinSerial::Write() because it appears M_UDREx is not getting reset. I'm not sure whether this is a quirk of Marlin serial or the emulator since the bootloader can talk over PTY and flash firmware.

Glut: Highlight enabled axis

Just as the title says. If the axis is disabled, show the driver in normal text. If the axis is enabled, invert the color of the background of the axis letter.
This is purely cosmetic.

Timer2 Investigation

Sub-problem 1 in investigating #65

Looks like timer2 is overflowing about twice as often as it should, relative to "real life".

It went from 943998 -> 959998 (16000) in about 8 actual seconds.

This by itself isn't necessarily an issue, assuming we are clocking at double rate on our simulator.
But this does mess with real-time delays/timeouts.

The bigger issue is that millis starts at a non-zero value.

Questions and chit-chat

Hi @vintagepc
Thank you for inviting me to this project. I've read what you wrote so far in readme.md. I have a few questions:
How do you propose that we communicate after you push the first usable source code?
Are there others involved in the project?

Multi-lang support

We could use PF-build.sh for this.

MK3 PAT optical sensor

Simulate the MK3 PAT sensor.

(IR sensor has been implemented, so discussions below on that are outdated... I don't see any reason to really alter the class and we will be able to simulate the different versions if we bring in the changes in #122 )

ADC is not working right

Something is not right with the ADC configurations/sim behaviour.
Temperatures read higher or lower than they should; I suspect partly a bug in the thermistor code, and partly incorrect AREF configuration.

Simulate an MMU2

Bed temp too high

For some reason the bed reads about 7 degrees higher than it should. Not sure why as the raw ADC values seem correct...
Bed reads 70C with an input value of 63C. (Hotend is on target).

simAVR ADC out value: 4105 (corresponds to 839 in the thermistor table, this seems right)
[[ 65C == 830, 60C==857 ]]

current_temperature_raw_bed (in FW): 13424. 13424/16 (oversample nr) == 839 as well.

How do timers work in simAVR?

How do the timers work in simAVR? Do they function just like in the real hardware by having their clock tied to the CPU's clock source? I'm asking this, since the way the timers+WDT behave looks a lot like they are tied to the host's clock, not actually to the simulated program.
I have a feeling (not sure how to test it) that when the simulation slows down because of many IRQs or something like that, the timers keep on ticking at the usual rate. This would explain why I get WDT resets with the Print from SD menu when it has to load a lot of data (when it has to find a file on the card by filename).

I'm also curious why the CPU seems to be overclocked all the time. Is it really clocking so fast or are the timers running faster than they should (aka, _millis()/_micros() tick too fast)? Maybe we could make a "TPS" (ticks/s) reading derived from the program counter so that we can see how fast the simulation is running at any time.

Fix display character handling

There are a few issues with the stock display implementation:

Colour of text is black ✔️
No brightness support ✔️
Custom characters don't work ✔️
Possible wrap/RAM alignment issue. I think the stock does not map the memory correctly for 20x4 displays. I had to hack this to make it work, I probably missed something when chain-writing across boundaries. (Bootloader flashing display is an example) ✔️

Voltage simulation

Simulate the two sense pins for the power supply rails. One for bed, the other for everything else 24V. Not really needed, but we could make it anyway, just for the sake of a complete simulation.

How to manage source code

@vintagepc Quick question: how do you include this project over the simavr cloned repo?
Just moving this source over that project doesn't seem like something clean

Segfault after #44

After I merged #44 to my local branch, I started getting segmentation faults after thermistors are initialized.
Line responsible for the error at runtime:
avr_connect_irq(hw.hBed.irq + IRQ_HEATER_TEMP_OUT,hw.tBed.irq + IRQ_TERM_TEMP_VALUE_IN);
If it's commented out, everything works correctly.

Documentation and comments

Once things settle down a bit... fix up the documentation (Getting started, how-tos) and go through the code and add some useful comments to the various hardware objects we've added or changed.