What board ID number to use?

[blurfl]

I'm working on another board version, and I need to choose a version ID code that doesn't clash with any other project. I've provisionally used v1.5 thinking that by skipping one I would be safe. When @MarcinanBarbarzynca came up with a board that used ID v1.4, that didn't conflict. 👍
I can stick with v1.5, leaving v1.4 for @MarcinanBarbarzynca's second board project. That will leave a gap in the sequence - how does the community feel about that?
One reason to stake a claim on an ID number is that circuit boards get strapped for that number and it's a pain to cut/patch the PCBs after they are made.

[BarbourSmith]

Way to be considerate of others!

I vote for taking v1.4, if you are ready to take it now. That way we won't have any skipped numbers which might confuse folks.

I think we should do a first come first served basis for pull requests merged into master so if you want to lock down a number just make a pull request to master with the pins you want to use.

[davidelang]

On Wed, 22 May 2019, Scott Smith wrote: I'm working on another board version, and I need to choose a version ID code that doesn't clash with any other project.

what is it about your board that is going to require a unique ID? If it can be made pin compatible with an existing board, that would be good. We had a couple versions of the board from Bar because he found that different pins worked better for PWM, and then we had another version because the directiion controls worked differently (IIRC originally it was Enable_dir_1, Enable_dr_2 and the new chip with Dir, Enable), if your new board can fit either of these schemes, can we use the same ID? if not, what is different? David Lang

[blurfl]

Presently we have boards with the L298 motor driver that use three input pins to control it (one for master enable and two for individual output state - any of the three could act as the PWM signal) and boards with the TLE5206 that only has two control inputs, and chooses direction and speed by putting those in opposite states and putting a PWM signal on one of them.

what is it about your board that is going to require a unique ID?

The TLE5206 is being sunsetted, and the replacement is the TLE9201. That chip has yet a different control arrangement - simpler but different enough that it needs separate handling. It has one dedicated PWM input, one dedicated DIRection input, and one ENAble input. PWM, DIR, ENA is a more common control scheme for motor drivers, so it's possible that future boards that drive separate motor driver boards would be able to use this configuration. The TLE9201 is rated for 6A continuous and runs in chopper mode at currents above that. It can handle PWM up to 20kHz (much better than the 1kHz of the TLE5206). It tri-states the outputs if it senses over-temperature, and flags the error.

The board uses gpio pins from the Mega XIO connector to increase the number of AUX pins to 9, three of which have hardware PWM (PWM for spindle speed would be possible) and two of which can do analog input as well as digital IO. It also frees up the SPI pins though it doesn't use them - the Mega seems busy enough already. Finally, it has an on-board EEPROM, buffers on the encoder lines and automatic voltage selection so it is hardware compatible with the MaslowDue project. (It runs a branch of that code on a Due, but needs someone with more PID-fu than I possess to tune the loop make it purr instead of growl. I'll send a board to someone serious about working on that. ;) DM me.)

[davidelang]

Thanks, that answers my question about the difference. seems to me that 1.4 should be good. When you add this, please add comments about the differences between the boards (almost exactly what you put in this post is good), possibly with an explination for the next board developer as to what they would need to do to justify using a differentboard ID David Lang On Wed, 22 May 2019, Scott Smith wrote:

…

Presently we have boards with the L298 motor driver that use three input pins to control it (one for master enable and two for individual output state - any of the three could act as the PWM signal) and boards with the TLE5206 that only has two control inputs, and chooses direction and speed by putting those in opposite states and putting a PWM signal on one of them. > what is it about your board that is going to require a unique ID? The TLE5206 is being sunsetted, and the replacement is the TLE9201. That chip has yet a different control arrangement - simpler but different enough that it needs separate handling. It has one dedicated PWM input, one dedicated DIRection input, and one ENAble input. PWM, DIR, ENA is a more common control scheme for motor drivers, so it's possible that future boards that drive separate motor driver boards would be able to use this configuration. The TLE9201 is rated for 6A continuous and runs in chopper mode at currents above that. It can handle PWM up to 20kHz (much better than the 1kHz of the TLE5206). It tri-states the outputs if it senses over-temperature, and flags the error. The board uses gpio pins from the Mega XIO connector to increase the number of AUX pins to 9, three of which have hardware PWM (PWM for spindle speed would be possible) and two of which can do analog input as well as digital IO. It also frees up the SPI pins though it doesn't use them - the Mega seems busy enough already. Finally, it has an on-board EEPROM, buffers on the encoder lines and automatic voltage selection so it is hardware compatible with the MaslowDue project. (It runs a branch of that code on a Due, but needs someone with more PID-fu than I possess to tune the loop make it purr instead of growl. I'll send a board to someone serious about working on that. ;) DM me.)

[blurfl]

add comments about the differences between the boards

Where in the firmware is that appropriate? It's got little to do with the code. I think that info belongs in the board repo in the Electronics or CommunityGarden, as so.

[BarbourSmith]

Wow those sound like some exciting improvements 👍 👍 That chip also looks very nice. From a glace at the data sheet am I right that no flyback diodes are needed?

[blurfl]

no flyback diodes are needed?

That’s right , ‘built in’.

[BarbourSmith]

That's a nice feature. It keeps the part count and cost down, but more than that it frees up a lot of board space.

[BarbourSmith]

$2 at large quantities too. Here is the digikey link https://www.digikey.com/product-detail/en/infineon-technologies/TLE9201SGAUMA1/TLE9201SGAUMA1TR-ND/5960696

[blurfl]

Compact and cheap, aimed at the auto market. They do need to be protected from having reversed voltage applied to the supply so there are a few components added there.

[BarbourSmith]

I've found that things aimed at the auto market are rock solid because recalls are expensive there. If it could measure current too it would be perfect.

[davidelang]

On Wed, 22 May 2019, Scott Smith wrote: Where in the firmware is that appropriate? It's got little to do with the code. I think that info belongs in the board repo in the Electronics or CommunityGarden, as

it's good to have it in the board design repo, but I would put it in the firmware in the section that decodes the board version as well. David Lang

[esspe2]

Am I the only one to be confused about TLE5206 boards numbering ?
System.cpp already talks about V1.4,
and V1.1 ... V1.3 mean no TLE5206:

Firmware/cnc_ctrl_v1/System.cpp

Line 288 in e7ae77d

TLE5206 = false;

And @blurfl showed a link to a V1.4 TLE5203 board.

So my vote would go to "V1.5" for TLE9201 boards and there is no V1.4 gap, or am I missing something?

[blurfl]

No, I screwed up with the TLE5206 silkscreen 😳. It should say 'v1.3' on the TLE5206 silkscreen. GC correctly reports 'PCB v1.3'

[GeroBH]

Sorry for the noob question, what is the difference to Bee's shields labelled v1.4?
I think they are based on or forked from @blurfl 's shield.

[blurfl]

what is the difference to Bee's shields labelled v1.4?

I have a hunch that Bee used the same silkscreen file that I did, so he would have inherited my mistake. When you start up GC, does it report "PCB v1.3 TLE5206 Detected"? That would confirm my hunch.

[GeroBH]

I'm still running a generously donated one of the first @blurfl 's TLE shields.
I built one of Bee's and tested it before sending it to Spain.
I did not pay attention to the report. Would have to solder one to see, but your explanation sound solid.

[blurfl]

The consensus seems to be that Board ID 4 is the best choice - I'll use that. 👍

[BarbourSmith]

I support that plan 👍 👍

[esspe2]

Still not convinced because of the evident conflict on line 290 :

Firmware/cnc_ctrl_v1/System.cpp

Line 290 in e7ae77d

case B110100: case B000100: // some versions of board v1.4 don't strap VERS5-6 low

[BarbourSmith]

Hmmmm yeah I didn't know about that. Are there a lot of those boards out there?

[blurfl]

Still not convinced because of the evident conflict on line 290

Not sure exactly which of the several conflicts you've spotted in that line, but I'll have a go at it.

• "...some versions of board v1.4..." - In laying out the silkscreen for the TLE5206 board I stumbled over the zero-based/one-based thing and those boards have the wrong board number in their silkscreen. They should have been silkscreened "v1.3". They're correctly strapped for v1.3 and identify as v1.3 boards in the firmware and GC.

• "don't strap VERS5-6 low" - The first layout of the TLE5206 boards only used four ID pins. While working on the firmware subsequently, I saw that having more ID pins would be beneficial and added provision for two more. I updated the files in the CommunityGarden (Bee's boards use 6 ID pins) but I had previously sent some boards out to testers and didn't want the release firmware to bork those boards. A software fix to a hardware issue.

Are there a lot of those boards out there?

If we're talking about the silkscreen issue, I would guess that most TLE boards are mis-labelled.
If we're talking about the "don't strap VERS5-6 low" issue, there are fewer than ten, but I didn't keep track of who has them.

[esspe2]

So could we say that v1.3 / v1.4 are just 2 different names for the same boards ?

Then maybe this arrangement would make everyone happy;
it follows the checks of getPCBVersion() and takes into account the silk numbering:

*     "x" = not used
*     #53-#52    #27-#26  #25-#24  #23-#22
*     -------    -------  -------  -------
*     GND GND     PU PU   PU  PU   GND PU  -> rev.0001  PCB v1.0 aka beta release board
*     GND GND     PU PU   PU  PU   PU  GND -> rev.0002  PCB v1.1
*     GND GND     PU PU   PU  PU   PU  PU  -> rev.0003  PCB v1.2
*      x   x      x   x   GND PU   GND GND -> PCB v1.3 and 1.4 TLE5206
*      x   x     GND GND  GND PU   GND PU  -> reserved for PCB v1.5

And the comments of line 290 would be like that (correct me if I'm wrong):

    // boards v1.0, v1.1, v1.2 don't strap VERS3-6 low
    case B111101: case B111110: case B111111: // v1.0, v1.1, v1.2

instead of that:

    // boards v1.1, v1.2, v1.3 don't strap VERS3-6 low
    case B111101: case B111110: case B111111: // v1.1, v1.2, v1.3

(still advocating my suggestion ;-) at least I feel that it follows the reality.

[blurfl]

I'll change the PR #505 to incorporate your suggestions:

*     "x" = not used
*     #53-#52    #27-#26  #25-#24  #23-#22
*     -------    -------  -------  -------
*     GND GND     PU PU   PU  PU   GND PU  -> rev.0001  PCB v1.0 aka beta release board
*     GND GND     PU PU   PU  PU   PU  GND -> rev.0002  PCB v1.1
*     GND GND     PU PU   PU  PU   PU  PU  -> rev.0003  PCB v1.2
*      x   x      x   x   GND PU   GND GND -> PCB v1.3 and 1.4 TLE5206
*     GND GND     GND GND GND PU   GND PU  -> reserved for PCB v1.5

(Edit - PCB v1.5 should correctly ground VERS5 and VERS6)
and

Carrying your comment further, how about making that code block (lines 284-294) something like:

    switch (pinCheck) {
        case B111101: case B111110: case B111111: // PCB v1.0, PCB v1.1, PCB v1.2
        // boards v1.0, v1.1, v1.2 don't strap VERS3-6 low
            pinCheck &= B000011; // strip off the unstrapped bits
            TLE5206 = false;
            break;
        case B110100: case B000100: case B110101: case B000101: 
        // some boards strapped Bxx0100 are silkscreened in error as "PCB v1.4"
        // so all boards strapped Bxx0010x will all enumerate as "PCB v1.3"
        // some versions of board silkscreened "PCB v1.4" don't strap VERS5-6 low,
            pinCheck &= B000111; // strip off the unstrapped bits
            TLE5206 = true;
            break;
    }

I've checked this on the various flavors of TLE5206 PCBv1.4 board and they all still enumerate and operate properly as "PCB v1.3" as they did before. How far do you want to take this? Do we need to special-case the print statements in cnc_ctrl_v1.ino to agree with the silkscreen?

[esspe2]

Sounds very good!
I would still leave #53-#52 pins unused to free the SPI following what I have read not long ago
(while I don't see really any usage for it: flashing is made by arduino serial, so one would only need it to change the bootloader, better without any shield, so... )

As for the case, you may prefer make a new one for your board: you know VERS5-6 are low, so no need to strip any bits, and I don't know about any incompatibilies between TLE5206 and TLE9201 which could need some coding.

Hidden gem: starting with v1.5, pin numbering matches version numbering, we are good at least until v1.15! After that some creativity will be necessary.
But for that, return pinCheck<5 ? pinCheck-1 : pinCheck;, in getPCBVersion()
to be discussed, of course!

[esspe2]

... as for cnc_ctrl_v1.ino, the version should appear correctly as is, or, again for the fun:

Serial.print(getPCBVersion()==3 ? "3/1.4" : getPCBVersion() );

(Not tried yet, but should give v1.3/1.4)

[blurfl]

I would still leave #53-#52 pins unused

I noticed that a bit ago and pushed yet another commit to do what you say. {Check it out.](3838d92)

As for the case, you may prefer make a new one for your board: you know VERS5-6 are low, so no need to strip any bits, and I don't know about any incompatibilies between TLE5206 and TLE9201 which could need some coding.

The TLE9201 board needs separate handling, so a unique ID.

Many good ideas here, I'm going to close PR #504 until the discussion reaches consensus.

[BarbourSmith]

I don't think there is a big need to conserve board numbers, because I would like to move away from the Mega to something smaller and more powerful in the future which would come with a new footprint and a new system for board ID. I'm thinking that is six months away, but I don't think we'l run out of version numbers before then

[blurfl]

return pinCheck<5 ? pinCheck-1 : pinCheck;

That works fine. I would argue that it's less readable than an expanded if..else block to less experienced contributors, but maybe this is where they learn a new thing.

For announcing the board in cnc_ctrl_v1.ino, how about something like

    int boardVersion = getPCBVersion();
    if (boardVersion <= 2) {
        Serial.print(F("PCB v1."));
        Serial.print(boardVersion);
        Serial.println(F(" detected"));
        } 
    else if (TLE5206 == true) { // boardVersion may be 3 or 4, but TLE5206 will be true
        Serial.println(F("TLE5206 board detected"));
        }

That sidesteps the silkscreen issue, and will be easy to extend for future boards.

smaller and more powerful

Hints? Enquiring minds...

[esspe2]

OK for readability against compactness!
I also hoped to reduce confusion starting from the v1.5 by matching with the binary value of PORTA[5..0], ready for the 10 next revisions.

Will the 'smaller and more powerful' board use the same port? curious to know.
Also thinking that major revisions could be used for incompatible changes, maybe 2.x for that.

For announcing the board in cnc_ctrl_v1.ino, 

Yes, more readable, don't forget to foresee next revisions: how will you announce yours, just by the number or with the driver name TLE9201, and what will be next...

[blurfl]

matching with the binary value of PORTA[5..0]matching with the binary value of PORTA[5..0]

While this would be true, wouldn't using low-level access to the pins would make it harder to port to other processors? The board ID function doesn't need the speed. Take a look at the GrandCentralM4, much faster and mostly pin compatible. It doesn't have a developed version of the TimerOne library though, that's the major hurdle to cross (also wants a change to the Maslow EEPROM routines). Your comment about PORTA suggests you've been interested in port-level programming, maybe take a look at the timers for the SAMD51 and the GrandCentral board?

[esspe2]

No worries, portability is more important of course, just seeing how well VERS1..VERS6 were designed.
The GrandCentralM4 is a completely different board, very promising but I know nothing about SAMDs; if I find something useful I'll talk about it though.
Hopefully it will have something like TimerTen ...