Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
12/28/07 16:01
Read: times


 
#148828 - Where is the borderline to stumble on
Responding to: ???'s previous message
Erik Malund said:
"flexibility is good" is pure unadulterated male cow manure.


LOL ... What an odourful way of (out)putting it. This reminds me of a selenium rectifier that has a horrible smell when fried - more suitable name for it would be "selenium rectumfier".

You have that completely right. Trying to code fully independent code that is usabe AS SUCH everywhere is doomed to fail and when miraculously passed compilation it is VERY hard to test. Any modification to the code should be tested in all target platforms. I understand this and have gone through the PITA of it as I was stubborn enough to stumble on the lying log that was clearly marked by someone more wiser than me.

It is very good practise to make portability questionable. This way it comes clear that it is not at all clear when to make such code and when not.

Erik Malund said:
PS YES, I believe in reuse of code but I do not believe in reusable code. If I have something similar to what I need in my files I take it and modify it to an exact application match rather than starting from scratch but ..<snip>


Well, isn't communication wonderful. I have noticed that we agree 99 percent of the issues we have been discussing but still we seem to tangle on the few differences there are. Most welcome discussion after all these years. I attach a sample header file whic has served my coding unaltered for 15 years now. I believe You will find it quite familiar.

// -----------------------------------------------------------------------
// Timer.h
// Definitions and declarations for the Timer module
// -----------------------------------------------------------------------
#ifndef	Timer_h
#define	Timer_h

#include "platform.h"

// -----------------------------------------------------------------------
// Public functions
// The resolution in TimerInit is used to define the counter rate in
// counts/second.
// -----------------------------------------------------------------------
extern void     TimerInit       ( uint16_t aResolution );
extern uint16_t TimerGetCounter ( void );
extern void     TimerPutCounter ( uint16_t aValue );
extern void     TimerWait       ( uint16_t aValue );

// -----------------------------------------------------------------------
// Interfacing functions that are NOT in the library. These must be
// supplied by the calling program because these are highly hardware
// dependent.
// ApplicationTimerCallback - Called once for every value decrement
//                            when in TimerWait loop.
// ApplicationCpuSpeed      - Returns the clock frequency in Hz
// -----------------------------------------------------------------------
extern  void     ApplicationTimerCallback ( void );
extern	uint32_t ApplicationCpuSpeed      ( void );

#endif
// -----------------------------------------------------------------------
// EOF: Timer.h
// -----------------------------------------------------------------------


List of 34 messages in thread
TopicAuthorDate
Having problem on using interrupt            01/01/70 00:00      
   Answers            01/01/70 00:00      
      not so fast, Cristoph and to Ragu            01/01/70 00:00      
         Serial comm is slow.            01/01/70 00:00      
            if you read the OP            01/01/70 00:00      
               good interupts            01/01/70 00:00      
                  AAAAAARGH            01/01/70 00:00      
                     not AAAAAAAARGH            01/01/70 00:00      
                        OH YES            01/01/70 00:00      
                           do You ever avoid "non-debuggable"?            01/01/70 00:00      
                              always            01/01/70 00:00      
                                 nice            01/01/70 00:00      
                                    a trick for "long ISRs" better than a RTOS            01/01/70 00:00      
         Buffered RX            01/01/70 00:00      
            not much difference            01/01/70 00:00      
               You are right            01/01/70 00:00      
   Sucess with interrupts            01/01/70 00:00      
      Isn't it too short?            01/01/70 00:00      
         the reason for circular buffers            01/01/70 00:00      
            Worst case, instead of average            01/01/70 00:00      
               absolutely, just worst case is not as bad            01/01/70 00:00      
                  single, double and ring buffer            01/01/70 00:00      
                     single, double and ring buffer app dependent            01/01/70 00:00      
         and some more reasons to use (circular) buffers            01/01/70 00:00      
            buffer overflow error            01/01/70 00:00      
               Buffer overflow handling            01/01/70 00:00      
                  Buffering options            01/01/70 00:00      
                     Beauty contest !            01/01/70 00:00      
                        flexible is the best?            01/01/70 00:00      
                        Simplicity is always better            01/01/70 00:00      
                           simple is another word for            01/01/70 00:00      
                              Where is the borderline to stumble on            01/01/70 00:00      
                                 Copper Oxide            01/01/70 00:00      
               please exclude me from the 'we'            01/01/70 00:00      

Back to Subject List