Easy question!

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hey, first post here!

 

Trying to use 328p to take digital input from three pins and reproduce on three other. The trio of input pins are on the same register and the trio of output pins are on another so that makes things quite easy. Without going into the details, let say it's a multilevel learning experience...

 

#define F_CPU 16000000UL
#include <avr/io.h>


int main(void)
{
	DDRD = DDRD | 0B00011100;//sets pins PD2, PD3, PD4 as output
    while (1) 
    {
		PORTD = (PINB & 56) >> 1;
    }
}

So all is fine and works "ok"... BUT... Every couple cycles I get 500ns longer pulse.

 

The input wave looks just fine so it's not a trigger problem on the scope. I can probably take picture of the scope if that can help.

 

I'm running out of keywords to put in google but ISR seems pretty good. Issue with this is that I thought my one line code did not call for interrupt...

 

Any keywords accepted! Feel free to state the obvious

This topic has a solution.
Last Edited: Tue. Jun 25, 2019 - 11:01 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the clock rate of the AVR? You could be observing the nature of your asynchronous signals - it depends exactly where they change in relation to the code and the clock.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Agreed, you're just seeing the fact that the input signals are not synchronized with your AVR clock.  500 ns is 8 cycles of 16 MHz clock, which sounds just about right to run through your loop one time.

 

BTW, magic numbers are evil, and even more so with decimal bit masks like '56'.  I have truly never seen that before in 40+ years.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

it's running on a 16MHz resonnator. 

 

If I get this right, there should be input signal frequency that won't produce this effect?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah, learned about bitmask two days ago thought it looked cool to use the decimal number... Wish it was 42 though...

 

So I just suck it up and get a baud rate where 500ns is within error margin?

 

What would be the intelligent way to proceed? I sense the internet really has not had the need to use that chip as a wire...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Back up and tell us why you're doing what you're doing.  Maybe there's another approach that will work better.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What does baud rate have to do with input scanning?

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll have to go back to my notes. It's an old problem I had using ccloader to upgrade a firmware. I was limited at 19200 baud probably because of my poor choice of crystal... I thought I'd bypass all that with some avr black magic... Thing is, I'd like to be able to upgrade some 300 pcb so I'd rather have a speedier option...

I'll try to put my thoughts together

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kk6gm wrote:
Back up and tell us why you're doing what you're doing.

 

+1

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are talking about ISR, but there is non in the code you provided...

Also you are talking about baudrate, even though there is nothing done with a uart or any of the associated registers.......

 

int main(void)
{
	DDRD = DDRD | 0b00011100; //sets pins PD2, PD3, PD4 as output
  9e:	81 b3       	in	r24, 0x11	; /1/ 17
  a0:	8c 61       	ori	r24, 0x1C	; /1/ 28
  a2:	81 bb       	out	0x11, r24	; /1/ 17
	while (1)
	{
		PORTD = (PINB & 56) >> 1;
  a4:	86 b3       	in	r24, 0x16	; /1/ 22
  a6:	88 73       	andi	r24, 0x38	; /1/ 56
  a8:	90 e0       	ldi	r25, 0x00	; /1/ 0
  aa:	95 95       	asr	r25 ; /1/
  ac:	87 95       	ror	r24 ; /1/
  ae:	82 bb       	out	0x12, r24	; /1/ 18
  b0:	f9 cf       	rjmp	.-14     	; /2/ 0xa4 <main+0x6>

000000b2 <_exit>:
  b2:	f8 94       	cli

000000b4 <__stop_program>:
  b4:	ff cf       	rjmp	.-2      	; 0xb4 <__stop_program>

your code gave this listing I added the needed AVR Clock cycles between /n/ and that turns out to be 8.

Now if your level change is happening just after the actual sample is taken it will take another 8 AVR clock cycles before it is sampled again. That will explain the some times 500ns delay .

 

Keep in mind that each and every interrupt you will be introducing will cause this to massively delay as it will have entry code (pushing stuff) actual things to do and exit code (popping stuff) .

 

after re reading your post a number of times now it suggests that you are going to be doing a software uart.......

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Asking the question may have been easy......

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kk6gm wrote:
and even more so with decimal bit masks like '56'.
For the benefit of others (I had to work it out!) 56 is 0x38 so we're talking 00111000 so it's extracting bit 3 to 6. Then the >>1 moves them to 5..2.

 

I guess I should have known this from:

DDRD = DDRD | 0B00011100;

which rather raises the question as to why 56 when 0b format is known and used elsewhere ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

Asking the question may have been easy......

Yeah, I think the question was quite easy indeed and I did get the answer in the first couple replies. Lol