8-bit MicrocontrollersのトピックRe: 68HC908 Convert frequency to cycle duration doesn't work

68HC908 Convert frequency to cycle duration doesn't work

holgerkeil — Thu, 16 Oct 2014 19:44:36 GMT

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

Re: 68HC908 Convert frequency to cycle duration doesn't work

tonyp — Thu, 16 Oct 2014 20:41:53 GMT

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)

Re: 68HC908 Convert frequency to cycle duration doesn't work

holgerkeil — Thu, 16 Oct 2014 21:29:02 GMT

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?

Re: 68HC908 Convert frequency to cycle duration doesn't work

matthewkendall — Thu, 16 Oct 2014 22:49:56 GMT

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;

Re: 68HC908 Convert frequency to cycle duration doesn't work

tonyp — Fri, 17 Oct 2014 06:10:51 GMT

I would also check the possibility of stack corruption (either due to program error, or insufficient stack allocation) which might also cause resets (e.g., due to illegal opcode or address). Although this does not seem to explain the difference in real vs debugger, but it's worth investigating (e.g., is the debugger version the exact same binary?)

Re: 68HC908 Convert frequency to cycle duration doesn't work

holgerkeil — Fri, 17 Oct 2014 13:33:21 GMT

Hey you guys, thanks for helping. Im just within this debugger issue and found out: If I remove some code, it works. If I remove some other code instead, it works as well. Could it be possible that I'm simply running out of flash? However, I'd expect a warning if I try to write more code than the targets size is. And well, if the debugger access via MON08 may allocate some extra address space, that could be the explaination why it works in circuit but not in debug.

(I came across this cause I added two more example for() loops to the code, making it finally failing in circuit as well).

Best regards

Holger

Re: 68HC908 Convert frequency to cycle duration doesn't work

holgerkeil — Tue, 21 Oct 2014 08:56:32 GMT

Anybody else who can help? I hardly cannot believe that the 4k FLASH is already full. I have roughly 4K C sourcecode (including comments, formatings and stuff) and I thought that ASM is more compact than C

Re: 68HC908 Convert frequency to cycle duration doesn't work

tonyp — Tue, 21 Oct 2014 09:17:34 GMT

Yes, everything else being equal, ASM is always shorter than C but, in case you hadn't noticed, your code is in C, not ASM. :smileyhappy:

It's hard to tell what your actual problem might be.

Looking at the produced map file, you should be able to tell how much room your code takes, and where (in case some falls outside valid memory ranges).

Your programmer should also warn you if you try to put code outside the specific variant's memory ranges. (Hint: Are you using the correct variant setting in your compiler and/or programmer?)

If indeed you have an insufficient memory problem I suspect you can easily solve it by just removing the floating point library from your code. Floating-point is notoriously expensive in terms of code size (and even execution speed).

You can always do any basic calculations (like the ones you showed) using plain integer arithmetic. This should lower the code space needed for your app possibly enough to solve your problem.

Without having access to your full project details, it's hard for someone to offer you more advice.

Re: 68HC908 Convert frequency to cycle duration doesn't work

holgerkeil — Tue, 21 Oct 2014 09:33:10 GMT

Yes, the code is written in C. I thought it will be compiled to ASM by the IDE before its became loaded to the FLASH. However, this may not be that effective than directly coding in ASM (but the one and only time i wrote ASM was on 6502 - 20 years ago).

I've got a warning "Address out of range" sometimes during debugging, but not while programming. Probably this is an issue with the P&E interface - or better to say - it's software. The variant should be selected correctly.

I think there may be still the float library loaded, I'll doublecheck this later.

Apart from this, there is no problem to give access to the full code, it's not confidential. I can upload it later this evening.

Thanks so far.

Holger

Re: 68HC908 Convert frequency to cycle duration doesn't work

tonyp — Tue, 21 Oct 2014 09:58:27 GMT

OK, technically, every language is eventually translated to machine code (which, because of its one-to-one correspondence with ASM, can be considered the same as saying to ASM). But, when we talk what language one uses we mean before the compiler does its job. Othewise, everybody would claim to be programming in assembly language, and there would be no mention of the higher level language.

"Address out of range" during the execution of what instruction? Can you see the disassembly (from your debugger) and post that? Also, please mention the exact MCU variant so we know what exactly we're dealing with.

Although I do all my MCU programming 100% in ASM, and my opinion could be viewed as biased by some, I would argue that, at least for the smaller memory devices (say, up to 8K Flash), programming in C is not the right approach, except for trivial apps. So, either get a bigger memory MCU, or switch this project to ASM.

Re: 68HC908 Convert frequency to cycle duration doesn't work

iansmusical — Tue, 21 Oct 2014 11:40:34 GMT

Hi Tony,

Not wanting to hijack the thread but I was interested in your comment regarding not using C in smaller memory devices. Would you elaborate as to why you'd make this choice? I presume it's simply the overhead of C and coding more efficiently in assembler? While I'm also a big fan of assembler I would perhaps question how far one would go with it before switching to C.

Thanks,

Ian

Re: 68HC908 Convert frequency to cycle duration doesn't work

holgerkeil — Tue, 21 Oct 2014 12:26:10 GMT

Tony Papadimitriou schrieb:

But, when we talk what language one uses we mean before the compiler does its job. Othewise, everybody would claim to be programming in assembly language, and there would be no mention of the higher level language.

Ok for that, but that doesn't count when it is about the code size used in flash memory. I would love to code this in ASM, however it would take me years to finish since as I've learned 20 years ago, I found ASM kinda annoying. I admire everybody who can to this with ease.

If I recall correctly, this was a branch or jump instruction where that warning appeared. The device is MC68HC908JL3ECDWE. I will check for the debugger output later when I'm @home and will post the scourcecode as well. Its not a big thing, should become a control for rotary plate for 360° photography. Decodes a 10throw rotary switch, generates pulses for a stepmotor, two pushbuttons, two LEDs. It just misses the acceleration ramp and 48kHz modulated code output for infrared transmitter (camera remote).

Re: 68HC908 Convert frequency to cycle duration doesn't work

tonyp — Tue, 21 Oct 2014 12:42:24 GMT

@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:)

Re: 68HC908 Convert frequency to cycle duration doesn't work

iansmusical — Tue, 21 Oct 2014 13:10:08 GMT

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

Re: 68HC908 Convert frequency to cycle duration doesn't work

tonyp — Tue, 21 Oct 2014 17:53:42 GMT

>If I recall correctly, this was a branch or jump instruction where that warning appeared. The device is MC68HC908JL3ECDWE.

OK, if it's jumping to an illegal address for this MCU variant, it would cause a reset. Or, if it jumps to an area where there is NO valid opcode (e.g., data or garbage), again it would cause a reset.

To get rid of one possible problem at a time (not necessarily in this order):

* Verify object code address range is valid (by examining the produced map file.)

* Verify the JMP instruction is jumping where it should. If not, ask why. E.g., if it jumps to the correct label, but it turns out to be in nowhere land, then maybe your code has wrapped around the 64K limit, or some similar problem.

* Try to remove floating point, and make needed changes to your code.

Re: 68HC908 Convert frequency to cycle duration doesn't work

tonyp — Tue, 21 Oct 2014 18:59:27 GMT

@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.

Re: 68HC908 Convert frequency to cycle duration doesn't work

holgerkeil — Tue, 21 Oct 2014 19:59:51 GMT

First of all, I cannot reproduce the warning. I'd tried so many things the past days, that I can't recall exactly under what circumstances it happens. What I know is, it was shown only in full chip simulation, while in-circuit the connection to the target gots lost instead.

Then I took a look on the project.map file (it is still the version with floating point), but thats double dutch for me. I'm going to post it here, maybe you can point on the important things for me:

Processor : Freescale HC08

Memory Model: SMALL

File Format : ELF\DWARF 2.0

Linker : SmartLinker V-5.0.34 Build 8120, Apr 30 2008

*********************************************************************************************

FILE SECTION

---------------------------------------------------------------------------------------------

MC68HC908JL3.C.o Model: SMALL, Lang: ANSI-C

Start08.c.o Model: SMALL, Lang: ANSI-C

MCUinit.c.o Model: SMALL, Lang: ANSI-C

main_v1_2.c.o Model: SMALL, Lang: ANSI-C

RTSHC08.C.o (ansi.lib) Model: SMALL, Lang: ANSI-C

*********************************************************************************************

STARTUP SECTION

---------------------------------------------------------------------------------------------

Entry point: 0xEC8C (_Startup)

_startupData is allocated at 0xEC95 and uses 6 Bytes

extern struct _tagStartup {

unsigned nofZeroOut 0

_Copy *toCopyDownBeg 0xF369

} _startupData;

*********************************************************************************************

SECTION-ALLOCATION SECTION

Section Name Size Type From To Segment

---------------------------------------------------------------------------------------------

.init 149 R 0xEC00 0xEC94 ROM

.startData 10 R 0xEC95 0xEC9E ROM

.text 1738 R 0xEC9F 0xF368 ROM

.copy 2 R 0xF369 0xF36A ROM

.abs_section_0 1 N/I 0x0 0x0 .absSeg0

.abs_section_1 1 N/I 0x1 0x1 .absSeg1

.abs_section_3 1 N/I 0x3 0x3 .absSeg2

.abs_section_4 1 N/I 0x4 0x4 .absSeg3

.abs_section_5 1 N/I 0x5 0x5 .absSeg4

.abs_section_7 1 N/I 0x7 0x7 .absSeg5

.abs_section_a 1 N/I 0xA 0xA .absSeg6

.abs_section_d 1 N/I 0xD 0xD .absSeg7

.abs_section_1a 1 N/I 0x1A 0x1A .absSeg8

.abs_section_1b 1 N/I 0x1B 0x1B .absSeg9

.abs_section_1d 1 N/I 0x1D 0x1D .absSeg10

.abs_section_1e 1 N/I 0x1E 0x1E .absSeg11

.abs_section_1f 1 N/I 0x1F 0x1F .absSeg12

.abs_section_20 1 N/I 0x20 0x20 .absSeg13

.abs_section_25 1 N/I 0x25 0x25 .absSeg14

.abs_section_28 1 N/I 0x28 0x28 .absSeg15

.abs_section_3c 1 N/I 0x3C 0x3C .absSeg16

.abs_section_3d 1 N/I 0x3D 0x3D .absSeg17

.abs_section_3e 1 N/I 0x3E 0x3E .absSeg18

.abs_section_fe00 1 N/I 0xFE00 0xFE00 .absSeg19

.abs_section_fe01 1 N/I 0xFE01 0xFE01 .absSeg20

.abs_section_fe03 1 N/I 0xFE03 0xFE03 .absSeg21

.abs_section_fe04 1 N/I 0xFE04 0xFE04 .absSeg22

.abs_section_fe05 1 N/I 0xFE05 0xFE05 .absSeg23

.abs_section_fe06 1 N/I 0xFE06 0xFE06 .absSeg24

.abs_section_fe08 1 N/I 0xFE08 0xFE08 .absSeg25

.abs_section_fe09 1 N/I 0xFE09 0xFE09 .absSeg26

.abs_section_fe0e 1 N/I 0xFE0E 0xFE0E .absSeg27

.abs_section_ffff 1 N/I 0xFFFF 0xFFFF .absSeg28

.abs_section_21 2 N/I 0x21 0x22 .absSeg29

.abs_section_23 2 N/I 0x23 0x24 .absSeg30

.abs_section_26 2 N/I 0x26 0x27 .absSeg31

.abs_section_29 2 N/I 0x29 0x2A .absSeg32

.abs_section_fe0c 2 N/I 0xFE0C 0xFE0D .absSeg33

.abs_section_ffde 34 R 0xFFDE 0xFFFF .absSeg34

.stack 48 R/W 0x80 0xAF Z_RAM

Summary of section sizes per section type:

READ_ONLY (R): 78D (dec: 1933)

READ_WRITE (R/W): 30 (dec: 48)

NO_INIT (N/I): 27 (dec: 39)

*********************************************************************************************

VECTOR-ALLOCATION SECTION

Address InitValue InitFunction

---------------------------------------------------------------------------------------------

*********************************************************************************************

OBJECT-ALLOCATION SECTION

Name Module Addr hSize dSize Ref Section RLIB

---------------------------------------------------------------------------------------------

MODULE: -- MC68HC908JL3.C.o --

- PROCEDURES:

- VARIABLES:

_PTA 0 1 1 42 .abs_section_0

_PTB 1 1 1 4 .abs_section_1

_PTD 3 1 1 12 .abs_section_3

_DDRA 4 1 1 2 .abs_section_4

_DDRB 5 1 1 2 .abs_section_5

_DDRD 7 1 1 2 .abs_section_7

_PDCR A 1 1 2 .abs_section_a

_PTAPUE D 1 1 3 .abs_section_d

_KBSCR 1A 1 1 0 .abs_section_1a

_KBIER 1B 1 1 0 .abs_section_1b

_INTSCR 1D 1 1 0 .abs_section_1d

_CONFIG2 1E 1 1 1 .abs_section_1e

_CONFIG1 1F 1 1 1 .abs_section_1f

_TSC 20 1 1 5 .abs_section_20

_TSC0 25 1 1 0 .abs_section_25

_TSC1 28 1 1 0 .abs_section_28

_ADSCR 3C 1 1 0 .abs_section_3c

_ADR 3D 1 1 0 .abs_section_3d

_ADICLK 3E 1 1 0 .abs_section_3e

_BSR FE00 1 1 0 .abs_section_fe00

_RSR FE01 1 1 0 .abs_section_fe01

_BFCR FE03 1 1 0 .abs_section_fe03

_INT1 FE04 1 1 0 .abs_section_fe04

_INT2 FE05 1 1 0 .abs_section_fe05

_INT3 FE06 1 1 0 .abs_section_fe06

_FLCR FE08 1 1 0 .abs_section_fe08

_FLBPR FE09 1 1 0 .abs_section_fe09

_BRKSCR FE0E 1 1 0 .abs_section_fe0e

_COPCTL FFFF 1 1 0 .abs_section_ffff

_TCNT 21 2 2 0 .abs_section_21

_TMOD 23 2 2 1 .abs_section_23

_TCH0 26 2 2 0 .abs_section_26

_TCH1 29 2 2 0 .abs_section_29

_BRK FE0C 2 2 0 .abs_section_fe0c

MODULE: -- Start08.c.o --

- PROCEDURES:

loadByte EC00 17 23 5 .init

Init EC17 75 117 1 .init

_Startup EC8C 9 9 1 .init

- VARIABLES:

_startupData EC95 6 6 6 .startData

- LABELS:

__SEG_END_SSTACK B0 0 0 1

MODULE: -- MCUinit.c.o --

- PROCEDURES:

MCU_init EC9F 33 51 1 .text

- VARIABLES:

_vect FFDE 22 34 0 .abs_section_ffde

MODULE: -- main_v1_2.c.o --

- PROCEDURES:

FrqGetUs ECD2 14 20 1 .text

delayus ECE6 22 34 1 .text

move ED08 16F 367 9 .text

main EE77 2A9 681 68 .text

- VARIABLES:

MODULE: -- RTSHC08.C.o (ansi.lib) --

- PROCEDURES:

_PUSH_ARGS_L F120 2D 45 1 .text

_ENTER_BINARY_L_LC F14D 23 35 1 .text

_IDIVMOD F170 69 105 1 .text

_SPLITSIGN F1D9 1C 28 1 .text

_LDIVMOD F1F5 CA 202 2 .text

_NEG_L_HX F2BF 13 19 2 .text

_ABS_L_HX F2D2 6 6 2 .text

_SPLITSIGN_L F2D8 A 10 1 .text

_LDIVS_k_is_k_div_j F2E2 2C 44 1 .text

_IMUL F30E 2A 42 2 .text

_IDIVS F338 1E 30 3 .text

_LDIVS_LC F356 6 6 1 .text

_SEXT16_32 F35C D 13 1 .text

- VARIABLES:

*********************************************************************************************

MODULE STATISTIC

Name Data Code Const

---------------------------------------------------------------------------------------------

MC68HC908JL3.C.o 39 0 0

Start08.c.o 0 149 0

MCUinit.c.o 0 51 34

main_v1_2.c.o 0 1102 0

RTSHC08.C.o (ansi.lib) 0 585 0

other 48 10 2

*********************************************************************************************

SECTION USE IN OBJECT-ALLOCATION SECTION

---------------------------------------------------------------------------------------------

SECTION: ".text"

MCU_init FrqGetUs delayus move main _PUSH_ARGS_L _ENTER_BINARY_L_LC _IDIVMOD

_SPLITSIGN _LDIVMOD _NEG_L_HX _ABS_L_HX _SPLITSIGN_L _LDIVS_k_is_k_div_j

_IMUL _IDIVS _LDIVS_LC _SEXT16_32

SECTION: ".init"

loadByte Init _Startup

SECTION: ".abs_section_0"

_PTA

SECTION: ".abs_section_1"

_PTB

SECTION: ".abs_section_3"

_PTD

SECTION: ".abs_section_4"

_DDRA

SECTION: ".abs_section_5"

_DDRB

SECTION: ".abs_section_7"

_DDRD

SECTION: ".abs_section_a"

_PDCR

SECTION: ".abs_section_d"

_PTAPUE

SECTION: ".abs_section_1a"

_KBSCR

SECTION: ".abs_section_1b"

_KBIER

SECTION: ".abs_section_1d"

_INTSCR

SECTION: ".abs_section_1e"

_CONFIG2

SECTION: ".abs_section_1f"

_CONFIG1

SECTION: ".abs_section_20"

_TSC

SECTION: ".abs_section_25"

_TSC0

SECTION: ".abs_section_28"

_TSC1

SECTION: ".abs_section_3c"

_ADSCR

SECTION: ".abs_section_3d"

_ADR

SECTION: ".abs_section_3e"

_ADICLK

SECTION: ".abs_section_fe00"

_BSR

SECTION: ".abs_section_fe01"

_RSR

SECTION: ".abs_section_fe03"

_BFCR

SECTION: ".abs_section_fe04"

_INT1

SECTION: ".abs_section_fe05"

_INT2

SECTION: ".abs_section_fe06"

_INT3

SECTION: ".abs_section_fe08"

_FLCR

SECTION: ".abs_section_fe09"

_FLBPR

SECTION: ".abs_section_fe0e"

_BRKSCR

SECTION: ".abs_section_ffff"

_COPCTL

SECTION: ".abs_section_21"

_TCNT

SECTION: ".abs_section_23"

_TMOD

SECTION: ".abs_section_26"

_TCH0

SECTION: ".abs_section_29"

_TCH1

SECTION: ".abs_section_fe0c"

_BRK

SECTION: ".abs_section_ffde"

_vect

*********************************************************************************************

OBJECT LIST SORTED BY ADDRESS

Name Addr hSize dSize Ref Section RLIB

---------------------------------------------------------------------------------------------

_PTA 0 1 1 42 .abs_section_0

_PTB 1 1 1 4 .abs_section_1

_PTD 3 1 1 12 .abs_section_3

_DDRA 4 1 1 2 .abs_section_4

_DDRB 5 1 1 2 .abs_section_5

_DDRD 7 1 1 2 .abs_section_7

_PDCR A 1 1 2 .abs_section_a

_PTAPUE D 1 1 3 .abs_section_d

_KBSCR 1A 1 1 0 .abs_section_1a

_KBIER 1B 1 1 0 .abs_section_1b

_INTSCR 1D 1 1 0 .abs_section_1d

_CONFIG2 1E 1 1 1 .abs_section_1e

_CONFIG1 1F 1 1 1 .abs_section_1f

_TSC 20 1 1 5 .abs_section_20

_TCNT 21 2 2 0 .abs_section_21

_TMOD 23 2 2 1 .abs_section_23

_TSC0 25 1 1 0 .abs_section_25

_TCH0 26 2 2 0 .abs_section_26

_TSC1 28 1 1 0 .abs_section_28

_TCH1 29 2 2 0 .abs_section_29

_ADSCR 3C 1 1 0 .abs_section_3c

_ADR 3D 1 1 0 .abs_section_3d

_ADICLK 3E 1 1 0 .abs_section_3e

loadByte EC00 17 23 5 .init

Init EC17 75 117 1 .init

_Startup EC8C 9 9 1 .init

MCU_init EC9F 33 51 1 .text

FrqGetUs ECD2 14 20 1 .text

delayus ECE6 22 34 1 .text

move ED08 16F 367 9 .text

main EE77 2A9 681 68 .text

_PUSH_ARGS_L F120 2D 45 1 .text

_ENTER_BINARY_L_LC F14D 23 35 1 .text

_IDIVMOD F170 69 105 1 .text

_SPLITSIGN F1D9 1C 28 1 .text

_LDIVMOD F1F5 CA 202 2 .text

_NEG_L_HX F2BF 13 19 2 .text

_ABS_L_HX F2D2 6 6 2 .text

_SPLITSIGN_L F2D8 A 10 1 .text

_LDIVS_k_is_k_div_j F2E2 2C 44 1 .text

_IMUL F30E 2A 42 2 .text

_IDIVS F338 1E 30 3 .text

_LDIVS_LC F356 6 6 1 .text

_SEXT16_32 F35C D 13 1 .text

_BSR FE00 1 1 0 .abs_section_fe00

_RSR FE01 1 1 0 .abs_section_fe01

_BFCR FE03 1 1 0 .abs_section_fe03

_INT1 FE04 1 1 0 .abs_section_fe04

_INT2 FE05 1 1 0 .abs_section_fe05

_INT3 FE06 1 1 0 .abs_section_fe06

_FLCR FE08 1 1 0 .abs_section_fe08

_FLBPR FE09 1 1 0 .abs_section_fe09

_BRK FE0C 2 2 0 .abs_section_fe0c

_BRKSCR FE0E 1 1 0 .abs_section_fe0e

_vect FFDE 22 34 0 .abs_section_ffde

_COPCTL FFFF 1 1 0 .abs_section_ffff

*********************************************************************************************

UNUSED-OBJECTS SECTION

---------------------------------------------------------------------------------------------

NOT USED PROCEDURES

RTSHC08.C.o (ansi.lib):

_PUSH_ARGS_D _ENTER_UNARY_L _ENTER_UNARY_L64 _ENTER_UNARY_L64_4

_ENTER_BINARY_L _ENTER_BINARY_L_RC _ENTER_BINARY_L64 _ENTER_BINARY_L64_LC

_ENTER_BINARY_L64_RC _LADD_k_is_k_plus_j _k_is_k_plus_j_l _k_is_k_plus_j_i

_LSUB_k_is_k_minus_j _LAND_k_is_k_and_j _LOR_k_is_k_or_j _LXOR_k_is_k_xor_j

_LMUL_k_is_k_mul_j _LMODU_k_is_k_mod_j _LDIVU_k_is_k_div_j

_LMODS_k_is_k_mod_j _LCMP_k_rel_j _BMULS _BDIVS _BMODS _IDIVU _IMODS _IMODU

_IDIVU_8 _IMODU_8 _IASR _ILSR _ILSL _ICMP _LINC _LDEC _LNEG _LNOT _LADD

_LADD_RC _LSUB _LSUB_LC _LSUB_RC _LAND _LAND_RC _LOR _LOR_RC _LXOR _LXOR_RC

_LMUL _LMUL_RC _LDIVS _LDIVS_RC _LDIVU _LDIVU_LC _LDIVU_RC _LMODS _LMODS_LC

_LMODS_RC _LMODU _LMODU_LC _LMODU_RC _LASR _LLSR _LLSL _LCMP _LCMP_RC _COPY

_COPY_L _POP32 _POP64 _STORE32 _STORE64 _SEXT8_32 _CALL _Jump_Table_Addr

_Jump_Table_Offset _Jump_Table_Header_Addr _Jump_Table_Header_Offset

_Search_Table_16_Addr _Search_Table_16_Offset _Search_Table_8_Addr

_Search_Table_8_Offset _PUSH_CC _POP_CC _CONV_FAR_TO_NEAR _CONV_FAR_TO_LINEAR

_CONV_LINEAR_TO_FAR F_CLRK F_CLRK_Unary F_NANK F_INFK F_INFK_Unary F_TLK

F_XGKL _UNPACK_k_to_K _UNPACK_k_to_K_Unary _UNPACK_j_to_L _PACK_K_to_k

_PACK_K_to_k_Unary F_NORMK _FADD_K_is_K_plus_L _FMUL_K_is_K_times_L

_FDIV_K_is_L_div_K _F_LONGK _F_FLOATK _FCMP_k_rel_j _FADD_Common _FSUB_Common

_FMUL_Common _FDIV_Common _FADD _FADD_RC _FSUB _FSUB_RC _FSUB_LC _FMUL

_FMUL_RC _FDIV _FDIV_RC _FDIV_LC _FSTRUNC _FUTRUNC _FNEG _FABS _FCMP _FCMP_RC

_FINC _FDEC _FSFLOAT _FUFLOAT D_TLK D_TLRes D_TKRes D_XGKL D_CLRK

D_CLRK_Unary D_NANK D_NANK_Unary D_INFK D_INFK_Unary _DUNPACK_k_to_K

_DUNPACK_k_to_K_Unary _DUNPACK_j_to_L _DPACK_K_to_k _DPACK_K_to_k_Unary

D_NORMK_Unary D_NORMK _DADD_K_is_K_plus_L _DMUL_K_is_K_times_L

_DDIV_K_is_L_div_K _DCMP_k_rel_j _D_FLOATK _D_LONGK _D_FTODK _D_DTOFK

_DADD_Common _DSUB_Common _DMUL_Common _DDIV_Common _DADD _DADD_RC _DSUB

_DSUB_RC _DSUB_LC _DMUL _DMUL_RC _DDIV _DDIV_LC _DDIV_RC _DCMP _DCMP_RC _DINC

_DDEC _DNEG _DABS _DSFLOAT _DUFLOAT _DSTRUNC _DUTRUNC _DSHORT _DLONG

NOT USED VARIABLES

RTSHC08.C.o (ansi.lib):

_PowOfTwo_8 _PowOfTwo_16 _PowOfTwo_32 plus1 minus1 plus1d minus1d errno

*********************************************************************************************

COPYDOWN SECTION

---------------------------------------------------------------------------------------------

------- ROM-ADDRESS: 0xF369 ---- SIZE 2 ---

Filling bytes inserted

0000

*********************************************************************************************

OBJECT-DEPENDENCIES SECTION

---------------------------------------------------------------------------------------------

Init USES _startupData loadByte

_Startup USES __SEG_END_SSTACK Init main

MCU_init USES _CONFIG1 _CONFIG2 _PTAPUE _DDRA _PTB _DDRB _PTD

_PDCR _DDRD

FrqGetUs USES _SEXT16_32 _LDIVS_LC

delayus USES _TSC _IMUL _TMOD

move USES _IDIVS _IMUL move _PTA _PTD

main USES MCU_init _PTB main _PTA _PTD move delayus

FrqGetUs

_ENTER_BINARY_L_LC USES _PUSH_ARGS_L

_SPLITSIGN USES _IDIVMOD

_LDIVMOD USES _LDIVMOD

_ABS_L_HX USES _NEG_L_HX

_SPLITSIGN_L USES _ABS_L_HX

_LDIVS_k_is_k_div_j USES _SPLITSIGN_L _LDIVMOD _NEG_L_HX

_IDIVS USES _SPLITSIGN

_LDIVS_LC USES _ENTER_BINARY_L_LC _LDIVS_k_is_k_div_j

_vect USES _Startup

*********************************************************************************************

DEPENDENCY TREE

*********************************************************************************************

main and _Startup Group

+- main

| |

| +- MCU_init

| |

| +- move

| | |

| | +- _IDIVS

| | | |

| | | +- _SPLITSIGN

| | | |

| | | +- _IDIVMOD

| | |

| | +- _IMUL

| |

| +- delayus

| | |

| | +- _IMUL (see above)

| |

| +- FrqGetUs

| |

| +- _SEXT16_32

| |

| +- _LDIVS_LC

| |

| +- _ENTER_BINARY_L_LC

| | |

| | +- _PUSH_ARGS_L

| |

| +- _LDIVS_k_is_k_div_j

| |

| +- _SPLITSIGN_L

| | |

| | +- _ABS_L_HX

| | |

| | +- _NEG_L_HX

| |

| +- _LDIVMOD

| |

| +- _NEG_L_HX (see above)

+- _Startup

+- Init

| |

| +- loadByte

+- main (see above)

_vect

+- _Startup (see above)

*********************************************************************************************

STATISTIC SECTION

---------------------------------------------------------------------------------------------

ExeFile:

--------

Number of blocks to be downloaded: 5

Total size of all blocks to be downloaded: 1933

Re: 68HC908 Convert frequency to cycle duration doesn't work

holgerkeil — Tue, 21 Oct 2014 20:01:30 GMT

And finally, the C source code, which is surely far from good:

#include <hidef.h> /* for EnableInterrupts macro */

#include "derivative.h" /* include peripheral declarations */

#include "pdeclaration.h" /* ports declarations */

void MCU_init(void); /* Device initialization function declaration */

int FrqGetUs(int frq){

int period;

period=1000000/frq;

return (period);

}

void delayus(int delay){

TSC_TRST=1;

TMOD=(delay*3);

TSC_TSTOP=0;

while (TSC_TOF == 0);

TSC_TSTOP=1;

TSC_TOF = 0;

}

Calculation of correction steps:

360 degrees equals 3350 steps

Correction steps = 3350 minus (rounded (3350 divided by pictures per turn) * pictures per turn)

Correction position = rounded(3350 divided by correction steps)

void move(int picinit, int motspeed){

int pause;

int pics;

int steps;

int xtrastep = 0;

int totalsteps = 0;

int stepinit = 0;

int stepmiss = 0;

int accdcc = 0;

stepinit = (3350 / picinit);

if (3350 / (3350 - (stepinit*picinit)) > 0) {

stepmiss = 3350 / (3350 - (stepinit*picinit));

}

for ( pics = 0; pics < picinit;) {

for ( steps = 0; steps < stepinit;) {

MOTclk = !MOTclk;

for( pause = 0; pause < motspeed; pause++);

steps++;

xtrastep++;

totalsteps++;

if (stepmiss !=0) { /* Exact 360 deg step correction routine */

if (xtrastep == stepmiss) {

MOTclk = !MOTclk;

for( pause = 0; pause < motspeed; pause++);

totalsteps++;

xtrastep = 0;

}

if (BTNstop == DOWN) { /* Stop button pressed? */

LEDstart = 0;

LEDstop = 1;

while (totalsteps < 3350) {

MOTclk = !MOTclk;

for( pause = 0; pause < motspeed; pause++);

totalsteps++;

}

LEDstop = 0;

pics = picinit;

steps = stepinit;

}

for( pause = 0; pause < 30000; pause++); /* Placeholder for Infrared xmtr routine for DSLR control */

pics ++;

}

void main(void){

int test;

int period;

MCU_init();

MOTrst = 1;

EnableInterrupts;

for (;;) { /* main loop*/

if (BTNstart == DOWN) {

if (MODEword == 14){ /* SWITCH POSTITON 1 - 10 pics */

MOTmode = HALF;

LEDstart = 1;

move(10,200);

LEDstart = 0;

}

if (MODEword == 13){ /* SWITCH POSTITON 2 - 20 pics */

MOTmode = HALF;

LEDstart = 1;

move(20,200);

LEDstart = 0;

}

if (MODEword == 12){ /* SWITCH POSTITON 3 - 25 pics */

MOTmode = HALF;

LEDstart = 1;

move(25,200);

LEDstart = 0;

}

if (MODEword == 11){ /* SWITCH POSTITON 4 - 30 pics */

MOTmode = HALF;

LEDstart = 1;

move(30,200);

LEDstart = 0;

}

if (MODEword == 10){ /* SWITCH POSTITON 5 - 35 pics */

MOTmode = HALF;

LEDstart = 1;

move(35,200);

LEDstart = 0;

}

if (MODEword == 9){ /* SWITCH POSTITON 6 - 40 pics */

MOTmode = HALF;

LEDstart = 1;

move(40,200);

LEDstart = 0;

}

if (MODEword == 8){ /* SWITCH POSTITON 7 - 45 pics */

MOTmode = HALF;

LEDstart = 1;

move(45,200);

LEDstart = 0;

}

if (MODEword == 7){ /* SWITCH POSTITON 8 - 50 pics */

MOTmode = HALF;

LEDstart = 1;

move(50,200);

LEDstart = 0;

}

if (MODEword == 6){ /* SWITCH POSTITON 9 - 60 pics */

MOTmode = HALF;

LEDstart = 1;

move(60,200);

LEDstart = 0;

}

if (MODEword == 15){ /* SWITCH POSTITON 10 - Testmode */

MOTmode = HALF;

LEDstart = 1;

period=FrqGetUs(440);

for (test=0; test<1000; test++){

delayus(period);

MOTclk = !MOTclk;

}

period=FrqGetUs(880);

for (test=0; test<1000; test++){

delayus(period);

MOTclk = !MOTclk;

}

LEDstart = 0;

}

Re: Re: 68HC908 Convert frequency to cycle duration doesn't work

tonyp — Tue, 21 Oct 2014 20:53:38 GMT

>First of all, I cannot reproduce the warning.

Does this also mean that your app is now functioning?

From a quick look, it seems this version (which is not the same as your original) does not use floats at all.

int FrqGetUs(int frq){

So, maybe this explains why you no longer see a problem. Try adding a single float operation, and see if the problem re-appears. (Then, you know the culprit.)

At any rate, if with the current version you no longer see a problem, is there a reason to investigate it further?

Or are you still having a problem with the exact one you posted?

Re: Re: 68HC908 Convert frequency to cycle duration doesn't work

holgerkeil — Tue, 21 Oct 2014 21:12:09 GMT

Sorry, no. We're again at that stage while debugger losts conection to target while debugging, but µc working in circuit. However, since it's not yet complete, it also fails in-circuit if I add two more for() loops. So the question was am I running out of memory and (where) can i figure out this (in project.map).

I don't use floats right now, but the respective library is still loaded. I dont want to try too many things at a time, finally not knowing what in detail had which effect. So it would be really helpful to know how much memory I use and to understand the changes if I use the integer library instead (If I would know that for instance, I have 1% Flash memory left with float and 2% with integer, I know that I need more than some cosmetic changes in order to fit the two remaining parts of code into the flash)