Desperately need help with serial communication

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

Hi everyone. First I'd like to introduce myself. I'm a 4th year computer/electrical engineer, doing my thesis project using at Atmel microcontroller.

Ok, now onto the problem.

I'm using the Atmel AT90S2313 microcontroller, and I'm attempting to create a serial connection between it and my PC. I have it hooked up (properly) to a MAX233A chip, which is what provides the bridge between the Atmel and the serial port.

I'm using the STK500 project board for the time being, with PD0 as the receive pin and PD1 as the transmit pin. Everything is hooked up and working as it should, except for the actual serial communication.

I've written a simple program, whose sole purpose is to wait for a character to be received, then echo the same character directly back to the user. Unfortunately, this doesn't work. One of two things happens:

1) The Atmel just transmits garbage continuously, or
2) The Atmel echoes back a COMPLETELY DIFFERENT character than what was sent

I've tried using Hyperterminal, as well as making a Visual Basic project to communicate serially, and neither work.

Here is my program listing:

.nolist
.include "2313def.inc"
.list

.def temp	= r16			; Temporary register

; Set Port B (LEDs) to be output and turn them off
ser	temp
out	DDRB,temp
out	PORTB,temp

; Set up the baud rate to 9600 (based on a 3.69 MHz clock)
ldi	temp,23
out	UBRR,temp

; Enable UART transmit and receive
sbi	UCR,RXEN
sbi	UCR,TXEN

; ===== MAIN PROGRAM STARTS HERE =====
loop:
sbis	USR,RXC		; Wait for character
rjmp	loop

ldi	temp,UDR	; Load received char into temp

wait:
sbis	USR,UDRE	; Wait for transmit buffer
rjmp	wait		; to be free

out	UDR,temp	; Send that char out

rjmp	loop

I'm open to any suggestions anyone has. Thanks.

Last Edited: Mon. Aug 12, 2019 - 09:50 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, well I've improved the results a bit by using

in temp,UDR

As opposed to

ldi temp,UDR

Which was obviously very wrong, after reading Design Note #4. However, I'm still only getting about a 50% success rate, which is absolutely unacceptable.

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

Lord help us. After for years of studying computers and electrical erngineering you are just getting around to initializing a uart? Planning on getting a master degree? What will the thesis be for that?

Imagecraft compiler user

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

Hi,

I would start with just making a loop that echoes one character back - this way you can figure out which end the problem is on.

Regards,

-Colin

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

bobgardner:
First of all, I dont' appreciate your sarcasm. Electrical engineering has NOTHING TO DO with UARTs or computer components like that.

So unless you have something constructive or helpful to say, dont' say anything at all. :x

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

Bob that was just mean.

Volt9000. Welcome to the freaks net! I graduated a few years ago as an EE and I realize how much other stuff you have to deal with than silly UARTS. The people on here are usually pretty nice and very knowledgeable.

I simulated your code and found nothing wrong. I would try to use the on-board serial port on the STK500 before trying your own hardware. I'm sure you have it hooked up properly but you never know and it's always easier to debug one problem at a time. All you have to do is hook the PD0 and PD1 pins to the proper header as it is written in the manual.

Have you tried simply having your code spit out characters without trying to receive characters as well? Divide and conquer.

If that doesn't help, search the code posted here as there is about 50 metric tons of UART assembly code.

Hope this helps

Go electric!
Happy electric car owner / builder

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

Volt9000 wrote:

Electrical engineering has NOTHING TO DO with UARTs or computer components like that.

Have you ever written a program in any language for any computer during your four years in computer/electrical engineering? Just wondering if a graduate with a computer degree can write some programs..... I wont ask what school it is. If a prospective employer ask if you had some programming experience, would you tell him yes with a clear conscience?

Imagecraft compiler user

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

I've been having the same problem with my mega8. It can send data to the terminal but it receives nothing or garbage. The same program written for two mega8's talking to each other works fine. So I am wondering, maybe we both have problems with our serial terminals on our computers or is it possible that max232 has been blown in one direction but not the other :?: Regards, Johnny Banjo.

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

Nihilo wrote:

So I am wondering, maybe we both have problems with our serial terminals on our computers or is it possible that max232 has been blown in one direction but not the other?

Certainly. So you grab your 'scope, like with any other connectivity problem, put one side into a repetitive transmit, and follow the signal to the other side.

We can speculate about AVR code here all day; all suggestions won't help if a wire is broken.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I must say I am a bit surprised too but I think Bob has been a bit too harsh. But we all have to start somewhere and I did too. It made me think of my knowledge after graduating (with a Physics degree) and what I knew...next to nothing. But I persevered and you must too. I am sure your University will give you good a good grounding. The thing is when you are in uni, you feel like you are special. In some people this does come out as arrogance and that's why other people, some just as smart and without a degree is out there to bring you back to ground.

Writing in assembler is an art form. Unfortunately most universities do not give much attention to it; 1 or 2 semesters. This is nowhere enough and you have to develop the skills yourself if you are interested in it like some of us diehards are.

For asynchronous rs-232 type connection baud rate is not the only thing. There is also the frame format like 8N1 8 bit no parity; the most common theses days. This has to be pre-arranged/agreed between senders and receivers. Using hyperterminal is the quickest way to test your code..you needn't write a programme to do it (In BASIC????...please do not advertise that. BASIC is not a basic language..it is a misnomer. Do you know what the acronym stands for..that itself is based on pretty archaic terminologies). With a 50% strike rate, and unless you have editted out most of your code, I think your problem could be because of parity. Perhaps Hyperterminal was set for even parity and you have yours set as no parity ego...50% strike rate.

When you get this to work you should work on trying to do this project under interrupt. And if that works you should consider writing a very simple kernel. Now this is hard..but look around...ask around and experiment. A good project written in assembly is interrupt driven; ie no waiting loops; and under the governance of a kernel. The kernel can be very simple to very complex and these days you can even buy them.

And a good assembler programmer will have to learn other assembly languages too. This will come with time quite naturally as in an open market you will eventually find another processor with better features or is more economical. Over my 20+ years of programming I have learnt and forgotten Signetics 2650, Motorola 6800, 68xxx, Intel 8080, 80x86, Z80xxx, NEC upD series (forgotten the numbers), ST6, ST7 and of course the AVRs. Although the mnemonics are quite different the structure of the programmes and the style remains the same....remember interrupt driven and kernel driven... and a good assembly programmer will know how to use the stack in various ways for various things...that I think is basically it....and, like in the 2nd law of Thermodynamics, comes quite naturally with time.

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

Thank you to all those who replied with helpful advice.

Quote:
I simulated your code and found nothing wrong. I would try to use the on-board serial port on the STK500 before trying your own hardware. I'm sure you have it hooked up properly but you never know and it's always easier to debug one problem at a time. All you have to do is hook the PD0 and PD1 pins to the proper header as it is written in the manual.

Ahhh yes... using the onboard RS232 DOES work... so it seems there's a problem with the way I hooked up my MAX233.

But that's the weird thing... I've checked and rechecked the schematic (which I got from someone else's thesis, who did theirs a few years ago and they claimed it worked) many times, and got several other people to check it over as well. It's hooked up properly. Which leads me to believe the schematic is WRONG.

Anyways, I tried hooking it up a different way, and it APPEARS to work, except here's the weird thing...

If I make the prohram echo back only one character, i.e. not the one that was read in but just some arbitrary character, it STILL echoes back the same one. Even if I disable transmission, via

cbi UCR,TXEN

The damn thing STILL transmits the character back.

I'm using Bray's Terminal now, which has separate windows for sent and received chars. But I'm very confused as to why I'm getting back characters if UART transmission is disabled...

Quote:
Have you ever written a program in any language for any computer during your four years in computer/electrical engineering?

Of course. I've programmed in a wide variety of languages.... C (which includes pure C as well as several pseudo-C languages), Java, Prolog, VHDL, assembler...

Quote:
And a good assembler programmer will have to learn other assembly languages too.

Well at the moment I know 3 varieties of assembler (well, 2 and a half really... ;))
I know Motorola assembly, for the HC11, Atmel assembly, and I know a bit of assembler for the Intel x86 architecture.

Anywass back to my original problem... any idea why the damn thing is still transmitting even after disabling the transmitter?

[edit]
Ok, even if I disconnect the pins connecting the Atmel to the MAX, the damn terminal program STILL claims to receive back the same characters I sent. WTF is going on?

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

Ok, well it appears my MAX is STILL connected improperly. And now I'm stuck.

I've tried two different ways of connecting it, one which is straight from Atmel's Appnotes, but with no luck. Because the onboard serial port seems to work just fine.

Here is how I currently have the MAX hooked up:

PIN 2 - TX line of Atmel (PD1)
PIN 3 - RX line of Atmel (PD0)
PIN 4 - RX line to RS232 adapter
PIN 5 - TX line to RS232 adapter
PIN 6,9 - Connected together, to ground
PIN 7 - VCC, +5 volts
PIN 10,16 - Connected together
PIN 11,15 - Connected together
PIN 12,17 - Connected together

The rest of the pins are not connected.
This is straight from Atmel's application notes, so I know of no other way to connect this. Maybe I need something connected to the other pins, like CD, RTS, etc?

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

Volt9000 wrote:

Ok, even if I disconnect the pins connecting the Atmel to the MAX, the damn terminal program STILL claims to receive back the same characters I sent. WTF is going on?

Not familar with the terminal program you're using but it sounds like you have local echo enabled. If you unplug the serial cable, do you still see the charactes being echoed??

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

dksmall wrote:
Volt9000 wrote:

Ok, even if I disconnect the pins connecting the Atmel to the MAX, the damn terminal program STILL claims to receive back the same characters I sent. WTF is going on?

Not familar with the terminal program you're using but it sounds like you have local echo enabled. If you unplug the serial cable, do you still see the charactes being echoed??

It's definitely not local echo, because there are separate windows for sent data and received data. The sent data is obviously showing what I typed, but the received data window shows the exact same thing.

Obviouslu, my MAX is hooked up incorrectly, but I don't know how else to connect it. I'm currently reading through the (lengthy!) datasheet for the MAX family of ICs, hopefully it will offer some insight.

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

Hi,

So if you disconnect the cable the echo stops? Could be a faulty cable... always suspect the cable! I have had several hours (or more) wasted troubleshooting projects because those damn super-cheap computer cables were broken!!!

The MAX datasheet has some example circuits in it as well. Also the other person's thesis schematic could be wrong, he probably made the actual board from something else then drew up a schematic afterwards (thats what I end up doing a lot....) and could have introduced errors.

Regards,

-Colin

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

No, the echo doesn't stop if I disconnect the cable. It still echoes.

But like I said: the problem lies within my MAX233 connection; the cables all work fine.

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

Glad to hear you are making progress! Although I'm sure it doesn't feel that way! :lol:

can you clarify the pinout you posted? What are the from-to connections and what do those pin numbers refer to?

i.e.:
from PD0 to ....
from PD1 to ..
etc..

I ask because it sounds quite likely you have the port hooked up in a loop back fashion. Usefull for debuging but not quite right for what you want to do!

Go electric!
Happy electric car owner / builder

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

Hi,

If it still echoes with the cable disconnected there is a local echo enabled for sure.

Check the cable, short pins 2 and 3 together and you should get double-echo back (one local and one from the cable).

Otherwise how are you sure the cable works? So far you only say you've got the echo back, but since you get that anyway...

Then when that works ignore the AVR for now. Just connect the TX output of the MAX232 to the RX input of the MAX232. Again you should get a double-echo back.

Finally you can work on the AVR. First you should just make a program that manually reads the value of the RX pin and outputs it on the TX pin in a loop. If that works, your AVR is at least running.

-Colin

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

Ok here's my pin configuration again. On the left are the connections to the MAX233, and on the right are the connections going out of the MAX (either to the Atmel or to the serial port.)

PIN 2 - TX line of Atmel (PD1)
PIN 3 - RX line of Atmel (PD0)
PIN 4 - RX line to RS232 adapter
PIN 5 - TX line to RS232 adapter
PIN 6,9 - Connected together, to ground
PIN 7 - VCC, +5 volts
PIN 10,16 - Connected together
PIN 11,15 - Connected together
PIN 12,17 - Connected together

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

Ok, connections sound fine but I agree with Colin...try just getting one piece at a time to work.... loopback with just the cable..

Also, forget this whole two way communication...just send characters continuously from the AVR and get that to work.

Go electric!
Happy electric car owner / builder

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

Ok, the cable definitely works... if I use the Spare RS232 port on the development board, my program works fine. I tried loading up different programs that use serial communication, and they all work. So the cable is fine.

Therefore the problem must lie within my hookup.

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

What package MAX233 are you using? The pin assignments
are slightly different for the DIP and the SO.
Also, are you sure you are connecting the terminal's TX line
to the AVR's RX etc?

Is your terminal's hardware and software flow control turned off?

Have you traced the signal paths with a scope and verified
a solid ground, and the continuity, level, polarity, and pulse
widths of the signals at each point in the system?

Is the clock speed of the avr really what you expect it to be?

Are the avr's vcc and gnd terminals properly bypassed close
to the chip?

Do you have a bulk vcc filter cap in place as well?

Is the avr's reset line properly terminated and held stable?

The program (as corrected) works. Some methodical
troubleshooting should reveal the problem.

Tom Pappano,
Tulsa, Oklahoma

Tom Pappano
Tulsa, Oklahoma

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

Regarding your pin out diagram; Jan Axelson who is an authority on this matter has pin 2 tied to pin 20 and pin 19 then goes to Atmel Tx pin. Similarily pin 3 is tied to pin 1 and pin 18 goes to Rx line of 2313. This , of course is the pin out for the Max 233 chip. I use Max 232 chip with all the caps, and yes Lee I checked everything with the scope, lines, changed the chip itself , fluashed buffer in the program and nothing. My mega8 sends data all right but it can't receive it. As Sherlock Holmes used to say "if you eliminate all of the most probable reasons, the one that is least probale is the culprit" or something like that, however locating the least probable sucker is another matter, isn't it? :lol:

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

Actually, the saying is

"If you eliminate the impossble, whatever remains, however improbable, must be the truth."

:)

And I'm still troubleshooting this sucker, bit by bit, eliminating all the impossible problems, but still getting nowhere. :(

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

Ok, to recap:

1) Connect the PC to the spare RS232 port on the STK500 and the AVR to the spare RS232 port and everything works fine - no echo.

2) Connect the PC to your RS232 connector and the AVR to your MAX233 and you get some type of echo...

3) Disconnect the PC from everything and you still get some type of echo..

Is this right?

Go electric!
Happy electric car owner / builder

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

Ok, the following is assuming I have the Atmel running, just echoing the same character over and over again (with a slight delay of course.)

Quote:
1) Connect the PC to the spare RS232 port on the STK500 and the AVR to the spare RS232 port and everything works fine - no echo.

Correct. Connecting direcltly to the spare RS232 works perfectly, I'm getting the correct character from the Atmel every time.

Quote:
2) Connect the PC to your RS232 connector and the AVR to your MAX233 and you get some type of echo...

Well that's the thing... depending on how I hook it up, I either get nothing back (which I assume would mean I've switched te TX and RX lines) or I get back garbage, but ONLY if I start shifting the wire around or touching the header pins on the board (I assume here the garbage is due to noise.)

Quote:
3) Disconnect the PC from everything and you still get some type of echo..

Well, yes and no. I think I only got an echo back because of the shitty terminal programs I was using. Now I've found a very nice one, Look RS232, which tells me exactly what I send and whatI get back. So disconnecting everything does exactly what it's supposed to do - I get nothing echoed back.

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

AAAAHHHHHHHH NOW WE ARE GETTING SOMEWHERE!!! WOOOOO HOOO!

Quote:
I get back garbage, but ONLY if I start shifting the wire around or touching the header pins on the board (I assume here the garbage is due to noise

Time to break out the O'scope.... and when you do make sure to probe up on the pin of the chip itself. Don't probe down where the pin touches the socket or the PCB or whatever. Probe up on the chip.

Things to look for:

0) This is from page one of the technicians training manual I wrote for our company.... Check the supply votages.

1) nice TTL levels on the outputs of the AVR and on the inputs of the MAX
2) nice RS232ish levels on the other side of the MAX -- +/- 5V minimum
3) nice edges on all the above. They should be nice and snappy not slowly drooping or rising and minimal ringing. Certainly no ringing above more than a few millivolts.
4) Did you really do step 0)?

Remember just because you see the signal leaving the AVR doesn't mean it's getting to the MAX.

Go electric!
Happy electric car owner / builder

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

Crap... gotta wait until I get to school to do all that, unfortunately I don't have an oscilliscope at home. :?

Well thanks for your suggestions, I'll definitely check it out tomorrow...

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

HOLY SHIT.... IT WORKS...

I whipped out my multimeter and checked the power going to the MAX... apparently, the power supply I'm using (I constructed my own, which so far has worked perfectly well for the rest of the circuit) wasn't supplying enough voltage to the MAX.

So I instead tried running the MAX off the ground and power pins on the STK board, and holy crap, it WORKS!

Thank you everyone who helped me out, especially sgomes, who so brilliantlly suggested I check the power, which I never even thought of. :D :D :D

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

:lol:

My bet is that you'll have one within the year. I found mine in a trash can at school. Ok, it's a really old 100Mhz jobby that had two broken inputs but it was free! :wink:

The old finger on the circuit trick is one of the best diagnostic tricks you can use. Good job. Many of the old timers at work use it to test stuff all the way up into the GHz!

Keep us posted. Good problem!

Go electric!
Happy electric car owner / builder

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

Hello Volt9000,

Nice to see you got it communicating :lol: I had an thought as to what your problem could have been.

This home built power supply that you mentioned. Was it used to supply power to both the STK500 and the RS232 chip OR did you have two separate supplies. (I.E. A wall mount supply for the STK500 and your home built PS for the RS232 circuit.)

My thought is based on the case that you had two different supplies. :idea:

GND PS1(STK500)<----------->GND PS2(Home Built Power Supply)

Now this may have not been the problem, but not having them common would cause all sorts of problems....

If you only used one supply then ignore all thoughts from me :wink:

Jason.

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

Congratulations!!!! WOOOOHOOOO! :D

Yeah, sometimes it's the simple stuff. You would be amazed how many times I go over to manufacturing to help out a technician who is absolutely banging his head on a problem-- only to find out one of the power rails is dead. Two seconds with a DVM and the problem is solved.

Bet you'll check there first from now on! :lol:

Again, Congratulations!

Go electric!
Happy electric car owner / builder

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

Well, that's nice that it works. Mine still works only one way. Incidentally, what "nice' terminal program have you been using Volt900 :?: Ragards Johnny Banjo.

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

Hi! I've checked your connection list and, if I'm not misunderstanding, you've connected pins 4 and 5 to Pins 2 and 3 (Assuming DB9 connector), respectively, of the PC serial port (i.e. RD and TD in the PC).

You should connect them in the "reverse way", i.e.
AVR | PC (DB9 Connector)
--------------------------------------------------------
Pin 4 | Pin 3 (Transmision Line, Assuming DB9)
Pin 5 | Pin 2 (Reception Line, Assuming DB9)

Also, I've found to be very useful to connect a 2 input scope to verify the correct signal flow while testing the program.

Attachment(s): 

Last Edited: Thu. May 19, 2005 - 05:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nevermind.

Last Edited: Thu. Apr 8, 2004 - 12:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Leon and Bugman. Yeah I've got my connections exactly as in your diagram Leon except pin 5 on DB9 connector is my ground :?: And my caps are in the right order and polarity. I checked the lines = OK, Exchanged the Max232 for another =the same problem. I am going to check the +10 and -10 voltages on the scope now. What mystifies me is that AVR sends the data to the teminal (Bray's++ Terminal) very well however nothing or garbage goes the other way. :cry:

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

Quote:
his home built power supply that you mentioned. Was it used to supply power to both the STK500 and the RS232 chip OR did you have two separate supplies.

No, the power supply was just made to power the MAX, not the STK board; that gets its power from a good ol' Radio Shack DC adapter. :)

When I got into the lab and hooked the power supply up to an oscilliscope, the regular was supplying a perfect +5V, with no load. As soon as I attached the MAX, not only did the output voltage drop, but also there was MASSIVE amounts of ringing! The regular output was very unstable.

I consulted with my professor, who informed me that 3-terminal regulators are actually a feedback system, and they can become unstable like that. So he suggested put a few caps on the terminals of the regulator.

Quote:
Incidentally, what "nice' terminal program have you been using Volt9000

It's a program called Look RS232.

http://www.lookrs232.com/

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

BugMan wrote:
Does your MAX233 setup have external caps? Are your caps in the right polarity? I've had success with many, many MAX233 chips and might be better to help if I had a diagram of your circuit.

MAX233 is the expensive version with internal caps. You mean MAX232 with external caps?

Imagecraft compiler user

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

Yes, you're right. I must have fatfingered that one.

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

Just because there is a separate window for transmit & receive in your terminal application, don't assume that local echo is turned off.

Your connections to the MAX233 seems correct, make sure you have no connection on pins 8,13,14. Note some pins are different between the DIP and SO package

Also are you configuring your cable as a null modem. RX->TX, TX->RX.

Make sure your terminal app does not require a hardware flow control, if it does connect RTS->CTS at the CPU end of the cable

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

Hi,how are you I have this code use at90s2313 in simulation the code work and on circuit not work crystal,reset button also not work out can you guide me to set this at90s2313 or make configuration

thank you

void main() {
ddrd=0x00;
    portd=0x0e;

    Portb=0;
    ddrb=0xff;
    while (1)
    {
        if (pind.b0==1 && pind.b1==1&& pind.b2==0&&pind.b3==0&& pind.B4==0)
            Portb=0b00001011;
            else
        Portb=0;
        if(pind.b0==1  && pind.b1==0&& pind.b2==0&&pind.b3==0&&pind.b4==0)
            portb=0b00000011;
            else
            portb=0;
             if(pind.b0==1&&pind.b1==0 && pind.b2==1&&pind.b3==0&&pind.b4==0)
            portb=0b00000010;
            else
            portb=0;
            if (pind.b0==1 && pind.b1==1&&pind.b2==1&&pind.b3==0&&pind.b4==0)
            portb=0b00000100;
            else
            portb=0;
            if(pind.b3==1&&pind.b1==1&&pind.b2==0&&pind.b0==0&&pind.b4==0)
            portb=0b00011001;
            else
            portb=0;
            if(pind.b3==1&&pind.b1==0&&pind.b2==0&&pind.b0==0&&pind.b4==0&&pind.B5==0)
            portb=0b00010001;
            else
            portb=0;

            if(pind.b3==1&&pind.b2==0&&pind.b1==1&&pind.b0==0&&pind.b4==0&&pind.B5==0)
            portb=0b00010000;
            else
            portb=0;
            if (pind.b3==1&&pind.b2==1&&pind.b1==1&&pind.b0==0&&pind.b4==0&&pind.B5==0)
            portb=0b00010000;
            else
            portb=0;

 

    }
}

ihope you find me bascom error221

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

Stop cross posting by tacking your code onto long expired threads!

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 user

Topic locked