MKS CANable V2.0

[KozhinovAlexander]

add new board MKS CANable V2.0 Please refer to added documentation for more information.
The hardware of the board can be dound under: https://github.com/makerbase-mks/CANable-MKS

[KozhinovAlexander]

@henrikbrixandersen You will see an overlay for this board in CANnectivity later. ;) Thus please take a look too.

[nordicjm]

Board is OK, please fix ordering issue

[KozhinovAlexander]

Board is OK, please fix ordering issue

Thank you for you review. Great to see a feedback from hwv2 guy :) I'll do necessary changes today late night.

[nordicjm]

Updates need squashing i.e. 2 commits

[KozhinovAlexander]

Updates need squashing i.e. 2 commits

Thank you. It is done now.

[nordicjm]

Updates need squashing i.e. 2 commits

Thank you. It is done now.

So the second vendor update commit needs squashing into the first vendor update commit and the second board commit needs squashing into the first board commit. Something like this:

git rebase -i 40cd35e56d43716bdbdeafafa6c356407121ca2e
  change first to edit, third to fixup, forth to drop
git cherry-pick ddf9bfdf02006c2dc4e2012ae5ad93a3a0fde584
git rebase --continue
git rebase -i 40cd35e56d43716bdbdeafafa6c356407121ca2e
  change second to fixup

Now you should have 2 commits

[KozhinovAlexander]

Updates need squashing i.e. 2 commits

Thank you. It is done now.

So the second vendor update commit needs squashing into the first vendor update commit and the second board commit needs squashing into the first board commit. Something like this:

git rebase -i 40cd35e56d43716bdbdeafafa6c356407121ca2e
  change first to edit, third to fixup, forth to drop
git cherry-pick ddf9bfdf02006c2dc4e2012ae5ad93a3a0fde584
git rebase --continue
git rebase -i 40cd35e56d43716bdbdeafafa6c356407121ca2e
  change second to fixup

Now you should have 2 commits

Got it. Will do.

[henrikbrixandersen]

Given that upstream threats this as one of multiple board variants (see https://github.com/makerbase-mks/CANable-MKS), I think we might want to do the same (bu renaming the board folder etc.). Support for the V1.0 and the PRO editions can then be added later on. What do you think?

[nordicjm]

Given that upstream threats this as one of multiple board variants (see https://github.com/makerbase-mks/CANable-MKS), I think we might want to do the same (bu renaming the board folder etc.). Support for the V1.0 and the PRO editions can then be added later on. What do you think?

There are a lot of differences between each version of the HW. To me their versioning seems more as an tagging of evolution approach and not of progress.

Yes, this. I very much agree with the point of view that we shouldn't try to "force" boards into hwmv2 variants/revisions just because naming scheme from a given vendor seems to call for using them. Sometimes ProductFoo and ProductFoo X just happen to be very different beasts (see ex how we have rpi_pico2 coming up as its own board).

How does it not fit? The schematics for v1.00 and v1.00 pro are the same except one has a TJA1051T and the other has a ADM3053 on page 2 of the schematic, the other 5 pages of the schematics are exactly the same. That's the definition of a board revision. The v2.00 seems to be completely different but that doesn't mean v1.00 and v1.00 pro can't use board revisions. And rpi_pico2 is a different board, no-where as anyone or the company themselves said it's just a revised PCB

[KozhinovAlexander]

Given that upstream threats this as one of multiple board variants (see https://github.com/makerbase-mks/CANable-MKS), I think we might want to do the same (bu renaming the board folder etc.). Support for the V1.0 and the PRO editions can then be added later on. What do you think?

There are a lot of differences between each version of the HW. To me their versioning seems more as an tagging of evolution approach and not of progress.

Yes, this. I very much agree with the point of view that we shouldn't try to "force" boards into hwmv2 variants/revisions just because naming scheme from a given vendor seems to call for using them. Sometimes ProductFoo and ProductFoo X just happen to be very different beasts (see ex how we have rpi_pico2 coming up as its own board).

How does it not fit? The schematics for v1.00 and v1.00 pro are the same except one has a TJA1051T and the other has a ADM3053 on page 2 of the schematic, the other 5 pages of the schematics are exactly the same. That's the definition of a board revision. The v2.00 seems to be completely different but that doesn't mean v1.00 and v1.00 pro can't use board revisions. And rpi_pico2 is a different board, no-where as anyone or the company themselves said it's just a revised PCB

Thank you for taking a look on it.
Agree, marker base MKS v1.00 and v1.00 pro may be pretty same. But here v2.00 will be integrated.
In general it definitely would be possible to add v2.00 that way, that with some DTS overlays v1.00 and v2.00 could be covered. But I see it also out of scope of this PR.
Still, I am completely open if someone will add v1.00 right way and do the whole necessary work. I will support, provide review, test.

[kartben]

Given that upstream threats this as one of multiple board variants (see https://github.com/makerbase-mks/CANable-MKS), I think we might want to do the same (bu renaming the board folder etc.). Support for the V1.0 and the PRO editions can then be added later on. What do you think?

There are a lot of differences between each version of the HW. To me their versioning seems more as an tagging of evolution approach and not of progress.

Yes, this. I very much agree with the point of view that we shouldn't try to "force" boards into hwmv2 variants/revisions just because naming scheme from a given vendor seems to call for using them. Sometimes ProductFoo and ProductFoo X just happen to be very different beasts (see ex how we have rpi_pico2 coming up as its own board).

How does it not fit? The schematics for v1.00 and v1.00 pro are the same except one has a TJA1051T and the other has a ADM3053 on page 2 of the schematic, the other 5 pages of the schematics are exactly the same. That's the definition of a board revision. The v2.00 seems to be completely different but that doesn't mean v1.00 and v1.00 pro can't use board revisions. And rpi_pico2 is a different board, no-where as anyone or the company themselves said it's just a revised PCB

But this is the PR introducing V2, so I was commenting on that, Jamie. And you seem to agree it's completely different, and pretty the same story as Pico vs. Pico 2?

[nordicjm]

Given that upstream threats this as one of multiple board variants (see https://github.com/makerbase-mks/CANable-MKS), I think we might want to do the same (bu renaming the board folder etc.). Support for the V1.0 and the PRO editions can then be added later on. What do you think?

There are a lot of differences between each version of the HW. To me their versioning seems more as an tagging of evolution approach and not of progress.

Yes, this. I very much agree with the point of view that we shouldn't try to "force" boards into hwmv2 variants/revisions just because naming scheme from a given vendor seems to call for using them. Sometimes ProductFoo and ProductFoo X just happen to be very different beasts (see ex how we have rpi_pico2 coming up as its own board).

How does it not fit? The schematics for v1.00 and v1.00 pro are the same except one has a TJA1051T and the other has a ADM3053 on page 2 of the schematic, the other 5 pages of the schematics are exactly the same. That's the definition of a board revision. The v2.00 seems to be completely different but that doesn't mean v1.00 and v1.00 pro can't use board revisions. And rpi_pico2 is a different board, no-where as anyone or the company themselves said it's just a revised PCB

But this is the PR introducing V2, so I was commenting on that, Jamie. And you seem to agree it's completely different, and pretty the same story as Pico vs. Pico 2?

For this board yes, the original comment refers to v1.00 and pro

[henrikbrixandersen]

https://docs.zephyrproject.org/latest/snippets/rtt-console/README.html

[KozhinovAlexander]

@henrikbrixandersen Thank you for your input. I've done the chnages requested. The OpenOCD config will be moved to separate PR in few minutes.

UPDATE:
Regarding Seger RTT console sample from this link: https://docs.zephyrproject.org/latest/snippets/rtt-console/README.html I can not see step-by-step guide there like my documentation for this board do. Thus I prefer to leave the section about RTT console connection over telnet.
Moreover the link does not give any useful information except KConfig entry description :)

[kartben]

@erwango please revisit