How to use two 8bit ports to form a 16bit port ?

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

Hello Everyone!

I want to make two 8bit ports as a single 16bit port. I know that how to send 16 bit data to two 8 bit port one by one.  But I want to send unsigned char data simultaneously to the two 8bit ports without any delay. that is only in one cycle (or time taken to execute  say, "PORTA=0xFF" etc.). Is there any solution?

Thanks in advance!

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

Not gonna happen on an 8 bit AVR.  SAM device you can do this.

 

If you really need 16 bits to appear at once I suggest some sort of latch on each port such as the 74HC573.  And you would only need on 8 bit port to feed both and a couple extra i/o lines.

 

Jim

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

Please Read: Code-of-Conduct

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

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

Hi, thanks for repplying . presently i am doing this as you said using 74HC573. But i want to reduce circuit and ICs (even total cost also). Anyway, so I can only use two ports one by one.sad . Thank You!

Last Edited: Wed. Nov 8, 2017 - 04:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cheers!

Jim

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

Please Read: Code-of-Conduct

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

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

so I can only use two ports one by one

Best you can hope to achieve is two consecutive OUT instructions. It is a 1 cycle instruction though so one lot of 8 bits will lag the other by 1 cycle. Cannot be avoided using AVR alone.

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

Atmel used to[1] describe the XMega as an "8/16-bit" microcontroller; eg: 

http://www.atmel.com/images/doc8...

 

SO does the XMega have capability to address two 8-bit ports as one 16-bit port ... ?

 

[1] Nowadays, it seems to be relegated to just a plain "8-bit"

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

awneil wrote:
"8/16-bit" microcontroller
Surely th 16 in that is just talking about the existence of things like SBIW ? I don't believe Xmega has any more functionality (in terms of "ganging ports") than tiny/mega (ie none).

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

I dunno - it was just a thought.

 

And please don't call me Shirley ...

 

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

clawson wrote:
so I can only use two ports one by one Best you can hope to achieve is two consecutive OUT instructions.

AFAIK, there is only the limited case that is the exception, that of applying an external memory address to ADnn pins.  AFAIK, that applies to both AVR8 and Xmega.  Of practical use?  Dunno.

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

theusch wrote:
that of applying an external memory address to ADnn pins
I thought that even that happened in two 8 bit halves - which is why extern SRAM usually has a latch on the address lines. Or am I confused - does it output the full 16 bit address first (and 8 bits of those are latched at that time) and then 8 of the 16 lines are then used for data?

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

theusch wrote:
AFAIK, there is only the limited case that is the exception, that of applying an external memory address to ADnn pins.

CRAP I forgot about that.

 

clawson wrote:
does it output the full 16 bit address first (and 8 bits of those are latched at that time) and then 8 of the 16 lines are then used for data?

Yes.

 

I cannot believe I forgot about that as one of my first AVR project was interfacing to an external sram chip....ahh the good 'ol days

 

Jim

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

Please Read: Code-of-Conduct

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

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

Although AD0-AD7 will not be stable once they switch to outputting the data lines.

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

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

XMEGA AU EBI (A1U) has SRAM 4 port no address latch and DRAM is no address latch (3 port or 4 port)

 

Edit: EBI

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Wed. Nov 8, 2017 - 03:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the 16 bit bus connected to?

 

Usually there is some sort of data latching signal?

 

Is the issue speed of data transfer or just the extra chips?

 

JC

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

Actually, I am reading signals from 16 ADC pins of ATMEGA2560, and generate a signal indication for metal detection at particular zone. (I have 16 zones in metal detector). The program is so long that may take too much time. so I want to send all Metal detection indiction at each zone simultaniously to output (connected 16 leds to two ports). I am using same ports for showing metal strength at the same time using Latched output. 74574. so I have to out all indication at the same time. does external ram addressing pins useful?

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

Outputting to LEDS only. Do you really think that the human eye will be able to detect the 1 cycle time difference in the lighting of two banks of 8 leds?

 

Ross McKenzie ValuSoft Melbourne Australia

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

Do you really think that the human eye will be able to detect the 1 cycle time difference

You are right. Human i cannot detect difference below 100ms. But my problem is that I experienced that, when person pass through detector. Led glows very late, not at instant, if number of zones of detection are more. that's why i am trying to reduce execution of program (also I have 20x4 line lcd connected. so i have to give time to show all things on lcd also). and the calcution to generate zone indication flag takes to much time (its float data types which is requred in my calculations).

Last Edited: Thu. Nov 9, 2017 - 06:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Huh? It sounds like your computations are too slow. But then again, you really haven't given us a clear enough explanation of what you are doing.

 

Ross McKenzie ValuSoft Melbourne Australia

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

Unless that 16-bit port I/O sits in a really tight loop somewhere then I'd say that hunting less than one to a few microseconds when having performance problems on the order of 0.1 second is hunting in the wrong place.

 

Rule #4 of optimization: Always know what to optimize. That is often the hard bit.

 

Just curious: Not using floating point variables and computations, are you?

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

I think you are not focused on what will actually improve your system's performance.

 

The micro's ports will automatically latch the LEDs, either on or off, based upon the last data outputted to them.

As already mentioned, saving a couple of clock cycles on output data to LEDs doesn't make any difference at all in the human interface, and isn't likely to impact the overall speed of your project in detection and outputting data.

 

If the LEDs light up too slowly, after the detection was made, then perhaps that is because you are processing 8 or 16 detector's data before you update the display?

 

As suggested above, perhaps you can scale the math to use integer values instead of floating point math, which will likely significantly speed up the data processing.

 

We don't have much info on your hardware, but a few other thoughts:

 

LCD's are slow compared to the remaining parts in many systems.

Make sure your LCD display routines are not slowing things down.

 

Not sure what speed your processor is running at, but the Xmegas can run at 32 MHz,  That gives you 16,000,000 more clock cycles per second for your signal processing!

 

Another option, perhaps, is to put a micro on each of the 16 detectors, running full speed to just process one data channel each.  Then they feed a status signal to a Master Unit that receives the data and displays it, (a trivial task).

 

Many of the regular members on the Forum have expressed distain over multiple processor solutions to problems, but I tend to view them as just another chip in the circuit, so no big deal...

 

There are many ways to skin a cat...

 

JC  

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

DocJC wrote:
Another option, perhaps, is to put a micro on each of the 16 detectors, running full speed to just process one data channel each

Or variations on that: 8 micros doing 2 channels each; 4 micros doing 4 channels each; etc, ...

 

Many of the regular members on the Forum have expressed distain over multiple processor solutions to problems, but I tend to view them as just another chip in the circuit, so no big deal...

But if raw speed is the key concern, then you can't beat parallel processing - whatever the cost!

 

But probably there is plenty of room to optimise/improve the OP's current implementation before it comes to that ...

 

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

But surely the motive to go parallel (cf quad and octo PC processors) only comes when you have reached the limit of single core execution? If a 16/20/32MHz AVR does not deliver the performance you need trade up to a 48..120Mhz Cortex M0/M3. When that's not enough trade up to M4 adding hardware FP, DSP, SIMD. If thats not enough trade up to Cortex A executing at 200MHz.. 2GHz from cache and DRAM. If, finally that's not enough parallel them up to 4 or 8 and when that's finally not enough go for 2+ CPUs.

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

Minor problem with that is that although they may have sky-high clock speeds, they are also heavily pipelined, cached, &c., and a pipeline flush or a cache miss is a massive performance hit.

 

I don't know, but I'm curious:  Given an ARM chip at 200MHz, and given an arbitrary I/O signal that causes an interrupt, how many cycles does it take to output an indicatory signal on another arbitrarily chosen pin?  (On an AVR I get eight.  Four to call the IV, one in the ISR ('out' does have a delay, but it doesn't matter because the code is busy in the 'reti'), and three to return)

 

(For this sort of thing, incidentally, I use CPLDs and FPGAs.  It's not the clock speed - It's the lag between gzinta and gzouta that matters).

 

S.