| Electronics > Projects, Designs, and Technical Stuff |
| uSupply Firmware Released |
| << < (8/11) > >> |
| Dave:
--- Quote from: EEVblog on May 28, 2020, 05:47:53 am ---I don't need different filters, I don't need code re-use for other projects, I just needed 7 lines of code to get a simple job done. --- End quote --- Right, exactly what I said at the end of my post. --- Quote from: Dave on May 27, 2020, 11:14:11 pm ---Making things modular may not be strictly necessary in small pieces of code, like just testing some proof of concept with a couple hundred lines, but it is absolutely crucial in larger projects. --- End quote --- |
| Jeroen3:
Well, the thing is that developers write code to handle change of requirements. So from programmers point of view I think there are three major objectives: 1. The code must pass the tests (aka the requirements). 2. The code must allow change of requirements at low cost. 3. The code must be maintainable, other people need to be able to read it. To try and make this easy we have invented Object Oriented Programming and design patterns to use to conform to the solid rules. What we call "DaveC" here only passes requirement 1. And requirement 3 for the first few weeks. After 2 iterations of rule 2 and it's too big. Read up on "why software fails". Now the problem here is that many embedded software developers are also electrical engineers used to making hardware. Changes to hardware are always expensive. So changes are less common. Also the embedded software is often named firmware. Firm isn't hard, but also not soft. It's in between. It's perfectly fine to write a small bit of code that makes a chip do a simple job and to never change it again. Your quarts watch for example. There DaveC is perfectly acceptable if you can test it. It's another thing to write a reasonably chunk of code doing a simple job fow now with the idea to later improve upon it. Your Apple Watch. This is in my opintion the biggest weak spot of the embedded world. Many people who write code for embedded are not career developers. And many career developers do not know how to write code that works on embedded. With the above shown "figh" about the "best code". However, compared to the target audience, I can see the concern here. The uSupply with this architecture isn't a project average joe who bought an arduino can get on with. But does it need to be? (3 is unfortunately largely forgotten by many people) I'm currently developing in Qt C++. And it's hard, as embedded engineer. With Qt you are forced to comply to SOLID and design patterns. Trying "DaveC" fails after about 5 features. |
| SiliconWizard:
--- Quote from: EEVblog on May 28, 2020, 05:43:13 am --- --- Quote from: SiliconWizard on May 27, 2020, 02:01:41 pm ---That's one more reason the choice of using C++ in this project, at least the way Dave used it, was probably not a good idea. Days of delay for tools issues - that's OK. But weeks? You were probably not in a big hurry at the time, and wanted to give him maximum autonomy, but as a manager, you should probably have made a couple decisions to limit useless delays. --- End quote --- Such a decision is really only possible in hindsight. Each small problem is always presented/appears as being the "last hurdle". Then you have another one, and another one, and another one, and before you know it you are too far down the process to change direction. --- End quote --- Believe me, I know exactly what you're saying here! That actually defines a technical manager's job pretty well. We're confronted with that all the time. "Last hurdle"? Yes, I've heard that too so many times! ;D And with experience as a manager, you learn how to spot that and anticipate. Correctly monitoring the project will help not waiting until it's too late to change directions. It may not have meant rewriting everything from scratch either! I'm pretty sure using a simpler subset of C++ (which gets back to other discussions on C++ for embedded targets) would have been enough to get out of the rut without Dave 2 having to change all his code base or switch to pure C. Not using the problematic C++ constructs would have been enough, and probably not *that* difficult to do. He may have "wasted" one week instead of several without moving forward. Now his insisting on still using them while it made him waste weeks, that wasn't good. Hopefully, he's learned a few things along the way! That's IME one of the hardest parts of tech management. Sometimes you need to make the decisions for others, even when your engineers are swearing they know what they're doing and basically ask you to leave them alone. Interestingly, if you don't make the required decisions (even when they are hard to make), your engineers (at least some of them) will end up resenting you! As a manager, you're expected to make decisions and give them guidance - which is hard to do, because right when you do that, they will usually try their best to argue you're being wrong. Just sharing my 2 cents of experience here. ^-^ |
| VEGETA:
what about the hardware circuit? < million dollar question for +10 years xD |
| uer166:
--- Quote from: VEGETA on May 28, 2020, 10:10:43 pm ---what about the hardware circuit? < million dollar question for +10 years xD --- End quote --- Don't care for the USB whatever, but I really would like to see the video about the design of that planar transformer and the actual converter itself in detail. |
| Navigation |
| Message Index |
| Next page |
| Previous page |