Searching \ for '[TECH] Code reuse for embedded systems' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=code+reuse+embedded
Search entire site for: 'Code reuse for embedded systems'.

Exact match. Not showing close matches.
PICList Thread
'[TECH] Code reuse for embedded systems'
2009\05\25@004406 by Vitaliy

flavicon
face
> Vitaliy wrote:
>> My point is, you can be more productive if you
>> can use code that has already been written,

Olin said:
> This is usually not true in my experience.  Most other code is crap, or
> wouldn't fit into my system nicely without more work then to write it the
> way I want from scratch.  Code re-use sounds nice in principle, but in
> practise I find it way overrated.

Isaac Marino Bavaresco responded with:
> It appears that 99.9% of the programmers think this way (me included),
> because of coding style or other subtle details. I try to get over such
> prejudices so I can use others code.
> There is a lot of bad code around, but there is a lot of good code also.
> If you get a nice piece of code, use it, or at least use it as a base to
> write your own.
> I save much time this way.

My experience with code reuse on embedded systems, falls into several
categories:


1. Standard C libraries. Typically they're plug-and-play, because they were
designed with reuse in mind by people who knew what they were doing. My
only complaint here is that sometimes it's difficult to remember which
function lives in which library ("is memcpy() in stdlib.h or string.h?"),
which means that the libraries aren't as cohesive as they could have been.


2. Microchip C libraries. Possibly some of the ugliest library code ever
written. Here's an excerpt from the 24F library docs, which shows the code
necessary to perform a very common, simple operation -- configuring and
opening the UART:

=========
/* Configure uart1 receive and transmit interrupt */
  ConfigIntUART1(UART_RX_INT_EN & UART_RX_INT_PR6 &
                 UART_TX_INT_DIS & UART_TX_INT_PR2);
/* Configure UART1 module to transmit 8 bit data with one stopbit.
  Also Enable loopback mode */
  baudvalue = 5;
  U1MODEvalue = UART_EN & UART_IDLE_CON &
  UART_DIS_WAKE & UART_EN_LOOPBACK &
  UART_EN_ABAUD & UART_NO_PAR_8BIT &
  UART_1STOPBIT;
  U1STAvalue = UART_INT_TX_BUF_EMPTY &
  UART_IrDA_POL_INV_ZERO & UART_SYNC_BREAK_DISABLED &
  UART_TX_ENABLE & UART_INT_RX_3_4_FUL &
  UART_ADR_DETECT_DIS &
  UART_RX_OVERRUN_CLEAR;
  OpenUART1(U1MODEvalue, U1STAvalue, baudvalue);
=========

After the nausea subsides, the natural reaction is to say "forget this, I'll
just configure the registers myself!"

Another approach is to hide this ugliness behind adapter functions, so the
code
above could be replaced with:

   Uart_Init();
   Uart_SetBaudRate(9600);
   Uart_Open();

Other ugly uChip functions can be dealt with, in the same way. The advantage
of this approach is that you can get a proof of concept, or even a fully
functional product, very quickly. What happens in our situation, is that the
Microchip code inevitably gets replaced, piece-by-piece, with our own code.
This improves readability, and as a side effect, increases performance and
reduces footprint.


3. Other people's (non-library) code. Depending on the quality of the code,
refactoring may get you where you want to be faster than if you had to write
the code from scratch.


4. Our "in-house" code. We practice the "tight cohesion, loose coupling"
rule, which allows code reuse with a minimal amount of effort. In fact, I
was surprised when it turned out that modules written for one project,
could be used in another project without _any_ modifications.

Note that the modules in question were not specifically designed for reuse.
We did not put any provisions "for future expansion", or made compromises to
make the modules "fit".


Code reuse is the king in the PC apps/Windows world. You get tons of
functionality without writing a single line of code: Windows takes care of
handling mouse clicks, drawing windows, buttons, text boxes, etc. There
are libraries of custom components to do virtually everything. They can be
dropped into your project, and require only a small amount of "glue" code.
There, only masochists and lunatics would insist on writing the code from
scratch.

The situation is different in the embedded world, but nonetheless I think
the problem has more to do with the mindset of embedded programmers, than
with the special attributes of embedded programming that make it different
from other types of software development.

Best regards,

Vitaliy

2009\05\25@041050 by Tamas Rudnai

face picon face
As they say the software developer's best friend is the Ctrl+C - Ctrl+V...

I have never considered as a reusable code of using libraries though.
Interesting approach.

Tamas


On Sun, May 24, 2009 at 11:16 AM, Vitaliy <spam_OUTspamTakeThisOuTspammaksimov.org> wrote:

{Quote hidden}

> -

2009\05\25@054950 by Vitaliy

flavicon
face
Tamas Rudnai wrote:
> As they say the software developer's best friend is the Ctrl+C - Ctrl+V...

Taken literally, this is actually considered a big no-no. :)  "Ctrl-C,
Ctrl-V" violates a fundamental rule of programming: "one rule, one place."


> I have never considered as a reusable code of using libraries though.
> Interesting approach.

We're finding that a majority (I'd say, 85%+) of the code that we created,
can be thought of as "library code". The reason for this is that when you
treat your modules as objects, it happens naturally. After all, "library"
and "reusable code" are synonyms.

Most of the code in our currently active projects, is extern'ed from the
"library" repository. There are only a handful of files (including the
Initializer object) that have to be project-specific.

Vitaliy

2009\05\25@085140 by sergio masci

flavicon
face


On Mon, 25 May 2009, Vitaliy wrote:

{Quote hidden}

libraries, bloat, long hours debugging are "synonyms" :-)

I see we're chasing unicorns again.

I remember one time I worked for a company where it was deamed expediant
to purchase a comms library rather than write it in house. We used said
comms library, tested the resultant system and shipped it. We ended up
with lots of egg on our collective face when the system mysteriously
crashed a few days after installation. Turns out the library was at fault.
It took weeks to track down the fault, much longer than if we'd written
our own. How do you tell a client "actually the fault is with a SW
component we bought in" - it doesn't wash.

>
> Most of the code in our currently active projects, is extern'ed from the
> "library" repository. There are only a handful of files (including the
> Initializer object) that have to be project-specific.

I've worked with lots of companies where they insist on building
everything as libraries with a minimal "main". What really gets to me
about this approach is that it doesn't give you anything over simply
linking object files together. This myth that "improving" a library
automatically makes everyones code better is just complete BS. If anything
it introduces bugs into tried and tested code - code which then needs to
be completely retested by the person that didn't even make the changes to
the library.

I've seen many systems fall apart at the eleventh hour just as they're
about to ship because someone fixed a bug in their code which had a
detrimental effect on someone elses code.

If you're talking about objects then presumably you're talking about C++
or Java. The overheads of using libraries are so bad C++ had to resort to
"templates" - good luck debugging the mess that comes out of that when you
try porting your code to a new compiler for a different system. And Java -
I heard of a guy (worked with my brother - so pretty reliable source) that
had to port Java to a system. He was tracing though the executable and was
appauled to find that it took hundreds of millions of malloc calls just to
print "hello world". Yeh sure you can get JIT (just in time compiling) for
your Java program but how does that help when the libraries need to go
through heavy duty memory management to achive trivial things.

Regards
Sergio Masci

2009\05\25@092653 by Tamas Rudnai

face picon face
On Mon, May 25, 2009 at 4:52 PM, sergio masci <.....smplxKILLspamspam@spam@allotrope.net> wrote:

> Turns out the library was at fault.
> It took weeks to track down the fault, much longer than if we'd written
> our own. How do you tell a client "actually the fault is with a SW
> component we bought in" - it doesn't wash
>

I agree that it could happen. However, if you buy a library from a sw
company that has hundreds or even thousands of clients using the same
library then the chance that the code is more reliable than your in-house
one is quite high -- simply because more people are testing it in a more
variety of systems. You might can make it more compact though as the
in-house one was designed for your needs only not for average requirements.


On Mon, May 25, 2009 at 4:52 PM, sergio masci <smplxspamKILLspamallotrope.net> wrote:

> He was tracing though the executable and was
> appauled to find that it took hundreds of millions of malloc calls just to
> print "hello world". Yeh sure you can get JIT (just in time compiling) for
> your Java program but how does that help when the libraries need to go
> through heavy duty memory management to achive trivial things.
>

Most HLL is quite inefficient on small code as they have a relatively big
startup code initializing a larger set of libraries and as they generalize
the system for average needs instead of specifically yours. The real
question is always whenever the HLL is still resource waster when you have a
huge code base and also if you can achieve a better code in shorter time.
Usually it is a complex calculation how can you get more profit -- if you
take a high speed mcu/cpu with plenty of resources and hll development
buying libraries etc so you have a product in a small turnover or do the
opposite so you save money on the production but spending much more time
during the development phase. My guess is that the answer is usually
somewhere in between.

Tamas
--
http://www.mcuhobby.com

2009\05\25@093133 by olin piclist

face picon face
Vitaliy wrote:
> There are only a handful of files (including the
> Initializer object) that have to be project-specific.

That's really funny, since that's the biggest module that gets re-used here
between PIC projects without modification.  In fact, most projects just have
a stub module that includes a project-specific include file, the library
file (we do libraries at the source level), and the END directive.

You can see this for yourself.  The library include file is PORT.INS.ASPIC,
which will be in the SOURCE > PIC directory after installing my PIC
development environment.  The information about how to set up the ports
comes from the /INBIT and /OUTBIT directives in the project include file.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\25@101506 by sergio masci

flavicon
face


On Mon, 25 May 2009, Tamas Rudnai wrote:

{Quote hidden}

Do you really think that after the problems we had with it (the money it
cost us to fix, the loss of face with our clients) that we even bothered
telling the provider what the problem was. Some people may report bugs but
many just "dump" and look for an alternative. When is the last time you
wrote a letter of complaint for something you bought and didn't work as
expected. Heck how many bug reports have you bothered to send for software
that you bought or downloaded?

{Quote hidden}

Yes given that many PC users seem to accept bugs nowadays it makes sense
to use components from other software houses to minimise time to market
and maximise profit. However such components (and even low level
libraries) tend to be written differently to normal app code. Simply
combining a lot of object files together to produce a library is not the
same as specifically writing and maintaing a library. There is a lot of
effort involved, a lot of testing, documenting etc. Code re-use is about
taking code that was written for project A and using it for project B. You
can't simply say "we achived 99% code re-use with minimal effort" if there
was a ton of effort put into making the code re-usable in the first place.
In effect you wrote the code for project A nd project B at the same time
(with all the extra effort that involved).

:-)

Friendly Regards
Sergio Masci

2009\05\25@142754 by Vitaliy

flavicon
face
Olin Lathrop wrote:
> Vitaliy wrote:
>> There are only a handful of files (including the
>> Initializer object) that have to be project-specific.
>
> That's really funny, since that's the biggest module that gets re-used
> here
> between PIC projects without modification.  In fact, most projects just
> have
> a stub module that includes a project-specific include file, the library
> file (we do libraries at the source level), and the END directive.
>
> You can see this for yourself.  The library include file is
> PORT.INS.ASPIC,
> which will be in the SOURCE > PIC directory after installing my PIC
> development environment.  The information about how to set up the ports
> comes from the /INBIT and /OUTBIT directives in the project include file.

So where do you specify the project specific attributes, for instance the
baud rate for UART, or the resolution for ADC?

Specifying these attributes inside the module that uses them, effectively
precludes code reuse. You have to make a copy of the UART module, just so
you can specify a different baud rate. Since the file is now different, it
will quickly get out of synch with the other copies, because any other
changes you decide to make, won't propagate.

It makes sense to isolate the stuff that changes (e.g., configurable
attributes) and put it in one file that contains project-specific code. Then
the UART module can be used without any modifications, in a project that
uses it at 9600 baud and a second project that runs it at 115k baud.

Vitaliy


2009\05\25@150535 by Vitaliy

flavicon
face
sergio masci wrote:
> I've worked with lots of companies where they insist on building
> everything as libraries with a minimal "main". What really gets to me
> about this approach is that it doesn't give you anything over simply
> linking object files together.

I'm not talking about rolling everying into .a files. Are you familiar with
Subversion? I said that reusable code gets extern'ed into the project. If
it's not clear what this means, or what the benefit is, let me know -- I can
try to explain.


> This myth that "improving" a library
> automatically makes everyones code better is just complete BS.

Would you believe me if I said that we've been using the approach I
described, and it indeed makes the code better over time? This happens
because with every project that touches the reusable code module, bugs get
fixed, code gets refactored, new features get put in. Of course, the longer
the module exists, the less it gets changed -- because there are no more
bugs to fix, the code is an epitome of beauty and elegance, and it's got all
the features we need. ;-)))))


> If anything
> it introduces bugs into tried and tested code - code which then needs to
> be completely retested by the person that didn't even make the changes to
> the library.

Ah. Yes, we've ran into this problem early on. :) The solution is to specify
the version of the library module when you tag a release.


> I've seen many systems fall apart at the eleventh hour just as they're
> about to ship because someone fixed a bug in their code which had a
> detrimental effect on someone elses code.

Sounds like you've seen some very tightly coupled code. Reusable modules
almost by definition tend to make the code loosely coupled, because most of
the data and functions are encapsulated and are not accessible from the
outside. Communication b/w modules takes place through small, well defined
interfaces.


> If you're talking about objects then presumably you're talking about C++
> or Java.

No, I'm talking about applying OOP concepts to regular C code, on embedded
systems. Last year there was a discussion here where I explained how it
works, and how we use it at our company. Since then, we made significant
improvements to the system and were able to work through many of the kinks.

I understand this is a somewhat controversial topic. However, this is not
just some unproven theory, I'm sharing my actual experience. Trying to prove
to me that it "cannot possibly work", is sort of like trying to convince me
that I don't have a belly button. :)

Last week I explained the concepts to another programmer. He said he was so
excited that when he came home, he could not go to sleep until he converted
his hobby project to our system.

Unfortunately, email is no substitute for a face-to-face meeting. :-)

Vitaliy

2009\05\25@155044 by Herbert Graf

picon face
On Mon, 2009-05-25 at 11:26 -0700, Vitaliy wrote:
> So where do you specify the project specific attributes, for instance the
> baud rate for UART, or the resolution for ADC?
>
> Specifying these attributes inside the module that uses them, effectively
> precludes code reuse. You have to make a copy of the UART module, just so
> you can specify a different baud rate. Since the file is now different, it
> will quickly get out of synch with the other copies, because any other
> changes you decide to make, won't propagate.
>
> It makes sense to isolate the stuff that changes (e.g., configurable
> attributes) and put it in one file that contains project-specific code. Then
> the UART module can be used without any modifications, in a project that
> uses it at 9600 baud and a second project that runs it at 115k baud.

Exactly. For example, many of my projects have had "print string" type
functions. I've been able to reuse all this code because none of it is
specific to any piece of hardware. All the routines end up calling just
one function: putChar. putChar is the only function I need to change
when moving from platform to plaform.

Obviously there is an associated initPutChar type routine that handles
where putChar outputs it's stuff.

So when I want to change UARTs it's just a matter of changing a define
in initPutChar. If I want to output through say a USB port I just bring
in a different initPutChar. LCD? initPutChar and putChar get a little
more complicated, but not much. The point is none of the code that calls
putChar needs to be changed.

Moving to a PC? Even easier since then I've got an OS that does most of
what initPutChar does.

TTYL

2009\05\25@165705 by olin piclist

face picon face
Vitaliy wrote:
> So where do you specify the project specific attributes, for instance
> the baud rate for UART, or the resolution for ADC?

Those go in whatever module manages those resources.

> Specifying these attributes inside the module that uses them,
> effectively precludes code reuse.

Of course not.  If truly only the baud rate ever changes between your UART
modules, then you can put the baud rate constant in your project include
file and make the UART module a library include file.  However there are
different wrinkles in how you might want to use the UART.  The needs of a
particular project could span the range between using only the UART output
with a busy wait loop before writing, to full interrupt driven I/O using
FIFOs in both directions.  My QQQ_UART.ASPIC template module contains the
full blown case since it's a lot easier to delete things you don't want
instead of adding things that aren't there.  I can also use other project
code as templates, like when I want just programmed I/O UART output.

> You have to make a copy of the UART
> module, just so you can specify a different baud rate. Since the file
> is now different, it will quickly get out of synch with the other
> copies, because any other changes you decide to make, won't propagate.

The UART template module has changed very little in a bunch of years.  But
there is no problem even if it is customized for particular projects.

> It makes sense to isolate the stuff that changes (e.g., configurable
> attributes) and put it in one file that contains project-specific code.
> Then the UART module can be used without any modifications, in a
> project that uses it at 9600 baud and a second project that runs it at
> 115k baud.

In my experience, very few things on small resource-limited systems like
PICs can be pre-packaged and generalized at this level.  The UART is about
the only exception I can think of, which is why I have a UART template
module.  I've tried to do that with A/D handling code, and couldn't come up
with something flexible enough to meet a reasonable fraction of project
needs that was not so burdened with dealing with the options as to be too
unwieldy or inefficient.  There are just too many wrinkles, like which
channels are in use, how acqusition is timed, how conversion is timed, how
the results are filtered and/or scaled, how they are communicated to the
rest of the system, whether interrupts are used to get results, how
conversion is initiated, etc, etc.

In the end it's easier to start with code from a similar project and modify
it, or even start from scratch with maybe looking at code from another
project as a example.  Keep in mind that setting up the peripherals is the
trivial part of PIC projects.  Most of the work goes into the unique code
that performs whatever the project's function is.  The A/D module is rarely
that complex.  It doesn't matter how great a solution you have for 10% of
the problem.  You still have the other 90% to do.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\25@171812 by Vitaliy

flavicon
face
sergio masci wrote:
>> I agree that it could happen. However, if you buy a library from a sw
>> company that has hundreds or even thousands of clients using the same
>> library then the chance that the code is more reliable than your in-house
>> one is quite high -- simply because more people are testing it in a more
>> variety of systems.
>
> Do you really think that after the problems we had with it (the money it
> cost us to fix, the loss of face with our clients) that we even bothered
> telling the provider what the problem was. Some people may report bugs but
> many just "dump" and look for an alternative. When is the last time you
> wrote a letter of complaint for something you bought and didn't work as
> expected. Heck how many bug reports have you bothered to send for software
> that you bought or downloaded?

Bug reporting happens more often than you think. Take a look at the
Microchip forum, for example. Despite your bad experience, Tamas's point is
totally valid.


> Yes given that many PC users seem to accept bugs nowadays it makes sense
> to use components from other software houses to minimise time to market
> and maximise profit. However such components (and even low level
> libraries) tend to be written differently to normal app code. Simply
> combining a lot of object files together to produce a library is not the
> same as specifically writing and maintaing a library. There is a lot of
> effort involved, a lot of testing, documenting etc. Code re-use is about
> taking code that was written for project A and using it for project B.

I don't see why you would want to use such a narrow definition of code
reuse. However, like I said, this is exactly what we do -- take code written
for project A, and use it in project B. Since the shareable code sits in a
specific place in the repository ("lib"), calling it "library code" is just
another way of thinking about it.


> You
> can't simply say "we achived 99% code re-use with minimal effort" if there
> was a ton of effort put into making the code re-usable in the first place.
> In effect you wrote the code for project A nd project B at the same time
> (with all the extra effort that involved).

I know you won't believe me, but reusable code is just a byproduct of
following the simple programming paradigm "loose coupling, tight cohesion".
We write code the same way, whether we plan to reuse it, or not.

There is no reason to have 100 different implementations of a UART module,
if the only thing you're changing when you go from project to project, is
the baud rate. Anything that makes the UART module project-specific, is
unnecessary coupling.

Vitaliy

2009\05\25@180144 by Vitaliy

flavicon
face
Olin Lathrop wrote:
>> So where do you specify the project specific attributes, for instance
>> the baud rate for UART, or the resolution for ADC?
>
> Those go in whatever module manages those resources.

This is what we did, initially. Eventually we realized that what should
happen, is that each "object" should have an Init() function that sets all
the module's defaults (what you would use in 90% of the cases), and then let
whichever higher level object is using this object, change the attributes
that it cares about.

The Initializer object's job is to initialize only the highest level
objects. To make it a little bit more concrete, here's a short example of
what the function calls would look like, in a fictitios modem project:

main()
   Initializer_InitializeEverything()
       Modem_Init()
           Uart_Init()
           Uart_SetBaudRate(9600)

You want to push as much responsibility as possible, from the higher level
to the lower level objects. But not too much, because you don't want Uart to
know what its baud rate should be, for this particular project -- it would
create unnecessary coupling. It's the job of the object directly above it
(Modem, in this case) to set whatever configuration it needs.


{Quote hidden}

The problem with this approach, is that you have to manually port whatever
changes you make, back into the template. Also, deleting things you don't
want sounds a bit messy, as compared to using a module "as-is".


>> You have to make a copy of the UART
>> module, just so you can specify a different baud rate. Since the file
>> is now different, it will quickly get out of synch with the other
>> copies, because any other changes you decide to make, won't propagate.
>
> The UART template module has changed very little in a bunch of years.  But
> there is no problem even if it is customized for particular projects.

This is probably why it works so well for you: the code is very stable.


{Quote hidden}

Like I've been saying all along, I think the big differences in our
perspectives, come from the fact that you seem to mostly work with 16F, 12F,
and 10F PICs, where resources are very limited. My experience comes
primarily from writing PC apps and working with higher end PICs.

We have successfully written a reusable PIC ADC module, which fits our
current needs. If you try to reduce ADC module to its core functionality,
you realize that the only thing you need, is the ability to read out a
value. Everything else is hardware specific details. :)

The attributes can be nicely packaged into a structure that represents the
object you're working with. You initialize most attributes at runtime, and
use a project config file to define compile-time things like which A/D pins
are in use.


> In the end it's easier to start with code from a similar project and
> modify
> it, or even start from scratch with maybe looking at code from another
> project as a example.

When properly set up, taking a module and plugging it into a project, is
easier. That said, this approach may not work for the 16Fs. TANSTAAFL, and
in this case the tradeoff is code size and/or runtime performance. We found
it extremely well worth it.


> Keep in mind that setting up the peripherals is the
> trivial part of PIC projects.

Yes.


> Most of the work goes into the unique code
> that performs whatever the project's function is.  The A/D module is
> rarely
> that complex.

I'm not sure how the two sentences tie together.


> It doesn't matter how great a solution you have for 10% of
> the problem.  You still have the other 90% to do.

If my solution solves 10% of the problem, it makes me 10% more productive.
There is no silver bullet, but you can simulate the silver bullet effect by
combining many incremental improvements. Many of the techniques tend to
reinforce each other, which creates strong synergy and further amplifies the
effect.

Vitaliy

2009\05\25@191845 by Gerhard Fiedler

picon face
sergio masci wrote:

> Do you really think that after the problems we had with it (the money
> it cost us to fix, the loss of face with our clients) that we even
> bothered telling the provider what the problem was.

Should've... IMO. Helps making a better world :)

> When is the last time you wrote a letter of complaint for something
> you bought and didn't work as expected. Heck how many bug reports
> have you bothered to send for software that you bought or downloaded?

Happens all the time here. Why wouldn't I, if I already did find it out?

Gerhard

2009\05\25@194035 by olin piclist

face picon face
Vitaliy wrote:
> This is what we did, initially. Eventually we realized that what should
> happen, is that each "object" should have an Init() function that sets
> all the module's defaults (what you would use in 90% of the cases), and
> then let whichever higher level object is using this object, change the
> attributes that it cares about.
>
> The Initializer object's job is to initialize only the highest level
> objects. To make it a little bit more concrete, here's a short example
> of what the function calls would look like, in a fictitios modem
> project:
>
> main()
>    Initializer_InitializeEverything()
>        Modem_Init()
>            Uart_Init()
>            Uart_SetBaudRate(9600)

That has the serious drawback that the baud rate is no longer known at build
time, and various efficiencies are no longer possible.  I haven't had a PIC
project yet where the baud rate wasn't fixed.  That's why I use a symbolic
constant for the baud rate and assembly time computation to determine the
baud rate divider and other setup values.  This also uses the oscillator
frequency build-time constant.

> You want to push as much responsibility as possible, from the higher
> level to the lower level objects. But not too much, because you don't
> want Uart to know what its baud rate should be, for this particular
> project -- it would create unnecessary coupling. It's the job of the
> object directly above it (Modem, in this case) to set whatever
> configuration it needs.

That's nice in general, and certainly the best way to do it when resources
aren't a issue.  However on small embedded projects resources are often a
issue, and doing the baud rate computation at build time instead of at run
time can save a significant amount of code space.  This is why small
embedded projects are different where the usual rules of thumb don't apply
or you have to think about them carefully.

> The problem with this approach, is that you have to manually port
> whatever changes you make, back into the template.

No I don't.  These changes are presumably one-off unique to that project.
Unless I think they may be useful in other projects there would be no point
in backing them into the template.  Then there would need to be ways to
select which features you want in the template.  Some amount of
customization with assembly time conditionals may be worth it, but you don't
want something so dense it becomes hard to maintain and customize as needed.

Besides, the code in the new project is no different really than the
template source file.  It can be used as a template for future projects just
as well.  I even have a script, CLONE_PIC_MODULE, just for this purpose.  It
grabs a module from some other project, edits the include file references
and module name appropriately, and creates it as a new module for the
current project.

The real trick is to keep the external interfaces common to the extent you
reasonably can.  For example, my read and write UART byte routines are
always called UART_PUT and UART_GET, and always have the same interface.
The rest of the code won't care what I copied or wrote from scratch to make
the UART module.

> Also, deleting things you don't want sounds a bit messy, as
> compared to using a module "as-is".

Obviously doing no edits would be better than any, but you can't possibly
make a module so flexible that it caters to all possible contingencies, end
up with efficient code at run time, and be easily maintainable.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\25@220149 by Vitaliy

flavicon
face
Olin Lathrop wrote:
>> The problem with this approach, is that you have to manually port
>> whatever changes you make, back into the template.
>
> No I don't.  These changes are presumably one-off unique to that project.
> Unless I think they may be useful in other projects there would be no
> point
> in backing them into the template.  Then there would need to be ways to
> select which features you want in the template.  Some amount of
> customization with assembly time conditionals may be worth it, but you
> don't
> want something so dense it becomes hard to maintain and customize as
> needed.

This is possible because your template is pretty much set in stone by now.
New modules (at least in my experience) tend to go through lots of changes,
before the dust finally settles.

If was working on the lower-end 8 bit PICs, your approach would make total
sense. On the 24H, resources are cheap, and priorities are different.

Best regards,

Vitaliy

2009\05\26@041203 by Alan B. Pearce

face picon face
>The problem with this approach, is that you have to manually
>port whatever changes you make, back into the template.

Why ??? It is a template that will get different changes for another
project. It is a template, not the end code.

As Olin points out, the code is that tightly coupled to the hardware that
there will generally be some customization anyway.

In your case you do the customization by calling initialization subroutines.
In Olins case he does it by changing a define at the beginning of the file.
Your case may well tie up more code space, which may well be a killer in a
very small device. Olins method allows error checking for size or value of
parameter, or changing it according to the crystal frequency, on the fly at
compile time. In your case you need to repeat this code in the main
initialization routine every time you do a new project.

Each method has its own pluses and minuses. Each method suits different
people different ways. With the memory size of the devices we are dealing
with it is not going to really take that long to assemble the whole code for
the device, so customizing a module for a project is no big deal.

2009\05\26@050130 by Vitaliy

flavicon
face
Alan B. Pearce wrote:
> >The problem with this approach, is that you have to manually
>>port whatever changes you make, back into the template.
>
> Why ??? It is a template that will get different changes for another
> project. It is a template, not the end code.

Olin admitted that there may be changes that would require modifications of
the template. Unless you have very stable code that requires little or no
modifications (it sounds like it is the case, for Olin) it is bound to be
more error prone and more time consuming to maintain it this way. Alas,
there is no such thing as perfect code, and there is definitely no such
thing as writing perfect code on the first try.

I thought this topic had been beaten to death already? :)  I feel like I'm
repeating myself, which makes me suspicious: it sounds like you haven't been
following the thread, saw my message out of context, and decided to jump in
without getting the whole story.


> As Olin points out, the code is that tightly coupled to the hardware that
> there will generally be some customization anyway.

And I said that if I was working on 16Fs, I would probably do it this way
too.


> In your case you do the customization by calling initialization
> subroutines.
> In Olins case he does it by changing a define at the beginning of the
> file.
> Your case may well tie up more code space, which may well be a killer in a
> very small device.

I said that I'm not using "very small" devices, I'm using high end PICs.


> Olins method allows error checking for size or value of
> parameter, or changing it according to the crystal frequency, on the fly
> at
> compile time. In your case you need to repeat this code in the main
> initialization routine every time you do a new project.

I explained the reason why I think it's better to do it "my" way, *IF* you
can afford it. If you can't, you do it Olin's way.


> Each method has its own pluses and minuses. Each method suits different
> people different ways.

No argument here.


> With the memory size of the devices we are dealing
> with it is not going to really take that long to assemble the whole code
> for
> the device, so customizing a module for a project is no big deal.

I think all three of us are in complete agreement, when it comes to the
lower-end PICs. OTOH, when you're dealing with devices that have 256K of
Flash and 16K of RAM, things are quite different. Firmware development is by
far the most expensive part of the projects I've been involved in over the
past year. Since hardware resources are abundant and cheap, it makes sense
to try to do whatever is necessary to reduce programming costs -- even when
the savings come at the expense of wasting a few extra bytes and processor
cycles.

Best regards,

Vitaliy

2009\05\26@053235 by Alan B. Pearce

face picon face
>I thought this topic had been beaten to death already? :)  I feel
>like I'm repeating myself, which makes me suspicious: it sounds
>like you haven't been following the thread, saw my message out of
>context, and decided to jump in without getting the whole story.

I did see Olins message after I had sent the reply to yours.

But Monday was a holiday here in the UK, so I didn't see yesterdays messages
until this morning, which is why my reply was delayed.

2009\05\26@053508 by Xiaofan Chen

face picon face
On Tue, May 26, 2009 at 5:01 PM, Vitaliy <spamspamspam_OUTmaksimov.org> wrote:
> Since hardware resources are abundant and cheap, it makes sense
> to try to do whatever is necessary to reduce programming costs -- even when
> the savings come at the expense of wasting a few extra bytes and processor
> cycles.

Interesting conclusion.

Is that true? I thought there were too many software and to a lesser
extent firmware developer and not enough hardware developers? ;-)

--
Xiaofan http://mcuee.blogspot.com

2009\05\26@053920 by Alan B. Pearce

face picon face
>I think all three of us are in complete agreement, when it comes
>to the lower-end PICs. OTOH, when you're dealing with devices that
>have 256K of Flash and 16K of RAM, things are quite different.

Whoops, should have had this on previous message - hit send too soon.

I think you are right - but I am fighting the Microchip C30 library at the
moment, seems even they don't use their library for their own code.

Someone else quoted the mess that they have for setting up a UART in C30,
and wanting to use some UARTs in a project, I have been attempting to figure
out what is necessary. The C30 library has lots of calls that seem
unnecessarily complex, they do it a different way in their USB framework
(not even using the C30 library), and I am wondering if I should 'just'
write my own, so I know what is going on ...

2009\05\26@054911 by Xiaofan Chen

face picon face
On Tue, May 26, 2009 at 5:39 PM, Alan B. Pearce
<@spam@Alan.B.PearceKILLspamspamstfc.ac.uk> wrote:
> I think you are right - but I am fighting the Microchip C30 library at the
> moment, seems even they don't use their library for their own code.
>
> Someone else quoted the mess that they have for setting up a UART in C30,
> and wanting to use some UARTs in a project, I have been attempting to figure
> out what is necessary. The C30 library has lots of calls that seem
> unnecessarily complex, they do it a different way in their USB framework
> (not even using the C30 library), and I am wondering if I should 'just'
> write my own, so I know what is going on ...

As far as I know, those peripheral libraries provide a good way for customer
to move from one family to another (say PIC18 to PIC24 to PIC32). It also
helps the newbies to get started. But that is pretty much what they are for.

The C30 compiler is excellent, the peripheral libraries are probably not
of the desired quality. I think it may be easier for you to roll your own.


--
Xiaofan http://mcuee.blogspot.com

2009\05\26@055639 by Vitaliy

flavicon
face
Xiaofan Chen wrote:
>> Since hardware resources are abundant and cheap, it makes sense
>> to try to do whatever is necessary to reduce programming costs -- even
>> when
>> the savings come at the expense of wasting a few extra bytes and
>> processor
>> cycles.
>
> Interesting conclusion.
>
> Is that true? I thought there were too many software and to a lesser
> extent firmware developer and not enough hardware developers? ;-)

My cousin (an EE) told me that hardware design at Kyocera had been reduced
to "hook up this module to this module, here's a diagram that shows you
how".

At our company, hardware design constitutes a small fraction of the overall
development effort. We can go from a sketch on the proverbial napkin, to
finished PCB layout typically within a week or so. Firmware development
takes many many months.

Why do you ask? Is the situation different at your company?

Vitaliy

2009\05\26@060124 by Vitaliy

flavicon
face
Alan B. Pearce wrote:
> >I think all three of us are in complete agreement, when it comes
>>to the lower-end PICs. OTOH, when you're dealing with devices that
>>have 256K of Flash and 16K of RAM, things are quite different.
>
> Whoops, should have had this on previous message - hit send too soon.
>
> I think you are right - but I am fighting the Microchip C30 library at the
> moment, seems even they don't use their library for their own code.
>
> Someone else quoted the mess that they have for setting up a UART in C30,
> and wanting to use some UARTs in a project, I have been attempting to
> figure
> out what is necessary. The C30 library has lots of calls that seem
> unnecessarily complex, they do it a different way in their USB framework
> (not even using the C30 library), and I am wondering if I should 'just'
> write my own, so I know what is going on ...

We ended up writing our own UART library. :) I used the Microchip's UART
module interface as an example of how *not* to write code. Homegrown
Microchip library code is pretty awful.

The standard libs are pretty good, however. Printf(), etc work out of the
box.

Let me know if you need help with anything.

Vitaliy

2009\05\26@060244 by Vitaliy

flavicon
face
Xiaofan Chen wrote:
>> I think you are right - but I am fighting the Microchip C30 library at
>> the
>> moment, seems even they don't use their library for their own code.
>>
>> Someone else quoted the mess that they have for setting up a UART in C30,
>> and wanting to use some UARTs in a project, I have been attempting to
>> figure
>> out what is necessary. The C30 library has lots of calls that seem
>> unnecessarily complex, they do it a different way in their USB framework
>> (not even using the C30 library), and I am wondering if I should 'just'
>> write my own, so I know what is going on ...
>
> As far as I know, those peripheral libraries provide a good way for
> customer
> to move from one family to another (say PIC18 to PIC24 to PIC32). It also
> helps the newbies to get started. But that is pretty much what they are
> for.

Their only purpose in life, is to serve as a bad example. :)

Well, and maybe borrow some code from, since they're open source.


> The C30 compiler is excellent, the peripheral libraries are probably not
> of the desired quality. I think it may be easier for you to roll your own.

Agree.

Vitaliy

2009\05\26@071722 by Alan B. Pearce

face picon face
>We ended up writing our own UART library. :)

That is what I am going to do too.

>I used the Microchip's UART module interface as an
>example of how *not* to write code.
>Homegrown Microchip library code is pretty awful.

Well, I am figuring on using the code from the uart2.c module tat comes with
the USB framework as a starting point, unless you happen to have something
better you can point me at.

TIA.

2009\05\26@073759 by sergio masci

flavicon
face


On Tue, 26 May 2009, Vitaliy wrote:

{Quote hidden}

Hi Vitaliy,

I have been reading your posts VERY carefully and it seems to me that you
are spending a great deal of time makeing your software re-usable. In
other words designing, implementing and debugging interfaces between
components of your modules AND actually generating app code that interacts
with your libraries (modules or whatever you want to call them). It also
seems to me that when you talk about the efficiency you have achived
with your code re-use that all the VERY hard work you are putting into it
up front is being disregarded, as though it is somehow free.

You claim 85% code re-use and you say that "typically ... Firmware
development takes many many months" and that you use "PICs with 256k of
flash and 16k of RAM" this begs the question - what the hell are you
building?

Friendly Regards
Sergio Masci

2009\05\26@074718 by Xiaofan Chen

face picon face
On Tue, May 26, 2009 at 5:56 PM, Vitaliy <KILLspamspamKILLspamspammaksimov.org> wrote:
>> Is that true? I thought there were too many software and to a lesser
>> extent firmware developer and not enough hardware developers? ;-)
>
> My cousin (an EE) told me that hardware design at Kyocera had been reduced
> to "hook up this module to this module, here's a diagram that shows you
> how".

This will not work for many sections, at least not for our product (PLC
related).

> At our company, hardware design constitutes a small fraction of the overall
> development effort. We can go from a sketch on the proverbial napkin, to
> finished PCB layout typically within a week or so. Firmware development
> takes many many months.
>
> Why do you ask? Is the situation different at your company?

Because I am mostly a hardware designer. :-)

But seriously, there are not many good engineers who can design power
supply circuits. There are even fewer who can deal with EMC/EMI issues with
enough expertise (I admit I am not good in this aspect either). It
can take months or years to solve EMC/EMI problems...

In my particular division, often hardware and firmware are of equal
importance. But you are right, firmware/software engineers far
outnumber the hardware engineer in the company. Software
becomes more and more important now.

You will not be able to finish our hardware design in a
napkin even though I did receive a good power supply circuits
on a napkin from a guru a few years back.

--
Xiaofan http://mcuee.blogspot.com

2009\05\26@075222 by Xiaofan Chen

face picon face
On Tue, May 26, 2009 at 10:38 PM, sergio masci <RemoveMEsmplxTakeThisOuTspamallotrope.net> wrote:
> You claim 85% code re-use and you say that "typically ... Firmware
> development takes many many months" and that you use "PICs with 256k of
> flash and 16k of RAM" this begs the question - what the hell are you
> building?
>

Because the hard work is in the 15%. ;-)

Seriously, I think that is about right. We reuse a lot of hardware design
as well. But sometimes the 10% of the circuits may take 90% of the time
for the design.

By the way, 256KB firmware can be a lot work. I understand this one
(I have never written any firmware above 2k words or 4KB for work).

--
Xiaofan http://mcuee.blogspot.com

2009\05\26@080722 by olin piclist

face picon face
Vitaliy wrote:
>> Why ??? It is a template that will get different changes for another
>> project. It is a template, not the end code.
>
> Olin admitted that there may be changes that would require
> modifications of the template.

Nothing requires changing the template, and I never said that.  I do
occasionally change a template when I add something in a project that I
think generalizes well to future projects.  However, this is quite unusual.

I also pointed out how any existing project module can be easily used as a
template for a similar module in a new project.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\26@081250 by olin piclist

face picon face
Xiaofan Chen wrote:
>> Since hardware resources are abundant and cheap, it makes sense
>> to try to do whatever is necessary to reduce programming costs --
>> even when the savings come at the expense of wasting a few extra
>> bytes and processor cycles.
>
> Interesting conclusion.
>
> Is that true? I thought there were too many software and to a lesser
> extent firmware developer and not enough hardware developers? ;-)

The number of available engineers has nothing to do with it other than
effecting the cost of the engineers.  However, common sense says that the
unit cost of low volume products is dominated by the engineering effort, and
that of high volume products by manufacturing.  It's a simple large up front
plus smaller incremental calculation, which must always be kept in mind when
making tradeoffs in the desing process.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\26@102441 by sergio masci

flavicon
face


On Mon, 25 May 2009, Gerhard Fiedler wrote:

> sergio masci wrote:
>
> > Do you really think that after the problems we had with it (the money
> > it cost us to fix, the loss of face with our clients) that we even
> > bothered telling the provider what the problem was.
>
> Should've... IMO. Helps making a better world :)

Oh, you make me feel bad now. wait a minute there's an email comming in
from carma. She says "don't feel bad Sergio you're in credit, but tell
Gerhard I haven't forgotten". Ok then all's good :-)

>
> > When is the last time you wrote a letter of complaint for something
> > you bought and didn't work as expected. Heck how many bug reports
> > have you bothered to send for software that you bought or downloaded?
>
> Happens all the time here. Why wouldn't I, if I already did find it out?

I duno, maybe because you'd be helping your own competion? Maybe because
it would take valuble time to produce an example without including too
much of your propritry code? Maybe because you figure the best library
should actually be the one to survive?

Friendly Regards
Sergio Masci

2009\05\26@104712 by Herbert Graf

picon face
On Tue, 2009-05-26 at 02:56 -0700, Vitaliy wrote:
> My cousin (an EE) told me that hardware design at Kyocera had been reduced
> to "hook up this module to this module, here's a diagram that shows you
> how".
>
> At our company, hardware design constitutes a small fraction of the overall
> development effort. We can go from a sketch on the proverbial napkin, to
> finished PCB layout typically within a week or so. Firmware development
> takes many many months.
>
> Why do you ask? Is the situation different at your company?

If you look at most consumer electronics these days it's clear that
hardware dev is by far no longer the main consumer of design resources.

Pretty much every consumer electronics device you buy today uses a very
small subset of hardware solutions (usually an ARM or MIPS based SOC,
with a couple support components), and as little dedicated hardware as
possible. The "meat" of the device is software, from the DSP routines
running in a cell phone, to even much of the H264/VC1 decoding that went
on in the first BluRay players (which is why they were so painfully
slow, more modern BluRay players have more hardware acceleration for
H264/VC1, but there is still a boatload of software).

A perfect example of this is inkjet printers. I opened up a recent model
and found two very small chips on a VERY small PCB. The first chip was
basically a USB interface, the second a motor driver. It's clear that a
TON of the "guts" of this device's function is in the software running
on the PC.

For the consumer this has meant relatively cheap prices (since software
is very cheap to fix vs. an ASIC). Unfortunately, it has had a VERY
frustrating negative effect: device lagginess. Compared to devices that
used more specialized silicon today's devices are REALLY laggy. My sat
radio receiver has tons of annoying pauses while manipulating the GUI.
Pretty much every cell phone you buy (except really simple ones) have
lag while pressing the hang up button.

By far the most frustrating for me has been the "softwarizing" of power
buttons. Very few power buttons actually switch off power anymore. My
sat TV receiver simply turns off it's LEDs when I press the power
button, it still pumps out an HDMI standby picture while "off". My
monitor's power button doesn't work when it's in the middle of switching
to a power saving mode, I have to wait for it to transition before it
will respond to the power button.

Such is life when hardware becomes so cheap! :)

TTYL


2009\05\26@110922 by William \Chops\ Westfield

face picon face

On May 26, 2009, at 10:25 AM, sergio masci wrote:

>> Why wouldn't I, if I already did find it out?
>
> I duno, maybe because you'd be helping your own competion? Maybe  
> because
> it would take valuble time to produce an example without including too
> much of your propritry code? Maybe because you figure the best library
> should actually be the one to survive?

OTOH, The main reason to report bugs to a vendor is so that the NEXT  
revision of their code you incorporate into your products doesn't have  
the same bugs.  Having a "local patch list" for purchased software  
gets to really suck, pretty quickly...

(not applicable if you've already said "Argh; we're never using this  
awful thing again!", of course.)

BillW

2009\05\26@201222 by Bob Axtell

face picon face
I think you are right. I have decades of PIC code, all verified and
thoroughly tested.
Why do it all over again?

--Bob

On Sun, May 24, 2009 at 3:16 AM, Vitaliy <spamBeGonespamspamBeGonespammaksimov.org> wrote:
{Quote hidden}

>

2009\05\26@211932 by Xiaofan Chen

face picon face
On Tue, May 26, 2009 at 10:47 PM, Herbert Graf <TakeThisOuThkgrafEraseMEspamspam_OUTgmail.com> wrote:
> Pretty much every consumer electronics device you buy today uses a very
> small subset of hardware solutions (usually an ARM or MIPS based SOC,
> with a couple support components), and as little dedicated hardware as
> possible. The "meat" of the device is software, from the DSP routines
> running in a cell phone, to even much of the H264/VC1 decoding that went
> on in the first BluRay players (which is why they were so painfully
> slow, more modern BluRay players have more hardware acceleration for
> H264/VC1, but there is still a boatload of software).
>
> A perfect example of this is inkjet printers. I opened up a recent model
> and found two very small chips on a VERY small PCB. The first chip was
> basically a USB interface, the second a motor driver. It's clear that a
> TON of the "guts" of this device's function is in the software running
> on the PC.

Another example may be the USB Bluetooth Dongle. They are
very cheap. But most of the software in on the PC side. So it is
very difficult to interface with them using less powerful embedded
USB host, even as powerful as PIC32.

USB Webcam may be another example.

> For the consumer this has meant relatively cheap prices (since software
> is very cheap to fix vs. an ASIC). Unfortunately, it has had a VERY
> frustrating negative effect: device lagginess. Compared to devices that
> used more specialized silicon today's devices are REALLY laggy. My sat
> radio receiver has tons of annoying pauses while manipulating the GUI.
> Pretty much every cell phone you buy (except really simple ones) have
> lag while pressing the hang up button.

When the power issues are mitigated (better power management, better
battery, better power scaling of the ICs), the problem may be get
less severe. However, the software seems to get bloated faster than
the progress of power technology. ;-)

> By far the most frustrating for me has been the "softwarizing" of power
> buttons. Very few power buttons actually switch off power anymore. My
> sat TV receiver simply turns off it's LEDs when I press the power
> button, it still pumps out an HDMI standby picture while "off". My
> monitor's power button doesn't work when it's in the middle of switching
> to a power saving mode, I have to wait for it to transition before it
> will respond to the power button.

Don't use the button on the device or the remote. Use the master power
button outside the device (on the extension cord or on the wall power
socket). ;-)

> Such is life when hardware becomes so cheap! :)
But the consumers want them to be even cheaper. ;-) So anything
can be done in software will be done in software for these type of
product. Luckily software can not produce the power or charge
the battery. It can not deal with RF power and antenna either. It
can probably help a bit on the EMC/EMI issues but not too much.
So I think there are still hardware engineers needed. ;-)
And all these stuff still need a housing and other plastics, so
I think mechanical engineers are even safer. ;-)

--
Xiaofan http://mcuee.blogspot.com

2009\05\26@230819 by Sean Breheny

face picon face
On Tue, May 26, 2009 at 9:19 PM, Xiaofan Chen <RemoveMExiaofancspamTakeThisOuTgmail.com> wrote:
> But the consumers want them to be even cheaper. ;-) So anything
> can be done in software will be done in software for these type of
> product. Luckily software can not produce the power or charge
> the battery. It can not deal with RF power and antenna either. It
> can probably help a bit on the EMC/EMI issues but not too much.
> So I think there are still hardware engineers needed. ;-)
> And all these stuff still need a housing and other plastics, so
> I think mechanical engineers are even safer. ;-)
>

I have seen some AWFUL EMI produced by consumer products lately. I
really wonder how many companies selling cheap goods just "self
certify" for EMI and never worry about it?

My mom has a DVD player which has to be UNPLUGGED for anyone to listen
to AM radio anywhere in the house. (Philips brand, but of course, made
in China - I don't claim that this is an indication of lack of quality
by itself, but along with the overall construction of the device, it
IS an indication of how much effort went in to cutting out every bit
of cost, apparently INCLUDING the design effort and time to meet
EMI/EMC requirements decently.)

Somehow, it is managing to radiate hash all over the AM broadcast
spectrum via the shield on the coax cable attached to it,
whenever it is plugged in (to the AC mains), regardless of whether it
is fully powered on or not.

Also, in my apartment, HF radio reception is very difficult because of
something which produces large amounts of AC buzz. I have turned off
everything I own, checked all the neighboring streetlights to make
sure none are malfunctioning in any obvious way, it is still horrible.
If I just go down the street, it gets better. I think that the people
upstairs must have some poorly-designed consumer device with a similar
power supply EMI problem.

Sean




> --
> Xiaofan http://mcuee.blogspot.com
> -

2009\05\26@232123 by Herbert Graf

picon face
On Wed, 2009-05-27 at 09:19 +0800, Xiaofan Chen wrote:
> Don't use the button on the device or the remote. Use the master power
> button outside the device (on the extension cord or on the wall power
> socket). ;-)

I do do that, and for most devices it works. The problem is some
devices, when deprived of power, will revert to "default states" when
powered back up. In the case of a TV it may select the Ant input on cold
power up, which is very annoying when all you use is the HDMI input. In
other cases the boot time of the device is very long (i.e. my sat tv
receiver can take a few minutes before it's showing a picture). The
simple fact is many devices are now designed with the assumption that
power is never taken away from them.

An ideal world for me would be if software for these devices was open
source. The perfect example of how amazing this can be for consumers is
the WiFi routers that are open source. These devices are 10 times better
when running user generated firmware then the stock firmware. Look how
much more useful the original xbox became once it's software was
"hacked".

TTYL

2009\05\27@035001 by Vitaliy

flavicon
face
Alan B. Pearce wrote:
> >We ended up writing our own UART library. :)
>
> That is what I am going to do too.
>
>>I used the Microchip's UART module interface as an
>>example of how *not* to write code.
>>Homegrown Microchip library code is pretty awful.
>
> Well, I am figuring on using the code from the uart2.c module tat comes
> with
> the USB framework as a starting point, unless you happen to have something
> better you can point me at.

Have you seen this?

http://www.ece.msstate.edu/courses/ece3724/main_pic24/docs/index.html

I was impressed enough with the code to buy the book. Sadly, the book is a
bit of a disappointment. :(  But, the libraries look interesting, I think it
is possible to borrow some ideas from.

Vitaliy

2009\05\27@040826 by Alan B. Pearce
face picon face
>Have you seen this?
>
> http://www.ece.msstate.edu/courses/ece3724/main_pic24/docs/index.html
>
>I was impressed enough with the code to buy the book. Sadly, the book
>is a bit of a disappointment. :(  But, the libraries look interesting,
>I think it is possible to borrow some ideas from.

I have seen that site before, but looking at the UART library, it seems to
have all sorts of calls that are dependant on their own OS called ESOS. The
number of calls listed rather put me off, as there are heaps there not
relevant to me. I haven't dug very deep into it at all though.

(I note that those pages are built using doxygen, so whoever was looking at
the documentation things recently may like to peruse them to see the 'how
its done').

2009\05\27@042656 by Tamas Rudnai

face picon face
On Wed, May 27, 2009 at 9:08 AM, Alan B. Pearce <Alan.B.PearceEraseMEspam.....stfc.ac.uk>wrote:

> (I note that those pages are built using doxygen, so whoever was looking at
> the documentation things recently may like to peruse them to see the 'how
> its done').
>

It was me, thanks for the notice. Pretty much that's what I wanted to
achieve and now the documentation is pretty much in this state already.

Thanks,
Tamas
--
http://www.mcuhobby.com

2009\05\27@081304 by Gerhard Fiedler

picon face
William "Chops" Westfield wrote:

> On May 26, 2009, at 10:25 AM, sergio masci wrote:
>
>>> Why wouldn't I, if I already did find it out?
>>
>> I duno, maybe because you'd be helping your own competion?

See, I'm doing quite well as I'm doing. So I can really afford to let
them know if I found out something about their product that they didn't
know. If this helps them, and everybody who's using their product, all
the better.

Besides, it's up to you whether you think of your "competition" as
colleagues or competition. In general, I think life is better if
thinking of them as colleagues. (Even if some of them are pricks... :)

>> Maybe because it would take valuble time to produce an example
>> without including too much of your propritry code?

Depending on the exact situation, I may not go to great lengths to
produce something just to convince them that there's something wrong.
But letting them know what I already have found out doesn't cost a lot
of valuable time.

>> Maybe because you figure the best library should actually be the one
>> to survive?

Exactly. My contribution is just another factor (or not) in the survival
process. Think of it this way: I think that buying libraries from people
who actually listen to valuable customer feedback is a good thing. So I
want these libraries and library writers to have a competitive
advantage. They only have it if they actually do get valuable customer
feedback, so when I have some, I give it to them. The ones that use my
feedback will increase their chances of survival; the ones that don't
won't. Which supposedly will tilt the market in the direction I want it
(infinitesimally, but still :)

> OTOH, The main reason to report bugs to a vendor is so that the NEXT
> revision of their code you incorporate into your products doesn't
> have the same bugs.  Having a "local patch list" for purchased
> software gets to really suck, pretty quickly...

Right. Good source code management and merge tools help a bit, but it
still sucks :)

Gerhard

2009\05\29@051758 by Vitaliy

flavicon
face
sergio masci wrote:
> I have been reading your posts VERY carefully and it seems to me that you
> are spending a great deal of time makeing your software re-usable. In
> other words designing, implementing and debugging interfaces between
> components of your modules AND actually generating app code that interacts
> with your libraries (modules or whatever you want to call them).

I'm sorry you got this impression, Sergio -- I assure you it isn't true.
It's actually quite surprising, because I'm almost positive that Gerhard and
Olin think that my approach to programming is undisciplined. :)

If you're interested, take a look at some of the old code I've worked on:

http://www.scantool.net/scantool/downloads/12/scantool_net114src.zip

The first version took two months to write, and was released in June of
2002.  I worked on it with another programmer (my contribution was smaller
than his). The project was largely abandoned by 2005. While we tried to keep
the modules cohesive, we could not avoid putting a lot of unrelated code, in
the same module. The functions are very long and suffer from the same lack
of cohesion. Some of the files grew to over 1000 lines. The longer we worked
on the code, the harder it became to change and maintain it.

There was a successor project that we worked on, that took a lot more time
and resources, and suffered from many of the same problems. It never saw the
light of day.

As I've said before, making software reusable is not the most important goal
for us. The primary reason we adopted the OOP approach to programming, is to
help manage complexity on large projects. It boils down to:

- Keeping the modules ("objects") small and cohesive
- Minimizing the number of connections b/w the objects (loose coupling)
- Grouping the small objects into larger "assemblies"

Reusable code is really just a byproduct of this method. It just happens
that the same properties that make code easy to understand, change, and
maintain also make it easy to reuse.


> It also
> seems to me that when you talk about the efficiency you have achived
> with your code re-use that all the VERY hard work you are putting into it
> up front is being disregarded, as though it is somehow free.

We're not disregarding anything. If you've read my other posts, you know
that I am a big proponent of iterative development. The changes we make are
incremental, and we put the code we write to use, very quickly. All the
while, we keep adding functionality, and refactoring it. The more time we
spend on the code, the better it gets. Elsewhere, the opposite is often
true: the code gets uglier and more bloated with time.

Sure, it does take more thought and discipline to program this way. However,
I do not think it takes more time, certainly not in the long run. It feels
great to come back to the code you have not touched in months, and quickly
understand how it fits with the rest of the system. Thinking in objects also
greatly facilitates communicating ideas with other developers. Reusable code
is icing on the cake. :)


> You claim 85% code re-use and you say that "typically ... Firmware
> development takes many many months" and that you use "PICs with 256k of
> flash and 16k of RAM" this begs the question - what the hell are you
> building?

This, for example:

http://www.ecusim.com

It is a little device that pretends to be an on-board car computer. To be
honest, the production version has only 128k of Flash and 8k of RAM, and we
haven't hit either limit, yet. The first version made its debut in November
of last year, at the SEMA Show. We've gone through a number of revisions
since then, and will be releasing a new version that supports multiple ECUs
in the same device, next week.

There are three more products that share much of the code, scheduled to be
launched in the coming weeks and months.

Vitaliy

2009\05\29@053529 by Vitaliy

flavicon
face
Xiaofan Chen wrote:
>>> Is that true? I thought there were too many software and to a lesser
>>> extent firmware developer and not enough hardware developers? ;-)
>>
>> My cousin (an EE) told me that hardware design at Kyocera had been
>> reduced
>> to "hook up this module to this module, here's a diagram that shows you
>> how".
>
> This will not work for many sections, at least not for our product (PLC
> related).

I'm sure my cousin was exaggerating a bit. :)


{Quote hidden}

I certainly did not mean to say that hardware is less important than
software. I'm sorry if it came through like that. Both are necessary to make
a good product.

However, it does seem that hardware design is akin to civil engineering: it
relies more on "pre-canned" solutions, and is easier for people to master
because it's more tangible. It takes far less time to develop hardware for a
device, than it takes to write software for that same device. Unless we're
talking about switching power supplies or RF transceivers. :)


> You will not be able to finish our hardware design in a
> napkin even though I did receive a good power supply circuits
> on a napkin from a guru a few years back.

I used "design on a napkin" as a figure of speech, normally we use less
glamorous means -- notepads, whiteboards, and CAD software. :)

Vitaliy

2009\05\29@054532 by Vitaliy

flavicon
face
Xiaofan Chen wrote:
>> You claim 85% code re-use and you say that "typically ... Firmware
>> development takes many many months" and that you use "PICs with 256k of
>> flash and 16k of RAM" this begs the question - what the hell are you
>> building?
>>
>
> Because the hard work is in the 15%. ;-)
>
> Seriously, I think that is about right. We reuse a lot of hardware design
> as well. But sometimes the 10% of the circuits may take 90% of the time
> for the design.

Yes, same here. To go back to the origins of this thread, it makes sense to
spend most of one's time on developing new functionality, rather than
reinventing the wheel.


> By the way, 256KB firmware can be a lot work. I understand this one
> (I have never written any firmware above 2k words or 4KB for work).

Yes, it takes more than a few hundred lines of code to fill these puppies
up. :) Compilers take a 10K .c file, and compress it down to 1K of PIC
assembly. Plus, you can make lots of changes to the code, without increasing
its size. Moreover, refactoring a program can *reduce* its size.

But I'm not complaining. :) It's nice to have more cycles, code space, and
RAM than you need.

Vitaliy

2009\05\29@055116 by Xiaofan Chen

face picon face
On Fri, May 29, 2009 at 5:35 PM, Vitaliy <EraseMEspamspammaksimov.org> wrote:

> However, it does seem that hardware design is akin to civil engineering: it
> relies more on "pre-canned" solutions, and is easier for people to master
> because it's more tangible.

Yes you are probably right that hardware design relies more and more
on pre-canned solutions. But there are many "cans", so I am not so
sure whether it is easier for people to master or not.

> It takes far less time to develop hardware for a
> device, than it takes to write software for that same device. Unless we're
> talking about switching power supplies or RF transceivers. :)

Even for switching power supplies, we rely more and more on
vendor recommended design whenever possible. For EMI/EMC
issues, the vendors often can not really help though.

And yes typically we finish the basic hardware design way ahead
of firmware. And often you have firmware updates (to fix the
anomalies) from time to time for a more complex design even
though the hardware has long been stable.


--
Xiaofan http://mcuee.blogspot.com

2009\05\29@055821 by Vitaliy

flavicon
face
Olin Lathrop wrote:
>> Olin admitted that there may be changes that would require
>> modifications of the template.
>
> Nothing requires changing the template, and I never said that.  I do
> occasionally change a template when I add something in a project that I
> think generalizes well to future projects.  However, this is quite
> unusual.

Olin, I could swear that I've read in one of your earlier posts what you
said in the second sentence above. I could not find the post, so I have no
choice but to apologize. I'm sorry.

Vitaliy

2009\05\29@061838 by Vitaliy

flavicon
face
Xiaofan Chen wrote:
> Yes you are probably right that hardware design relies more and more
> on pre-canned solutions. But there are many "cans", so I am not so
> sure whether it is easier for people to master or not.

I wish there were more good cans in the software world. :)


{Quote hidden}

Yup. I think it is really cool how something so intangible (software) can
affect a device in very tangible ways: for example, make it run cooler by
using less power.

By 2015, people will be updating the firmware in their cars the same way
they update Windows today. A message will pop up on the on-board computer,
and a synthesized voice will declare: "A software update is available for
your vehicle, that increases fuel mileage by 15%. Would you like to
install?"

No doubt there will be plenty of routine, trivial bug fixes. "An update is
available that prevents erroneous seat ejection. Skip (Y/N)?"

Vitaliy

2009\05\29@083456 by Gerhard Fiedler

picon face
Vitaliy wrote:

> sergio masci wrote:
>> I have been reading your posts VERY carefully and it seems to me that
>> you are spending a great deal of time makeing your software
>> re-usable. In other words designing, implementing and debugging
>> interfaces between components of your modules AND actually
>> generating app code that interacts with your libraries (modules or
>> whatever you want to call them).
>
> I'm sorry you got this impression, Sergio -- I assure you it isn't
> true. It's actually quite surprising, because I'm almost positive
> that Gerhard and Olin think that my approach to programming is
> undisciplined. :)

FWIW, I don't think that, and I'm almost positive that Olin doesn't
think that either (from what he wrote).

Gerhard

2009\05\29@105746 by Tony Smith

flavicon
face
{Quote hidden}

Let's see, in the past month I've updated my PC BIOS, my MP3 player, my GPS,
my PVR and my bike.  You mean it's going to get worse?

Better go check the toaster, I suppose.

Tony

2009\05\29@122919 by olin piclist

face picon face
Vitaliy wrote:
> By 2015, people will be updating the firmware in their cars the same
> way they update Windows today.

Argh, please, no!!!

You downshift because you are going down a hill, then your dashboard turns
all blue except for "Your fuel injection driver has experienced a critical
error.  Send report?   Y  N  ".  Meanwhile the engine is flooded with fuel
and accellerates out of control before choking on the extra fuel and coming
to a stop.  You try to restart, but the dash shows only "fuinj32.dll not
found, please contact your system administrator".

You futz around some and get to the message "New sofware required, download?
Y  N  ".  You say yes and a progress bar gets to 80% then stops moving and
nothing more you do changes the display.  In desperation you go outside, get
some tools out, disconnect the battery, wait 10 seconds, then reconnect the
battery.  When you get inside you see "Car previously not shut down
properly, some systems may not function.  Continue?  Y  N  ".  You're
desparate, so you say yes, and to your great surprise the car actually
starts and sortof drives, although sluggishly.

Ss you continue down the winding mountain road and make a hard right on a
inside hairpin, you realize something is wrong with the power steering unit
and it's fighting you turning the wheel back.  You try to slow down and
stop, but it all happens so fast.  Before you can do anything about it the
car drives into the guard rail.  The front end drags along the guard rail as
the back end swerves out into the path of a oncoming truck.  Your car is
hit, flips over, rolls over the guard rail, eventually coming to a stop on
the canyon floor 1200 feet below.  Three hours later the state troopers are
standing around by the wreck.  "The computer log says he deliberately turned
into the guard rail.  That matches the physical evidence and what the
trucker said.  What an idiot."


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\29@161954 by Vitaliy

flavicon
face
Gerhard Fiedler wrote:
>>> I have been reading your posts VERY carefully and it seems to me that
>>> you are spending a great deal of time makeing your software
>>> re-usable. In other words designing, implementing and debugging
>>> interfaces between components of your modules AND actually
>>> generating app code that interacts with your libraries (modules or
>>> whatever you want to call them).
>>
>> I'm sorry you got this impression, Sergio -- I assure you it isn't
>> true. It's actually quite surprising, because I'm almost positive
>> that Gerhard and Olin think that my approach to programming is
>> undisciplined. :)
>
> FWIW, I don't think that, and I'm almost positive that Olin doesn't
> think that either (from what he wrote).

Sorry, I just got that impression from our heated "documentation is evil"
and Agile debates. :))

Vitaliy

2009\05\29@162244 by Vitaliy

flavicon
face
Tony Smith wrote:
> Let's see, in the past month I've updated my PC BIOS, my MP3 player, my
> GPS,
> my PVR and my bike.  You mean it's going to get worse?
>
> Better go check the toaster, I suppose.

The funny thing is, firmware updates for ECUs (engine controllers, abs, etc)
have been around for years. That's what the SAE J2534 (pass-thru
programming) is all about: its purpose is to make reflashing easier.

Vitaliy


2009\05\29@163750 by Mark E. Skeels

flavicon
face
I have received a letter in the mail telling me that my Kia Sorrento's
OCS electronic control module, located inside the passenger seat
cushion, has a firmware error which causes the passenger side air bag to
remain unactivated at times even when a passenger is sitting in the seat.

I am told to call the local dealer and they will set up an appointment
to upload "corrected" firmware.

Mark


Vitaliy wrote:
{Quote hidden}

2009\05\29@170104 by Tamas Rudnai

face picon face
On Fri, May 29, 2009 at 9:37 PM, Mark E. Skeels <
RemoveMEmskeelsEraseMEspamEraseMEcompetitionelectronics.com> wrote:

> I have received a letter in the mail telling me that my Kia Sorrento's
> OCS electronic control module, located inside the passenger seat
> cushion, has a firmware error which causes the passenger side air bag to
> remain unactivated at times even when a passenger is sitting in the seat.
>
> I am told to call the local dealer and they will set up an appointment
> to upload "corrected" firmware.
>

It is nothing new about this. Most of the times they do not even let you
know if the failure is not threatening life or cause danger. Whey you bring
your car to the service they upgrade it silently for you and that includes
ESR, ABS and ignition systems as well as the built in GPS.

Tamas
--
http://www.mcuhobby.com

2009\05\29@170502 by Vitaliy

flavicon
face
Mark E. Skeels wrote:
>I have received a letter in the mail telling me that my Kia Sorrento's
> OCS electronic control module, located inside the passenger seat
> cushion, has a firmware error which causes the passenger side air bag to
> remain unactivated at times even when a passenger is sitting in the seat.
>
> I am told to call the local dealer and they will set up an appointment
> to upload "corrected" firmware.

It used to be very common for car companies to do massive EPA-mandated
recalls to correct emissions problems: situations where the ECU would not
set the MIL ("check engine"), even when the emissions level was exceeding
the EPA limits.

Vitaliy

2009\05\29@224617 by Tony Smith

flavicon
face
> > Let's see, in the past month I've updated my PC BIOS, my MP3 player, my
> > GPS,
> > my PVR and my bike.  You mean it's going to get worse?
> >
> > Better go check the toaster, I suppose.
>
> The funny thing is, firmware updates for ECUs (engine controllers, abs,
etc)
> have been around for years. That's what the SAE J2534 (pass-thru
> programming) is all about: its purpose is to make reflashing easier.


That's true, but it's not the user doing it, nor is the car telling the user
to go and do it.  

Oh, and there was the camera as well.  Maybe instead of spring cleaning we
can have flashing instead when the weather warms up.

Tony

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...