Add SPI EEPROM simulator for W25X20CL #2
Comments
|
Helpful hints:
You did comment you're not as familiar with general programming - For command-register style stuff like you see with SPI/I2C, and many other embedded protocols, I'd suggest learning about bitfields and unions. These are a lot nicer/neater to manipulate (and maintain) than a bunch of &-ed or |-ed bitmasks littered throughout the code. Think of it like being able to "label" parts of a base data type. (From a technical perspective, unions let you interpret the same piece of memory with different data types, and we take advantage of the field-width feature of structs together with this). It leads to some really elegant code that's dead simple to read. (At some point I'll probably clean up the other ones that are in the example code too) For example - if you have something that takes an 8-bit command, of 2 bits are an opcode, and the other six some sort of memory address, you would define something like this: Then, you can use it in a way that's very easy to read for input: or output: and there's no messy 2^n enums, and basically zero chance of accidentally using the wrong bitmask! |
|
I have also pushed up a partial branch with some TMC2130 work in it that may be of use for reference. https://github.com/vintagepc/MK3SIM/tree/%238_TMC2130_Sim |
|
Just wanted to check in - I know it's still early stages but don't hesitate to ask if there's something I can clarify or assist with. If you'd like something smaller to get familiar with the architecture first, #13 is probably a good simple task to start. |
|
I was really busy with some MBL testing recently. I still don't understand this code quite well. What reference manual are you using for all the functions and their usage? |
|
Sure, no worries - Just wanted to make sure it wasn't off-putting because this can be a pretty complicated task if you don't know where to start. I'm primarily going off the examples and unit test code, as well as interpreting the .h files. the actual function documentation is pretty bad in that regard, it's basically just a list of the functions and the call stack with no info on what the arguments mean or are so I gave up on it. In some cases I've searched the code for a certain keyphrase (e.g "SPI", and then dumped the resulting relevant looking item (SPI_IRQ_OUTPUT) into google or github search to find examples. VS code with intellisense helps a bit if you know roughly what you're looking for. The primary thing any implementation/hardware boils down to is adding IRQ table entries for the various inputs/outputs (be they SPI, digital pin changes, PWM pin changes, etc.). Each part has listeners that act on input signals (avr_irq_register_notify()) and basically just passes out other signals (avr_raise_irq()). So within the context of an object it is basically a standalone entity that knows nothing of the outside world. You'll definitely need the datasheet for the flash chip so that you know what its SPI commands are. I'd build things up step by step from scratch - an example workflow, basically what I went through with the TMC drivers:
I think most of the relevant bits are available for the heavier lifting in other places - the TMC branch as noted earlier, some bits of the Einsy EEPROM for how to persist the data across reboots, etc. |
|
I’ll take a look later into implementing the spi flash. It should be much easier than the tmc drivers. Btw, I was wondering what performance you get out of the simulator. The thing is that I run a VM with ubuntu at the moment and the emulation moves really sluggish. If you run linux without a VM, is it worth it? |
|
It is kinda slow for me (though the primary point of reference I have is just reaction to input - encoder twists, knob pushes take 1-2 seconds to register). Hard to say whether that is because of the simulation or the firmware waiting and timing out on responses from things (such as the TMCs) that it's not getting. So I'm hoping it will get better as we get more hardware implemented. at some point I will try to do a performance profile to see if I can figure out why. but I've found that adding einsy_eeprom_poke(avr, EEPROM_CRASH_DET,0x00) helps a bit - right now it's constantly detecting crashes and trying to re-home which will pause the display until it fails. |
|
One other thing of note is that in the simreprap branch there's a comment that marlin does not have a sleep in its idle state so it's constantly running full throttle. That's definitely not helping the situation since even when idle the main loop is going to compete with any ISRs for cpu time. |
|
I'd say that reading now works quite nicely. The xflash file is also persistent, so that's nice. |
|
Currently the only change is related to UDRE0 - I changed the UART0 code to use UART1 instead. |
|
Derp, did not want it to auto-close. >_< |
Per title. Right now the F/W boots with 'W25X20CL is not responding..." message.
The text was updated successfully, but these errors were encountered: