68HC908 Convert frequency to cycle duration doesn't work

[holgerkeil]

Hi

I wanna convert a frequency in Hz to its cycle duration in µs. Example, frequency is 440, result shall be 2273

I tried this:

int round(double number){

  return (number >= 0) ? (int)(number + 0.5) : (int)(number - 0.5);

}

int FrqGetUs(int frq){

  double period;

  period=(1/frq)*1000000;

  return (round(period));

}

period=FrqGetUs(440);

but it doesn't work. In circuit, the µC appears to be caught in a reset-loop, and while in debugger, the µC freezes somewhere in ASM on the calculation of  period=(1/frq)*100000; debugger reports "Communication with target lost".

Whats wrong with it?

Original Attachment has been moved to: pdeclaration.h.zip

Original Attachment has been moved to: MCUinit.c.zip

Original Attachment has been moved to: MCUinit.h.zip

Original Attachment has been moved to: drehteller_v2.zip

Original Attachment has been moved to: lib_hc08c_device_include.zip

[tonyp]

@Ian:

I'm afraid this may again open one of those long-ended discussions as to whether one should program in C or ASM.  And, truly speaking, if there are no other compelling reasons (speed, size, etc.) there is no correct answer, other than "what makes you feel good."

As far as well-architectured microcontrollers are concerned -- like Freescale's -- I'm categorically for ASM only.  But that's just me, a die-hard minority!  Would I program a PIC in assembly, though?  I seriously doubt it.  Would I program in ASM for ARM?  You bet!

My best answer to "how far one would go .. before switching to C" is "as far as one would go before switching away from C to something else."  Would you reach a point of size or complexity that you would consider abandoning C for something 'better'?  Possibly not.  So, why would I do so with ASM?

You make it sound like if your project gets too big or too complex, you 'certainly' can't easily do it in ASM and you will inevitably have to switch to C.  Having far too many projects on my back to disprove such claims, it all becomes a matter of comfort level.  If you're comfortable with something, it does not make sense you change it, especially when that something gives better results from the alternatives.

(I will end with this: For me, the only reason I would consider using C for MCU development is if somebody above me told me I had to.  But, luckily, where I work, there's no one above me! :smileyhappy:)

[iansmusical]

Hi Tony,

Not at all, I'm aware of the benefits and otherwise of C or ASM but just didn't want to miss a trick with regard to the smaller devices :-) However, before I started with S08's I did write assembler for PICs and nearly lost the will to live but at the time there wasn't a free C compiler for them and hence why I switched to Freescale. What I've not done (yet) is look into programming assembler with S08's and of course I've overlooked the PIC's RISC vs S08's CISC instruction set. I am a big fan of assembler like yourself but sadly couldn't do my daytime job in it alone, well not after you've seen the immense instruction set for the MPC5xxx PowerPC's ;-)

Thank you for your interesting answer, I appreciate you taking the time to give it.

Ian

[tonyp]

@Ian:

>I'm aware of the benefits and otherwise of C or ASM but just didn't want to miss a trick with regard to the smaller devices :-)

What I meant about using ASM exclusively for smaller devices (say, up to 8K Flash) is my very generic advice based on experience from many diverse projects.  (It is by no means is a hard rule.)  Using an average complexity application for 8-bit MCUs, I've come to the conclusion that the smaller members can only show their full potential with assembly language programming, exactly for the reasons you noted -- the inherent self-optimization and compactness of assembly language (a concept not very easily understood by those who haven't used assembly extensively.)  Using C, in the general case, means putting less actual functionality into the chip than its full potential as revealed by using ASM on the same chip.  Of course, this is true regardless of memory size (ASM always allows for more functionality than C into the same code space), but as memory increases, the number of average C-based apps that can fit increases also.  This number is simply much lower for ASM-based programs.  Think of it as using compression on your EXE file.  Compiler produces 10K, compressor gets it down to 4K.  Similar effect with C and assembly.  So, by using ASM you can target lower memory devices for the same application written in C.  My personal estimates (which are by no means hard science, and I won't take the time to over-analyze here, plus the risk of many others coming out with completely different claims, and starting an endless feud) seem to indicate that the limit is around 8K, i.e., below 8K, ASM is pretty much the only choice for any serious app.  Above that C starts to be a player but it's always ASM that has the advantage.

>What I've not done (yet) is look into programming assembler with S08's

Well, if you decide to start, you may want to have a look at my (shameless plug) macro assembler ASM8 which comes with a whole bunch of well-tested basic library code.

[matthewkendall]

You have several, likely unrelated, problems.

The constant resetting and inability to work with the debugger is either going to be a watchdog (ensure any watchdog present is kicked regularly, or disabled entirely for debugging) or a hardware issue.

Once you get past that your calculation has a straightforward C problem.

period = (1/frq)*1000000;

Since 1 and frq are both integers, 1/frq is calculated using integer arithmetic and will produce the result zero or one. That will then be multiplied by the integer 1000000, before the result is finally converted to double and assigned to period. That is not what you want. You want the whole calculation to be performed using floating point arithmetic. To achieve this either the constant 1 or frq must be a floating point type. The conventional thing to do is to ensure the constant 1 is floating point by writing it with a trailing decimal point, like this:

period = (1./frq)*1000000;

[tonyp]

I suppose the result is used as a counter in an ASM loop, which hangs?

Looks like a COP issue.  But, have you checked the value of period?

Why don't you avoid floats and use integers instead?  Regardless, period could be non-float, and

period=(1/frq)*1000000;

could be rewritten as

period=1000000/frq;

BTW, frq being int, 1/frq would be zero, I suppose, making your loop count for very-very long.  Don't you need to first cast frq to float? (I'm not that good with C)

[holgerkeil]

Hey Tony.

it should be used as a counter later, but it isn't used right now. It does not eaven reach return(), it freezes on calculation of period=(1/frq)*1000000;  in RTSHC08.C at address F157: PSHX.

I'm not good in C either, this is my very first work. I thought it may be enough, if I divide an integer, and the result is (maybe) a float, it's enough to have the variable carrying the result to be declared as a float. So if you're right, that might have been some div by zero operation.

However, now I'm really confused. I'd changed it to period=1000000/frq; as you suggested, and it keeps freezing - in the debugger:

I put it in circuit to doublecheck, and it works.

Huh? So why it calculates correctly in realtime in circuit, and not in debugger in step mode?