Direct Digital Synthesis. (DDS)

davidapex · Joined: 12 Mar 2006 Posts: 42 Location: Auckland

That's it - I'm going back to making model aeroplanes.
Found a major problem with the 3x4 keypad routine. After calling this routine the port pins are left partly as input and partly outputs, including my separate pin (portb.7) for the interrupt.

Thinking if I set all the port pins back to inputs after using the keypad I would be up and running ended in further confusion.

I suspect the ISR is being completed and returned to the frequency generating loop but it appears to be instantly interrupted again and going back to the keypad input routine.
Changing the ISRs "return" to a "goto" with a label just before the frequency loop at least allows the new frequency to be entered and generated but does not re-establish the interrupt.
Why doesn't my interrupt work the second time around?

Luciano · Joined: 29 Nov 2004 Posts: 3149 Location: Italy

David,

===============================================
If you are using an ATmeg168:

Set EIFR.0 ' clear Int0 flag of the ATmega168.

See my previous post where to put this line of code.
The code of my previous post is for a Tiny2313 where
the Int0 flag is bit 6. The Int0 flag of the ATmega168
is bit 0 of the EIFR register.

===============================================

When the interrupt occurs, the processor pushes the actual program
counter to the stack. RETI (return from the int routine) restores
the I-bit after the return address has been popped from the stack
and loaded to the program counter. (When you use RETURN in a Bascom
interrupt routine, Bascom will generate a RETI instruction).

This is not the only way to return from an interrupt routine.
If you use RETI you will avoid problems with the stack.

===============================================

These two lines must be before the assembly code:

Ross_ValuSoft · Posted: Sat May 13, 2006 2:07 pm Post subject:

David,

Talking of model aeroplanes <g>....about 10 years ago I was the project manager for the Aerosonde (google it for more).

Regards,

Ross McKenzie
ValuSoft
melbourne Australia

davidapex · Joined: 12 Mar 2006 Posts: 42 Location: Auckland

Hello Luciano,
Many thanks for your continued support.
I will try this later today and report back. I seem to have waisted so much time and had little change in result.
I was a bit confused by the Atmel datasheet that said "The flag is cleared when the interrupt routine is executed" but I realise now this is for a different type of interrupt. If it needs the flag cleared then I guess it will be a one-shot.

Ross - nice project. Very impressive performance!

Cheers,
David

davidapex · Joined: 12 Mar 2006 Posts: 42 Location: Auckland

Hmmmm.....
Just realised - I'm using Pin Change Interrupts which will generate interrupts whether going high or low. Was this another bad call on my part and should I change them to low only interrupts?

Cheers,
David

davidapex · Joined: 12 Mar 2006 Posts: 42 Location: Auckland

Hi All,
Attached is my last attempt to ***** this before trying something a little easier such as blinking LEDs.

The code starts up outputing a garbage waveform as I have removed the starting values for the phase accumulator.
I have PortB.7 configured as a pin change interrupt with a pullup resistor.
A momentary low on this pin then interrupts and sends the code to the 3x4 keypad input routine.
The number that is keyed in is written to the display along with the 3 register values for the phase accumulator.
Upon hitting the "#" key the values are loaded and the assembler loop outputs the new frequency. The table is not yet indexed to a boundary so it is distorted but this is a minor concern.
All is OK so far but that is where it stops. It won't interrupt the second time indicating I have screwed up in the interrupt setup before the RETURN.
Now the code is not exactly in the form I want it but until I can get the interrupt working (more than once) I haven't bothered optimising it.
Please note I'm using PCInt0 and not Int0. I don't mind a challenge but this is getting quite frustrating.
Any pointers or guesses from anyone (including weather bureau) would be gratefully received. The PCInt example in the samples makes it look so easy.

Cheers,
David

Luciano · Joined: 29 Nov 2004 Posts: 3149 Location: Italy

David,

There is no RETI in your ISR. This because your RETURN is inside
an IF. When the RETURN is inside an IF, Bascom will generate the assembly RET.
To fix the problem just replace your RETURN with the assembly RETI.

Best regards,

Luciano

From the Bascom Help file:

ON INTERRUPT

The first RETURN statement that is encountered that is outside a condition will generate a RETI instruction. You may have only one such RETURN statement in your interrupt routine because the compiler restores the registers and generates a RETI instruction when it encounters a RETURN statement in the ISR. All other RETURN statements are converted to a RET instruction.

davidapex · Joined: 12 Mar 2006 Posts: 42 Location: Auckland

Hello Luciano,
It may be time to give up on your worst student.

A quick change of code gives the following results:

An active low on the PCInt0 pin (portb.7) puts it in to keypad entry mode.
Upon entering "#" the RETI then returns somewhere but instantly ends up back at keypad entry with the PCInt pin as an active low (keypad mode?)
The interrupt pin briefly goes high (as it should) but almost immediately become low.
It's like another interrupt source occurs at the same time as the assembler routine runs.

Time to put it to one side I think.

Cheers,
David

davidapex · Joined: 12 Mar 2006 Posts: 42 Location: Auckland

New theory - I think the RETI instruction is being ignored and the code simply runs in to the Goto Keypad instruction a couple of lines further on. I don't think it is going to the assembler routine at all.
The previous posted code does load the phase increment registers and run the assembler routine to output the new frequency but doesn't allow a second interrupt.

Cheers,
David

Luciano · Joined: 29 Nov 2004 Posts: 3149 Location: Italy

David,

I have fixed your code.

The interrupt is now triggered when you press one of the
key of the keypad. (Any key). Remember to remove the
external pull-up resistor on PortB7 if you have one.

* * *

After you flash the AVR, make sure you disconnect the ISP
programmer because also the ISP programmer uses pins of portB.
(With the 470 ohm resistors there is no danger for the AVR and the ISP).

* * *

The 256 bytes boundary for the table is not correctly set.
This is just a sample for your interrupt problem. The
code was tested with an ATmega48 and the STK500.

* * *

If you are using the ATmega168 and the ATMEL board STK500
make sure you remove the jumper XTAL1 on the STK500.
Also the PB6 and PB7 of the ATmega168 are not connected
to the port header PORTB of the STK500. These two pins
are connected to the port header PORTE/AUX where
PB6=XT1 and PB7=XT2.

* * *

Connect the keypad like that:
(The same code works with a 3x4 or a 4x4 keypad).

PB0---470 ohm----keypad c1
PB1---470 ohm----keypad c2
PB2---470 ohm----keypad c3
PB3---470 ohm----keypad c4
PB4---470 ohm----keypad r1
PB5---470 ohm----keypad r2
PB6---470 ohm----keypad r3
PB7---470 ohm----keypad r4

If you are using a 3x4 keypad, the pin PB3 is not connected.
(PB3 is not floating because the pin is an output and set to 0).

(Click to enlarge the picture)

Best regards,

Luciano

davidapex · Joined: 12 Mar 2006 Posts: 42 Location: Auckland

Hello Luciano,
That's fantastic! Worked like a treat. E-beers all round.

I very much appreciate the time you have taken to develop the code and although I now have a great solution I still need to go through the code and learn from it.

The only change needed to get it going perfectly was the dummy data offset (expected) and I also tweaked the timing as the keypad behaved a little sleepy.

I will go through the code carefully to be sure I can follow everything but it does not look too bad.
Now, about those dovetail waveforms.........

Thanks again. If you're ever down this way I will make those real beers.

Cheers,
David

davidapex · Joined: 12 Mar 2006 Posts: 42 Location: Auckland

Hi All,
As a final footnote to this interesting thread I have observed a curious trend in the input number vs output frequency of this DDS.

With the 8MHz oscillator the 24 bit phase accumulator register and 9 cycle assembler loop you would need to multiply the number keyed in by 18.874368 or approx 151/8 to get number in =frequency in Hz out. This is easily done by adding a few more lines of code to Luciano's good work. Regardless of this ratio the output frequency should be linear to the input number.

This is what I have found (without the fudge factor of 151/8 applied)

Input number Freq Hz
1000 41.27
2000 96.20
4000 206.2
8000 426.0
16000 851.2
32000 1717
64000 3436
128000 6872
256000 13740
512000 27480

It appears to be quite linear from around 16000 upwards but not below 16000. The lowest entry of 1000 should return a frequency of approx 53Hz. I don't think it's my set up as I have measured other DDS units over a similar range with complete linearity.
Can anyone suggest why the smaller numbers are running so much slower than they should?

The frequency is determined by the following loop and the phase increment constant.

Main_loop:

add r28, r24 ' 1 cycle
adc r29, r25 ' 1 cycle
adc r30, r26 ' 1 cycle
lpm ' 3 cycles
Out Portd , R0 ' 1 cycle
rjmp Main_loop ' 2 cycles

Can any of these instructions change from 1 to 2 cycles depending on the numbers used?

I'm happy with the results I'm getting but would be interested in any academic input to this odd effect.

Best regards,
David

Luciano · Joined: 29 Nov 2004 Posts: 3149 Location: Italy

Hi,

(See original post on page 1 of this thread).

davidapex · Joined: 12 Mar 2006 Posts: 42 Location: Auckland

Hello Luciano,
I did just format a reply to your post but the button I hit sent it off to data heaven. Here we go again.

The table I have shown is r24/r25/r26 value againt frequency output

Fisrt entry is
1000 * 0.0529.... = 52.9Hz but I am only seeing 41.27Hz.

The first three entries show a progressive non-linearity with only the higher values being correct.
To be out by over 20% at the low frequencies would require a further two clock cycles in the assembler routine.
It seems to me that the assembler loop delay is somewhat value dependent but this just does not seem possible. Have I overlooked something?

Cheers,
David

Luciano · Joined: 29 Nov 2004 Posts: 3149 Location: Italy

David,

The problem was the position of the line of code "Enable Pcint0" at
the end of the interrupt routine. (Bascom uses R24 for it).

I have also added the two lines below but this is not mandatory.

ldi r29,$00
ldi r28,$00

I have edited the code in my previous post.
You will have to set the 256 bytes boundary for the table.

Best regards,

Luciano