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 <spam@maksimov.org> wrote:
>> 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. =A0Most 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. =A0Code 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 we=
re
> 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:
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D
> /* Configure uart1 receive and transmit interrupt */
> =A0 ConfigIntUART1(UART_RX_INT_EN & UART_RX_INT_PR6 &
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0UART_TX_INT_DIS & UART_TX_INT_PR2);
> /* Configure UART1 module to transmit 8 bit data with one stopbit.
> =A0 Also Enable loopback mode */
> =A0 baudvalue =3D 5;
> =A0 U1MODEvalue =3D UART_EN & UART_IDLE_CON &
> =A0 UART_DIS_WAKE & UART_EN_LOOPBACK &
> =A0 UART_EN_ABAUD & UART_NO_PAR_8BIT &
> =A0 UART_1STOPBIT;
> =A0 U1STAvalue =3D UART_INT_TX_BUF_EMPTY &
> =A0 UART_IrDA_POL_INV_ZERO & UART_SYNC_BREAK_DISABLED &
> =A0 UART_TX_ENABLE & UART_INT_RX_3_4_FUL &
> =A0 UART_ADR_DETECT_DIS &
> =A0 UART_RX_OVERRUN_CLEAR;
> =A0 OpenUART1(U1MODEvalue, U1STAvalue, baudvalue);
> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> 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:
>
> =A0 =A0Uart_Init();
> =A0 =A0Uart_SetBaudRate(9600);
> =A0 =A0Uart_Open();
>
> Other ugly uChip functions can be dealt with, in the same way. The advant=
age
> 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 cod=
e.
> 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 cod=
e,
> refactoring may get you where you want to be faster than if you had to wr=
ite
> 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 reus=
e.
> 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
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

-- =

http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist