Please download images to give correct formatting OR Click here for on-line graphical version
Phaedsys Banner
Cost effective Safety Critical and High Reliability Embedded Systems Tools
 | Coder or developer? | SW Licenses | whose code? Whose liability? |  Case studies |
| Project management book | Device Developer conference | Embedded Muse|
Visit us online
A relatively sort newsletter this time as we catch up after the Easter break
and there are only 255 shopping days left until Christmas (there is a web site for it!). But there are a couple of things from the web that are worth thinking about and some information from Percepio that we wanted to share with you.
 
Also an advance notice for an item in the next newsletter that you wont want to miss.
PhaedruS SystemS
Coder, programmer or developer?
With the current obsession with teaching everyone to code, it was interesting to read a response on Quora, the question and answer website.  Replying to a question about whether coders who win coding competitions find it easier to get a job with Google, Facebook etc, Aideen NasiriShargh, who has won these competitions and also worked for Google, makes an inserting and thought provoking distinction between a coder, a programmer, and a developer. (see link here)

Coders, in his view solve small, standalone problems, but their code may not last well, may not be readable by others, and may not be maintainable. They are temperamentally averse to re-using other people's code from libraries or elsewhere, and they often not team players.

While I would discriminate between writing code and being a software engineer, it comes down to the same issue: the emphasis on writing code gets in the way of the real task, solving a problem using an engineering approach. Brick layers don't design buildings, mechanics don't design aircraft…
Licensed to sell?
Richard Quinnell has an interesting article in EDN on the potential problems that licensing terms offer for open source. He points out, rightly, that the difference between open source and proprietary software lies in the license terms, and goes on to discuss the many different forms of open source licenses that exist and discusses the restrictions, and often mutually exclusive restrictions, they may place on a developer. He also looks at the options that a developer has for licensing their open source code. It is a good starting point when thinking about these issues. See Link here

What he doesn't look at is the multitude of licenses associated with proprietary software. While these are designed for commercial use and can be less restrictive than you may think, there are some that have "interesting" restrictions. Licenses are licenses and you really should read them all carefully. You can't assume that just because it is "Open Source" or "proprietary" it is going to fall into one mould or the other.
Automotive software:- who owns it?
Moving on one step from software licenses  EFF is fighting for vehicle owners rights  to inspect the code that runs their vehicles and to repair and modify their vehicles, or have a mechanic of their choice do the work Is this really a good idea? I am not a lawyer, but it seems to me that Toyota would, in their recent court case(s), need only to show that "someone" had altered the code and it was not their responsibility that the behaviour of the car had changed.
 
Most accidents involve a 3rd party and 99.999% of automotive insurers require you to tell them of any modifications. They may not accept them, especially if you tell them after the change. In turn they may not pay out whatever the cause of an accident. Any one changing the source had better have very good public liability and professional indemnity insurance as the court costs in the Toyota case are reputed to be in the millions of USD. 
How users find Tracealyzer
Percepio's Tracealyzer lets you look inside your RTOS. It is a powerful tool with a huge range of applications. The company has gathered together some case studies and user comments, which are on our web site.
Case 1: Variant reader times A task should have read a sensor every 5 ms, but it wasn't, instead there were serious variations in the timing. Tracealyzer discovered that another task was unnecessarily disabling interrupts. Read more here.
 
Case 2: Random resets. A system was randomly resetting, which appeared to be caused by a watchdog timer expiring instead of being regularly rest. Using Tracealyzer, it was possible to identify that a small change in priorities of two tasks would keep the watchdog fully functional. Read how this was discovered here.
 
User comments stress the way in which the Tracealyzer screen provides understanding of complex problems and documentation for system maintenance. See more of them here.
Software Projects: Big Bang or Evolutionary
For the next newsletter we will have news of a book on Software Project Management written by an experienced author that looks at Big Bang vs Evolutionary development.

The good news is that as Phaedrus Systems will be publishing this and it will be available on free download to readers of the newsletter!  So make sure you read the next newsletter.
Device Developer Conference
DDCAnother plug for the Device Developer Conference. As you know we are great fans of good conferences and exhibitions, and Device Developer is good. This year it is on the 12th & 14th of May, and the 2nd and 4th of June, in Reading, Cambridge, Manchester and Uphall (Scotland). We will be exhibiting and presenting, a paper. Is it supposed to do that? We are also once again promoting the Programming Research's Developers' Challenge, with a prize of Kindle Paperwhite. More details and booking information is on the website http://www.device-developer-conference.co.uk/
This time We are pleased to tell you that after regularly talking about Jack Ganssle's Embedded Muse Newsletter  he has repaid the complement.
 
He has published my views on programming discipline and MISRA C in issue 281. There was also a mention of creative "artists" versus discipline. A musician doesn't just pick up an instrument and play. Their ability to be skilful comes from years of practice of methods and techniques. Art? Usually but always a discipline.
 
See you at Device Developer?
Forward this email
Forward
 
Tel: 0808 1800 358Email usVisit us online
PhaedruS SystemS Ltd, 96 Brambling, Tamworth, Staffs, B77 5PG, UK
Registered in England with Company Number 04120771
learn more about  newzapp email marketing This message was sent to by PhaedruS SystemS Ltd using newzapp email marketing. Follow this link to Unsubscribe.