Building a new driver based on the existing modm's flash driver - Block Device Spi flash

[ludekcizinsky]

Hi,
I am currently working on implementing driver for a flash chip (W25M512JV). A lot of the functionality that I need is already implemented within the existing driver for another chip written in modm - SST26VF064B. To be more specific, the only core difference is that my flash chip has two dies and my goal is to abstract this away from the client so it can act as if there was just one die. In practice, this means that I need to add a couple of new instructions such as switching between dies, and overload the existing core functions erase, program and read. (Or at least this is what I view as the possible solution as of now)

I am considering what is the best way to implement this new driver:

1. Inherit from modm's driver - I tried this and ran into a couple of issues such as need to increase the depth of NestedResumable, also certain members such as Instruction are private which makes it difficult to extend the instruction set

2. Write completely new driver using the same style as the modm's driver - this would mean that I would simply copy paste certain code...

3. Extend directly modm's driver - as I said, the core difference between the two drivers is the presence of two dies

I will be grateful for some advice on how to tackle this challenge :)

[salkinium]

If the difference is not too much, I would roll it into the existing driver in a way that maintains backward compatibility. So number three.
You could rename the existing driver to a more generic name and then template alias the differences.