7 ms·

I had an intern do something similar with an electromechanical machine. I'd all but written the equations out for him but he found drawing it out in Simulink i

I had an intern do something similar with an electromechanical machine. I'd all but written the equations out for him but he found drawing it out in Simulink in the most fundamental, primitive blocks to help him understand what was going on . I don't get it either. A related phenomenon seems to be people who don't want to "wire up" schematics but attach named nets to every component and then draw boxes around them.

tonyarkles 2y ago
> people who don't want to "wire up" schematics but attach named nets to every component and then draw boxes around them Lol there are a few things that I am highly intolerant of and this is one of them. The only place where I'm generally ok with that approach is at the input connectors, the microcontroller, and the output connectors. Same philosophy as I said before though: "if it brings clarity draw it as a wired up schematic; if it turns into a ratsnest use net labels to jump somewhere else". Having every component in a separate box with net labels will generally obscure what's going on and just turns it into an easter egg hunt.
- buescher 2y ago
  Also, part of the style seems to be to contort any actual schematic to fit in the box. I like to ask "if you wouldn't put it on its own page so you could draw it clearly, why did you draw a box around it?".
- foldr 2y ago
  I don't really get this point of view. Take an I2C bus, for example. Isn't it easier to read the schematic if all the components on the bus have two pins connected to wires labeled 'SDA' and 'SCL'?
  - tonyarkles 2y ago
    Yeah, there’s a balance here. There are common nets like SDA, SCL, GND, VCC that make sense to have as global nets. And then there’s actual circuits where it makes more sense (for understandability) to not do it like that. Here’s an example that I think takes it too far: https://cdn.sparkfun.com/datasheets/Dev/LilyPad/LilyPad-MP3-v15a.pdf https://cdn.sparkfun.com/datasheets/Dev/LilyPad/LilyPad-MP3-... - The audio jack (line level) could have just sat to the right of the codec and been directly connected to it to make it clear that it’s just a direct output - the speaker amplifier could be directly connected to the audio jack as well. I spent a lot of time looking around to figure out where it actually connects to; I figured it would have its input connected to the MP3 codec and didn’t realize that it would be connected through the micro switches inside the headphone jack (which makes sense now that I see it) - the SD card slot could either be connected directly to the codec or could have better names on the nets. When I see MOSI, MISO, and SCK I assume that they’re connected to the main MCU. Even more confusing, there’s an SD-CS that is connected to the MCU but not the rest of the SPI pins Overall I’d probably give this one a B. It’s by no means the most egregious I’ve seen but it also obscures the signal flow pretty badly. Other things I would probably consider doing: - better clustering of pins on the MCU by function. The switch inputs and LED outputs that connect to the rotary encoder are all over the place. Most tools allow you to move the pins on microcontrollers around at will - the FTDI block could move onto the first page. The DTR pin could use a bit of explanation that it’s tied to the reset circuit. Not their fault in this one but the naming inconsistency between FTDI-RXI and TRIG4/TXO is confusing until you figure out that the pin is meant to be either a GPIO or a UART pin. The name doesn’t make it clear that it goes to the FTDI chip because it’s inconsistent with the rest of the FTDI-xxx names but that’s because most ECAD programs handle net names poorly anyway Edit: one more thing that really bugs me about this schematic: the Vbatt net leaving J1. It’s labelled but not with any kind of flag or loose/unterminated line that would indicate that it’s connected to the net leaving U2. And further with that, the fact that VIN on U2 comes only from the FTDI connector on the second page (I think…)
    - buescher 2y ago
      All good points. By the way, yes, if you have one peripheral device on an i2c bus, and your design is small enough that you're drawing the device on the same page as your microcontroller, you should make the connection explicit. My two cents: - Making the power routing completely implicit is another hallmark of the style and it drives me crazy too. The power, charging, and maybe FTDI boxes should all be together on one page. Now, I might change my mind about this in six months, but I am starting to warm to the idea of drawing a power tree for even pretty simple power schemes like this one. The power tree style in the Arduino documentation is pretty nice - In the same vein, even modest designs usually benefit from a block diagram up front. You don't need to use hierarchical design functions - just boxes and arrows and text done with the drawing tools of the CAD program - I like that they actually did put most of the "bookkeeping" connections on the left side of the micro. I'd move the UART pins over to that side too, and the programming port. The programming port belongs with the micro and nowhere else, would you put it on its own page? - Audio signals flow right to left to down for no particularly good reason except to get all the other boxes to fit on the second page. All the audio could be on its own page - Similarly, LED signals come in to the rotary encoder on the right and encoder signals come out on the left. Really? - I like that they grouped the bypass capacitors with the ICs but for these modest numbers of bypass caps I prefer to see them shown connected to the pin pairs they'll be placed by - OK, not a schematic point and not critical for a hobbyist product but powering the battery charger from USB is a potential issue. Low line by spec on USB is 4V at the connector, and you won't get 4.2V out of that with a linear charge controller. They might also be exceeding maximum effective capacitance on the USB power bus. Again, not critical for a low-volume "maker" product - it will always work except when it doesn't - No off-page connectors for off-page connections. I like to see the pages called out that an off-page connector connects to, but I admit that's a pain to do by hand - The pull-ups and pull-downs in the top right hand corner of the second page are typical of the style. Who ever heard of connecting these directly to the pin that needs them? Again, it looks like this was done to fit the subcircuit in the box
      - tonyarkles 2y ago
        > I am starting to warm to the idea of drawing a power tree for even pretty simple power schemes like this one I'm laughing/crying right now because of a board I had to deal with last week at $JOB. Pretty beefy power distribution board with some... quirks related to load shedding etc. Details don't matter there. I ended up drawing the whole power graph (it's not a tree, there are two independent inputs that go through ideal diode controllers for some of the rails for redundancy). By carefully rearranging the nodes of the graph I managed to get it completely planar (no overlapping edges) except for one spot where a poorly-thought-out connector did require one edge overlap. Laying that out as a planar graph dramatically simplified routing. It's a technique I hadn't explicitly used before and it sure worked out nicely.
  - bobmcnamara 2y ago
    Sometimes, and it depends what you're trying to convey. Take a system with multiple I2C devices - with each device on a different sheet, it becomes difficult to tell that you might have bus contention issues.
    - foldr 2y ago
      Is it? You can just count the number of devices connected to the I2C bus. That seems easier than if you had to follow a bunch of tangled lines.
      - bobmcnamara 2y ago
        > You can just count the number of devices connected to the I2C bus If everyone working on it has the software, they can count easily and accurately. When I started and still sometimes today "just counting the number of devices" requires visiting each sheet of the schematic, then hoping you didn't miss one. > That seems easier than if you had to follow a bunch of tangled lines. Today's software will let you draw a single bus connection between all bus devices. > That seems easier than if you had to follow a bunch of tangled lines. The problem is generally that if you choose to put some things near each other, you're choosing to put other things further away. In many cases the I2C bus itself has little to do with what the I2C devices do, so by drawing a single I2C bus or pair connecting all the devices with splitting them up with a named bet, you're choosing to make those other things harder to show. This may or may not be appropriate for the design.
        foldr 2y ago
        >If everyone working on it has the software, they can count easily and accurately. Any IC on the I2C bus will have pins labeled SCL and SDA, so you can easily just go through all the ICs and count how many have those pins. It might be slightly tedious with a paper schematic, but it's hardly impossible. It still strikes me as easier than doing the same thing with unlabeled pins that are connected directly in the schematic to the UC's I2C pins. >In many cases the I2C bus itself has little to do with what the I2C devices do, so by drawing a single I2C bus or pair connecting all the devices with splitting them up with a named bet, you're choosing to make those other things harder to show. I don't quite understand what you're saying here. Labelling a pin with SDA or SCL makes it clear that it's connected to the I2C bus. What I'm saying is that I don't see any value in drawing a line connecting the pin to all the other SDA/SCL lines. That's completely independent of how you lay the schematic out or split it into functional blocks.
mst 2y ago
I think using the drawing it out process to understand initially is ... not how my brain would do it, but seems like a perfectly valid approach. But once you -do- understand it's time to stick that in a reference file out of the way and write it again properly for actual use.

tonyarkles 2y ago

> people who don't want to "wire up" schematics but attach named nets to every component and then draw boxes around them Lol there are a few things that I am highly intolerant of and this is one of them. The only place where I'm generally ok with that approach is at the input connectors, the microcontroller, and the output connectors. Same philosophy as I said before though: "if it brings clarity draw it as a wired up schematic; if it turns into a ratsnest use net labels to jump somewhere else". Having every component in a separate box with net labels will generally obscure what's going on and just turns it into an easter egg hunt.

buescher 2y ago
Also, part of the style seems to be to contort any actual schematic to fit in the box. I like to ask "if you wouldn't put it on its own page so you could draw it clearly, why did you draw a box around it?".
foldr 2y ago
I don't really get this point of view. Take an I2C bus, for example. Isn't it easier to read the schematic if all the components on the bus have two pins connected to wires labeled 'SDA' and 'SCL'?
- tonyarkles 2y ago
  Yeah, there’s a balance here. There are common nets like SDA, SCL, GND, VCC that make sense to have as global nets. And then there’s actual circuits where it makes more sense (for understandability) to not do it like that. Here’s an example that I think takes it too far: https://cdn.sparkfun.com/datasheets/Dev/LilyPad/LilyPad-MP3-v15a.pdf https://cdn.sparkfun.com/datasheets/Dev/LilyPad/LilyPad-MP3-... - The audio jack (line level) could have just sat to the right of the codec and been directly connected to it to make it clear that it’s just a direct output - the speaker amplifier could be directly connected to the audio jack as well. I spent a lot of time looking around to figure out where it actually connects to; I figured it would have its input connected to the MP3 codec and didn’t realize that it would be connected through the micro switches inside the headphone jack (which makes sense now that I see it) - the SD card slot could either be connected directly to the codec or could have better names on the nets. When I see MOSI, MISO, and SCK I assume that they’re connected to the main MCU. Even more confusing, there’s an SD-CS that is connected to the MCU but not the rest of the SPI pins Overall I’d probably give this one a B. It’s by no means the most egregious I’ve seen but it also obscures the signal flow pretty badly. Other things I would probably consider doing: - better clustering of pins on the MCU by function. The switch inputs and LED outputs that connect to the rotary encoder are all over the place. Most tools allow you to move the pins on microcontrollers around at will - the FTDI block could move onto the first page. The DTR pin could use a bit of explanation that it’s tied to the reset circuit. Not their fault in this one but the naming inconsistency between FTDI-RXI and TRIG4/TXO is confusing until you figure out that the pin is meant to be either a GPIO or a UART pin. The name doesn’t make it clear that it goes to the FTDI chip because it’s inconsistent with the rest of the FTDI-xxx names but that’s because most ECAD programs handle net names poorly anyway Edit: one more thing that really bugs me about this schematic: the Vbatt net leaving J1. It’s labelled but not with any kind of flag or loose/unterminated line that would indicate that it’s connected to the net leaving U2. And further with that, the fact that VIN on U2 comes only from the FTDI connector on the second page (I think…)
  - buescher 2y ago
    All good points. By the way, yes, if you have one peripheral device on an i2c bus, and your design is small enough that you're drawing the device on the same page as your microcontroller, you should make the connection explicit. My two cents: - Making the power routing completely implicit is another hallmark of the style and it drives me crazy too. The power, charging, and maybe FTDI boxes should all be together on one page. Now, I might change my mind about this in six months, but I am starting to warm to the idea of drawing a power tree for even pretty simple power schemes like this one. The power tree style in the Arduino documentation is pretty nice - In the same vein, even modest designs usually benefit from a block diagram up front. You don't need to use hierarchical design functions - just boxes and arrows and text done with the drawing tools of the CAD program - I like that they actually did put most of the "bookkeeping" connections on the left side of the micro. I'd move the UART pins over to that side too, and the programming port. The programming port belongs with the micro and nowhere else, would you put it on its own page? - Audio signals flow right to left to down for no particularly good reason except to get all the other boxes to fit on the second page. All the audio could be on its own page - Similarly, LED signals come in to the rotary encoder on the right and encoder signals come out on the left. Really? - I like that they grouped the bypass capacitors with the ICs but for these modest numbers of bypass caps I prefer to see them shown connected to the pin pairs they'll be placed by - OK, not a schematic point and not critical for a hobbyist product but powering the battery charger from USB is a potential issue. Low line by spec on USB is 4V at the connector, and you won't get 4.2V out of that with a linear charge controller. They might also be exceeding maximum effective capacitance on the USB power bus. Again, not critical for a low-volume "maker" product - it will always work except when it doesn't - No off-page connectors for off-page connections. I like to see the pages called out that an off-page connector connects to, but I admit that's a pain to do by hand - The pull-ups and pull-downs in the top right hand corner of the second page are typical of the style. Who ever heard of connecting these directly to the pin that needs them? Again, it looks like this was done to fit the subcircuit in the box
    - tonyarkles 2y ago
      > I am starting to warm to the idea of drawing a power tree for even pretty simple power schemes like this one I'm laughing/crying right now because of a board I had to deal with last week at $JOB. Pretty beefy power distribution board with some... quirks related to load shedding etc. Details don't matter there. I ended up drawing the whole power graph (it's not a tree, there are two independent inputs that go through ideal diode controllers for some of the rails for redundancy). By carefully rearranging the nodes of the graph I managed to get it completely planar (no overlapping edges) except for one spot where a poorly-thought-out connector did require one edge overlap. Laying that out as a planar graph dramatically simplified routing. It's a technique I hadn't explicitly used before and it sure worked out nicely.
- bobmcnamara 2y ago
  Sometimes, and it depends what you're trying to convey. Take a system with multiple I2C devices - with each device on a different sheet, it becomes difficult to tell that you might have bus contention issues.
  - foldr 2y ago
    Is it? You can just count the number of devices connected to the I2C bus. That seems easier than if you had to follow a bunch of tangled lines.
    - bobmcnamara 2y ago
      > You can just count the number of devices connected to the I2C bus If everyone working on it has the software, they can count easily and accurately. When I started and still sometimes today "just counting the number of devices" requires visiting each sheet of the schematic, then hoping you didn't miss one. > That seems easier than if you had to follow a bunch of tangled lines. Today's software will let you draw a single bus connection between all bus devices. > That seems easier than if you had to follow a bunch of tangled lines. The problem is generally that if you choose to put some things near each other, you're choosing to put other things further away. In many cases the I2C bus itself has little to do with what the I2C devices do, so by drawing a single I2C bus or pair connecting all the devices with splitting them up with a named bet, you're choosing to make those other things harder to show. This may or may not be appropriate for the design.
      - foldr 2y ago
        >If everyone working on it has the software, they can count easily and accurately. Any IC on the I2C bus will have pins labeled SCL and SDA, so you can easily just go through all the ICs and count how many have those pins. It might be slightly tedious with a paper schematic, but it's hardly impossible. It still strikes me as easier than doing the same thing with unlabeled pins that are connected directly in the schematic to the UC's I2C pins. >In many cases the I2C bus itself has little to do with what the I2C devices do, so by drawing a single I2C bus or pair connecting all the devices with splitting them up with a named bet, you're choosing to make those other things harder to show. I don't quite understand what you're saying here. Labelling a pin with SDA or SCL makes it clear that it's connected to the I2C bus. What I'm saying is that I don't see any value in drawing a line connecting the pin to all the other SDA/SCL lines. That's completely independent of how you lay the schematic out or split it into functional blocks.

mst 2y ago

I think using the drawing it out process to understand initially is ... not how my brain would do it, but seems like a perfectly valid approach. But once you -do- understand it's time to stick that in a reference file out of the way and write it again properly for actual use.