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

An exception must be made to that hex file.

Right now the brightness detection doesn't work. This is due to simAVR limitations; it will always return 1 for the pin state if you try to read with internal pullup enabled.

The problem is in sim/avr_ioport.c, line 60.
(avr_ioport_update_irqs).

TODO - figure out how to deal with external loading when an internal pullup is enabled. This is a known bug (buserror/simavr#204)

Maybe fake it into thinking that pin has an external pullup for simulation...

When the level is 0 or 255, the analog_write function uses digital IO instead of timer PWM. As a consequence, 0 or 255 will be read by the simulator as whatever the timer had the last time in its registers

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

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

@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.

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?

We could use PF-build.sh for this.

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.

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?

Simulate the beeper?

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

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.

Simulate the PINDA.

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.

There's benefit to simulating the motors separately and "wiring" them to the drivers, I think.
Also simulate the endstops on X/Y/ZMax

edit: I pulled in stepper code from https://github.com/buserror/simreprap/ that may be a good starting point.

Add fan simulation.

@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

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.

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.

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.

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

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

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.

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.

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.

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

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.)

Connecting with pronterface over the PTY doesn't work right. Output is still being directed to the terminal, and pronterface is not seeing replies to the temperature commands.

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

Per title. Right now the F/W boots with 'W25X20CL is not responding..." message.

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.

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.

Motor driver simulation.
Might be nice to have it track position internally and display where it thinks it is vs where the printer thinks it is,

Also a visual of the motors while running.

I'm going to take a crack at this...

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

Get a CI setup implemented to autobuild PRs/commits.

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

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 )

The click can't be triggered in factory reset.

• 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.

• Because why not?
• FINDA
• Load to nozzle (connect P feed & IR sensor somehow)
• Drivers
• Dial in step distances/limits
• UART comms
• Get rid of external UART loopback
• LEDS
• Shift register(s)
• Minimalist visuals
• Clever title

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) ✔️

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.

Possibly blocked by #1 - even bumping up the UART initialization to before LCD_init() causes a hang. UART may have timer issues, or may be related to not having the at32u2 chip.

Blocked by #11. I suspect fixing that will get things working correctly.

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:

• Improve models:
  • Colours
  • Triangle counts
  • weird parts (LCD holders)
  • Group models with shared materials to reduce material and draw counts.
  • Binary OBJs for smaller filesize/faster load
• Better position tracking
• Fix E visualizer
• Pinda/heatbed blinkenlight?
• Cleanup TestVis to a proper class name
• Prune out unneeded helper code (normal calcs)

Bonus points:

• Render actual LCD on LCD
• Spin the encoder knob
• Standard vs MMU2 extruder
• MMU2 visuals
• MMU LEDs
• SD card visual

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 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.

Per #51, verify if we can upload firmware and language data to the simulated einsy.

If it doesn't work, fix it.