Forum - MCS Electronics

 

FAQFAQ SearchSearch RegisterRegister Log inLog in

probleme sur bit1 du portD atmega823P
Goto page 1, 2  Next
 
Post new topic   Reply to topic    www.mcselec.com Forum Index -> BASCOM-AVR
View previous topic :: View next topic  
Author Message
Jeep56

Bascom Member



Joined: 19 Dec 2015
Posts: 4

france.gif
PostPosted: Fri May 28, 2021 11:22 pm    Post subject: probleme sur bit1 du portD atmega823P Reply with quote

bonjour,
je rencontre un phénomène bizarre avec un atmega328P:
voici le début de mon programme:

$regfile = "m328pdef.dat"
'$crystal = 8000000 'j'utilise l'horloge interne à 8Mhz
$baud = 19200
$hwstack = 40
$swstack = 16
$framesize = 32
Config Clockdiv = 1
'-------------------------------------------------------------------------------

Ddrc = &B00111111 ' port C sorties pour 6 servos
Ddrd = &B10000000 ' port D bits 0 à 6 en entrées bit7 en sortie pour led moniteur
Ddrb = &B10000000 ' port B bits 0 à 6 en entrées bit7 en sortie pour led élève
Portc = &H00 ' initialise les sorties servos à l'état bas, mettre une résistance 1k en série
Portd = &B01111111 ' pull-up sur 6 entrées
Portb = &B01111111 ' pull-up sur 6 entrées
....
' le reste du programme consiste à copier les bits 0-5 entrees des ports B ou D vers les sorties 0-5 du port C
'le choix depend de l'état du bit 6 du port D..

Lorsque je teste les entrées en appliquant un 0 sur chacune d'elle, il y a un problème sur la PinD.1:
cette entrée ne passe pas à 0, verification à l'oscilloscope ; 2.8v en la tirant à 0 et de 3.2v au repos.
Le circuit semble reagir à un court-circuit, comme si la PIND,1 etait en sortie forcée à 1.
Comment cette pin peut-elle repasser toute seule en sortie?
Sa deuxiéme fonction est TXD: comment PD1 pourrait-elle être affectée à cette fonction qui est une sortie?
Je n'utilise pas de port serie dans ce programme.
l'ensemble est monté sur un PCB, que j'ai verifié à plusieurs reprises sans rien détecter d'anormal sur le cuivre.
auparavant essayé sur une plaquette d'essai, je n'avais pas remarqué ce defaut sur PD1.
Si vous pouvez m'aider, je vous en remercie.
Jeep

(BASCOM-AVR version : 2.0.8.3 )
Back to top
View user's profile
Duval JP

Bascom Member



Joined: 22 Jun 2004
Posts: 997
Location: France

france.gif
PostPosted: Sat May 29, 2021 8:13 am    Post subject: Reply with quote

Bonjour Jeep56

Ce forum est international, donc SVP ecrit en anglais
This is an international forum, so please write in English
I use Deepl TRaduction to write in an not to bad English
JP
Wink

_________________
pleasure to learn, to teach, to create
Back to top
View user's profile Visit poster's website
Duval JP

Bascom Member



Joined: 22 Jun 2004
Posts: 997
Location: France

france.gif
PostPosted: Sat May 29, 2021 8:17 am    Post subject: Reply with quote

hi did you use a Arduino to test your program ?

try a very short program with only port D.1
then change to D.3
JP

_________________
pleasure to learn, to teach, to create
Back to top
View user's profile Visit poster's website
SZTRAD

Bascom Member



Joined: 30 Dec 2019
Posts: 123

blank.gif
PostPosted: Sat May 29, 2021 8:18 am    Post subject: Reply with quote

Hi
disconnect PD1 from external circuits and try again. If it behaves the same way it will be time to reach into the drawer for a new chip.
I'm also wondering do you by any chance have an arduino bootloader or something similar?
RS
Back to top
View user's profile
Jeep56

Bascom Member



Joined: 19 Dec 2015
Posts: 4

france.gif
PostPosted: Sat May 29, 2021 9:57 am    Post subject: Reply with quote

sorry,
my english is beginner level ...
let me use an online translator.
Back to top
View user's profile
Jeep56

Bascom Member



Joined: 19 Dec 2015
Posts: 4

france.gif
PostPosted: Sat May 29, 2021 10:11 am    Post subject: Reply with quote

I don't use arduino, i still have the old STK200, only for flashing .hex with AVRISP-U.
I plan to switch to Arduino, for more modernity
I made a prototype PCB of my project on a plate with copper bands. I use this on simple circuits like this one.

I think I found the cause, without finding the explanation:
the header of my program is modeled on another program in which I used a serial port on portD.
I realized that I had left the line $ baud = 19200
I deleted it and by magic, everything is back to normal!

Would this line be enough to switch PD1 to TXD output?

Thank you both for your quick response to my call for help.
Smile
jeep
Back to top
View user's profile
SZTRAD

Bascom Member



Joined: 30 Dec 2019
Posts: 123

blank.gif
PostPosted: Sat May 29, 2021 11:00 am    Post subject: Reply with quote

Hi
Yes, it sets PIND.1 to log.1 in the registry.
RS
Back to top
View user's profile
MWS

Bascom Member



Joined: 22 Aug 2009
Posts: 1939

blank.gif
PostPosted: Sat May 29, 2021 2:49 pm    Post subject: Reply with quote

SZTRAD wrote:
it sets PIND.1 to log.1 in the registry.

Sure?
Back to top
View user's profile
Jeep56

Bascom Member



Joined: 19 Dec 2015
Posts: 4

france.gif
PostPosted: Sat May 29, 2021 3:24 pm    Post subject: Reply with quote

thank You SZTRAD:
I confirm after a test of my program by the bascom simulator:
-with the code-line: $ baud = 19200 -> bits 3 (TXEN0) and 4 (RXEN0) of the UCR register (UCSR0B) are changed to 1, following the activation of the serial port
- without this code, they remain at 0.
verification by looking in the ATMEGA328P datasheet:

To remember... Idea
For me it is a solved problem, I will be able to finish my little module.
thank you all
jeep
Back to top
View user's profile
SZTRAD

Bascom Member



Joined: 30 Dec 2019
Posts: 123

blank.gif
PostPosted: Sat May 29, 2021 5:23 pm    Post subject: Reply with quote

Hello MWS
Looks like it.
The following instructions will be carried out
LDI R24,0x18
STS 0x00C1,R24
Or write the bits for RXEN0 and TXEN0. Since the other settings are done before that, the UART is activated.
And then it is valid that "The Receiver will override normal port operation for the RxDn pin when enabled."
So yes according to the simulator this is how it behaves and Mark logically sets the UART as requested by the BAUD command.

RS
Back to top
View user's profile
MWS

Bascom Member



Joined: 22 Aug 2009
Posts: 1939

blank.gif
PostPosted: Sat May 29, 2021 6:44 pm    Post subject: Reply with quote

SZTRAD wrote:
Looks like it.

Looks like what?
Like:
Quote:
Yes, it sets PIND.1 to log.1 in the registry.


My wording 'Sure?' should have hinted you to the fact, that PIND is the port's input register and writing to an input register makes no sense in this case. Actually, writing to the input register is a special toggle-functionality on newer AVR devices, not required here.

But you found out yourself:
Quote:
The following instructions will be carried out
LDI R24,0x18
STS 0x00C1,R24

This code sets UCSR0B at register address &hC1, but it does not set PIND.1, PIND is address &h29 btw.
Quote:
Or write the bits for RXEN0 and TXEN0. Since the other settings are done before that, the UART is activated.
And then it is valid that "The Receiver will override normal port operation for the RxDn pin when enabled."
So yes according to the simulator this is how it behaves and Mark logically sets the UART as requested by the BAUD command.

What you write here was perfectly clear to me, while you and the TO had to find out first.

Enabling the UART as soon serial functionality is requested, is afair basic Bascom behavior, which goes as far, that one 'print' in otherwise 'non-serial' code already has the effect of enabling the USART.

And this changes functionality of the pins connected to the USART.
Setting or changing PIND does not play any role here.

This was the expanded version of my hint 'Sure?', took for sure more chars, where I've initially thought five would be enough.
Back to top
View user's profile
SZTRAD

Bascom Member



Joined: 30 Dec 2019
Posts: 123

blank.gif
PostPosted: Sun May 30, 2021 12:04 pm    Post subject: Reply with quote

Ok
I thought you were serious. I misunderstood "sure?" as your sarcastic remark.
I apologize for the misunderstanding.
The questioner asked, I answered. Nothing more nothing less. Just because you know it doesn't mean everyone knows it. I, for one, didn't know that the Baud directive already made the setup, including HW. That's because I don't use settings I don't need in the program. According to the 1 in the PIND register, you can test if the open UART was left on after the bootloader. I know this because I used it on a device with a bootloader that had this feature.

Quote:
Enabling the UART as soon serial functionality is requested, is afair basic Bascom behavior, which goes as far, that one 'print' in otherwise 'non-serial' code already has the effect of enabling the USART.

And the interviewer didn't use the print command. Or do you see it in there somewhere?

RS

LONGUM ITER EST PER PRAECEPTA, BREVE EST EFFICAX PER EXAMPLA
Back to top
View user's profile
MWS

Bascom Member



Joined: 22 Aug 2009
Posts: 1939

blank.gif
PostPosted: Sun May 30, 2021 2:45 pm    Post subject: Reply with quote

SZTRAD wrote:
LONGUM ITER EST PER PRAECEPTA, BREVE EST EFFICAX PER EXAMPLA

Then you should recognize an example, if one is presented to you.
Quote:
Quote:
Enabling the UART as soon serial functionality is requested, is afair basic Bascom behavior, which goes as far, that one 'print' in otherwise 'non-serial' code already has the effect of enabling the USART.

And the interviewer didn't use the print command. Or do you see it in there somewhere?

No, there (obviously) was no 'print' in the TO's code, as it served for me as example that even an innocent appearing command like 'print' has the power of enabling the USART, with corresponding effect to the portpins, you and the TO were not the first ones falling for this trap.
But again, the generic character of this 'print' came clear from the way I've wrote it.
I suggest you opt for a different translator, as most discussion energy with you doesn't go into the tech-details, but instead to have your understanding. If the translator works well however, I would change the understander Very Happy
Being aware of this, I even thought twice about answering after all, but your primary statment was that wrong in its context, correction was required.
Back to top
View user's profile
albertsm

Administrator



Joined: 09 Apr 2004
Posts: 5253
Location: Holland

blank.gif
PostPosted: Sun May 30, 2021 8:23 pm    Post subject: Reply with quote

[quote="Jeep56"
I think I found the cause, without finding the explanation:
the header of my program is modeled on another program in which I used a serial port on portD.
I realized that I had left the line $ baud = 19200
I deleted it and by magic, everything is back to normal!

Would this line be enough to switch PD1 to TXD output?


jeep[/quote]

yes, this is by design. using this syntax is old but can still be used. i would suggest to use CONFIG COMx however. It can set all the properties of the USART including the baud rate.
there is no magic. the first micros had a simple UART. there was not much to configure so there was not even a CONFIG COM statement.
All that could be set was the baud rate. So the $BAUD was used for that. And when a later micro had 2 usarts, $BAUD1 was added.

In order to use the usart, the TX must be set to output. so this is done automatically.
And any PRINT or other serial command will have the same effect : it will configure the usart including the TX pin.

The PIND register is never altered. the DDR register is used to set the data direction.

_________________
Mark
Back to top
View user's profile Visit poster's website
SZTRAD

Bascom Member



Joined: 30 Dec 2019
Posts: 123

blank.gif
PostPosted: Mon May 31, 2021 6:29 am    Post subject: Reply with quote

Hi
You don't change it, Mark, it's a HW thing.It comes from the log AND register of the UART
I will try to find the schematic that was sent to me by Atmel once,there you can see why PIND is set.
RS
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    www.mcselec.com Forum Index -> BASCOM-AVR All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum