SPI master and slave development time - Page 1
Forum section: electronics / general

author: ricko_uk
author_rank: Super Contributor
timestamp: June 09, 2020, 02:21:52 pm
content: Hi,I know this is a bit of a vague "how long is a piece of string" question but would appreciate any reasonable feedback which might give me at least a vague clue...Strictly on the coding side (i.e. without accounting for testing) if two coders in separate locations have to develop I2C/SPI type of comms protocol (assume a medium complexity - I know vague gain) would it be faster for each of them to code it separately of for a single coder to develop both parts?I was thinking that perhaps is a single coder develops both sides he might reuse some or most of his code? Is that correct or would he be only able to reuse very little code?Apologies again for the vague question but with the current infos I have that's the best at the momentThank you

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: June 09, 2020, 02:37:33 pm
content: Absolutely faster for the same person doing both ends. No arguing over specs, what happens if they don't communicate, different interpretations of ambiguous specs etc.

author: andersm
author_rank: Super Contributor
timestamp: June 09, 2020, 02:46:06 pm
content: Two people will always argue about who is right, so my suggestion is to add athirddeveloper to the project.

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 09, 2020, 03:27:34 pm
content: Quote from: andersm on June 09, 2020, 02:46:06 pm

author: tggzzz
author_rank: Super Contributor
timestamp: June 09, 2020, 03:28:53 pm
content: With two developers/companies working on one project, theremust be a boundarybetween the two pieces of work somewhere or other. That's a standard problem.The standard solution is to specify the interface, and then each developer/company implements against that interface.The issue is then ensuring the interface is suitable and is understood unambiguously. But that's a standard issue everywhere in development, unless you are just assembling predefined compatible components.So, where is it easiest to create a specification? At the SPI boundary which is accessible to standard test equipment, or between two arbirtary blobs of code in an arbitrary language in an arbitrary execution environment?Personally, unless there are good reasons to think otherwise, I'd specify the voltages, the timing, the bitstream/packet formats, and the semantics of the messages contained therein. Using SPI might make it easy to specify some of those points.

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 09, 2020, 03:43:21 pm
content: It's almost impossible to answer that general question. It all depends on many factors, including whether the protocol is already defined and 100% accepted by both parties or not, how the two developers work together, how good they are, how complex the protocol is, etc.If your metric is strictly about development time, and the protocol is not too complex, a single developer will probably be more efficient overall. If the protocol is not 100% defined yet, even more so.But there are definitely other factors (that you are not considering here since you only talked about time).As you mentioned, code reuse is one of them. Of course there's bound to be a significant amount of common code between transmitting and receiving unless the protocol is very trivial. So not writing that twice saves time and brings consistency. But there are also arguments in favor of a separate code base: for instance, this way you're more likely to find inconsistencies in the protocol itself (whereas any inconsistency or ill-defined part of the protocol might become "hidden" if you're a lone developer as you will just tend to write code that makes both ends communicate, while maybe neglecting the specs. Developing separately allows to mitigate this.) Testing will also be more relevant overall if you add developers. You're more likely to find bugs.Of course despite the benefits of working as a team, this is an art in itself and can bring a lot of frustration.

author: ricko_uk
author_rank: Super Contributor
timestamp: June 09, 2020, 04:16:41 pm
content: Thank you all!!SiliconWizzard, perhaps I should have worded/centred my original question more around pros and cons of 1 vs 2 developers...Thank you all again for the feedback despite the "vagueness" of my original post

author: mfro
author_rank: Regular Contributor
timestamp: June 09, 2020, 04:27:45 pm
content: That entirely depends on the detail level and completeness of the specification.If it's comprehensive, both developers can work independently on their part, ideally without much communication needs, if it's nonexistent, more than one developer will certainly slow down the project considerably or even make it fail (without any guarantee that one single developer won't deliver a bycicle when you meant a Saturn V).

author: NorthGuy
author_rank: Super Contributor
timestamp: June 09, 2020, 09:44:44 pm
content: I think one developer will do faster and better.When it comes to the communication protocol, it's much faster to develop when you can test against other side - say it's much easier to develop Web browser when you already have a Web server, and it would take much longer and would be much harder without it. If you develop both sides, you would have to switch between sides very frequently, to make sure you always have something to test against. Coordinating this activity between two different sites would slow down the progress tremendously.If the protocol already existed, then two people would do better. Say, if you wanted to develop a Web server and Web browser, two people would do it faster, because they could do it independently and in parallel.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 09, 2020, 09:55:33 pm
content: Yeah, if a standard exists, anyone can implement it, and test against that standard -- when they meet in the middle, it should Just Work(TM).The trouble with creating your own standard is, you inevitably won't be able to think through the entire thing, to enumerate fully all its functions, implementations and shortcomings. As those are discovered during implementation, you'll need many back-and-forth meetings to synchronize those changes. One person (or if it's more advanced, one team) can do all that, by themselves, much more quickly, with far less added time (meetings) and duplicated effort (reworked/refactored implementations).Tim

author: ricko_uk
author_rank: Super Contributor
timestamp: June 09, 2020, 10:09:00 pm
content: Thank you Tim, NorthGuy and mfro

author: lawrence11
author_rank: Frequent Contributor
timestamp: June 11, 2020, 06:43:59 pm
content: Careful, those terms will soon be politicaly incorrect to use.

author: ETITsynthesizer
author_rank: Contributor
timestamp: June 12, 2020, 02:13:53 pm
content: if you are in a time crunch then you definitely want two people on it. it will cost more but it will get done. the first one to start working sets the standard and shares it over to the other programmer. just an image or PDF. the other guy picks it up and implements it. simple. add random jitter to the device under test. see how much abuse it will take in the real world. design software tests that expose all the failure modes so that they can be documented and defined. then add that to the standard you started with or fix whatever is broke.