| Author |
Message |
|
|
 Posted: Apr 05, 2012 - 03:11 PM |
|
Joined: Dec 09, 2010
Posts: 160
Location: BW, Germany
|
|
Hi,
I try to generate CS signals for external components using the External memory interface of the AT90USB1287 and a 74HCT138N. I'm using the adressbits 12-14 of the XMEM and feed them to the Inputs of the 3 to 8 decoder. Adressbit 15 is used as G1 on the 3 to 8 decoder. I want to achieve the following outputs:
CS0 0xB000..0xBFFF - Y3
CS1 0xC000..0xCFFF - Y4
CS2 0xD000..0xDFFF - Y5
CS3 0xE000..0xEFFF - Y6
CS4 0xF000..0xFFFF - Y7
The 74HCT138 is connected as shown on the attached image.
When using adresses from 0xB000 to 0xFFFF I see the proper signals on the inputs of the 74HCT138. However I got a permanent High signal on every output.
The AVR is clocked with an external 16MHz Quarz scaled down to 2MHz using the CKDIV8 Fuse.
The XMEM interface is initialized without any special settings.
Code:
XMCRA = (1 << SRE);
XMCRB = 0x00;
Do you see any problem with the way the 74HCT138 is wired up? Or any other problem. |
Last edited by MannImMond on Apr 11, 2012 - 04:35 PM; edited 3 times in total
|
| |
|
|
|
|
|
|
Posted: Apr 05, 2012 - 03:24 PM |
|
Joined: Aug 29, 2002
Posts: 790
Location: Muenster, Germany
|
|
| That wiring is absolutely correct. If you see the correct levels at the 4 input lines A12-A15, then this circuit *must* provide the correct output. Did/can you test the circuit without actually use an AVR to generate the address signals? |
_________________
Einstein was right: "Two things are unlimited: the universe and the human stupidity. But i'm not quite sure about the former..."
|
| |
|
|
|
|
|
|
Posted: Apr 05, 2012 - 03:30 PM |
|
Joined: Dec 09, 2010
Posts: 160
Location: BW, Germany
|
|
| Hmm I may be able to test it after getting some longer wires for my breadboard since I currently don't have any at home. Is it possible that the pulses on the input of the Chip are too short for whatever reason(I only got a XProtolab at home and on that screen the pulses look really ugly). |
|
|
| |
|
|
|
|
|
|
Posted: Apr 05, 2012 - 04:26 PM |
|
Joined: Jul 19, 2011
Posts: 477
|
|
Mannin,
It all looks good to me too. I have used this type of memory decoding with a 138 on many different types of processors, but never the AT90USB1287. So, I can't say if there is something in the memory mapping set-up and/or external memory accessing of this processor that is maybe tripping you up.
In this processor is it possible to set-up the A12-A15 address pins as GPIOs? If so, do that, then write a simple loop to walk-thru the 16 state possiblilities which scoping or DVMing in a static, or near-static, condition. That exercise will at least tell you that your wiring matches your schematic. If there is a wiring mixup, you'll stand a better chance of deducing it under static conditions than with 16MHz pulses. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 05, 2012 - 04:28 PM |
|
Joined: Dec 09, 2010
Posts: 160
Location: BW, Germany
|
|
|
Chuck-Rowst wrote:
Mannin,
[...]
In this processor is it possible to set-up the A12-A15 address pins as GPIOs? If so, do that, then write a simple loop to walk-thru the 16 state possiblilities which scoping or DVMing in a static, or near-static, condition. [...]
Great idea thanks I'll try that tonight. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 06, 2012 - 03:17 AM |
|
Joined: May 04, 2007
Posts: 3529
Location: Geelong Australia, Home of the "Cats"
|
|
| What is the supply voltage of the AT90USB1287? It must be +5V to interface to the 74HCT138 which can only run on +5 (74HC138 can run on 3.3V) |
_________________
Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
(If you haven't already done so, edit your PostNuke profile and let let us know where you are, what you do & what your interests are.)
|
| |
|
|
|
|
|
|
Posted: Apr 06, 2012 - 09:36 AM |
|
Joined: Dec 09, 2010
Posts: 160
Location: BW, Germany
|
|
| The AT90USB1287 is powered with +5V since I want to clock it with 16MHz at certain times. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 07, 2012 - 07:44 AM |
|
Joined: May 04, 2007
Posts: 3529
Location: Geelong Australia, Home of the "Cats"
|
|
|
Quote:
When using adresses from 0xB000 to 0xFFFF I see the proper signals on the inputs of the 74HC138.
How are you measuring those?
Quote:
However I got a permanent High signal on every output.
One would normally deduce, that it is not enabled correctly on G1/G2A/G2B! |
_________________
Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
(If you haven't already done so, edit your PostNuke profile and let let us know where you are, what you do & what your interests are.)
|
| |
|
|
|
|
|
|
Posted: Apr 07, 2012 - 11:30 AM |
|
Joined: Dec 09, 2010
Posts: 160
Location: BW, Germany
|
|
|
LDEVRIES wrote:
Quote:
When using adresses from 0xB000 to 0xFFFF I see the proper signals on the inputs of the 74HC138.
How are you measuring those?
I got one of these fantastic XProtolabs from Gabotronics which means I can only measure roughly at this frequency but I see peaks on the correct Pins.
Quote:
Quote:
However I got a permanent High signal on every output.
One would normally deduce, that it is not enabled correctly on G1/G2A/G2B!
Yes that's what I assumed aswell. G1 is tied to A15 and shows of course the same peak as the other Adress lines -> is that a problem? G2A and G2B are hardwired to Ground as shown in the schematic (and measured aswell). |
|
|
| |
|
|
|
|
|
|
Posted: Apr 07, 2012 - 01:17 PM |
|
Joined: Nov 01, 2005
Posts: 6354
Location: Hilversum - the Netherlands
|
|
Mr Moonlight, glitches on the outputs of the 138 are unevitable in this HW setup. You need some gating signal that tells when an address is valid.
It depends on what you plan to connect to the outputs of the 138.
Edit: if you use ALE as "address is valid"-signal, and connect it to G2A or G2B, you will have clean and glich-free outputs. |
_________________
Dragon broken ? Or problems with the Parallel Port Programmer ? Scroll down on my projects-page http://www.aplomb.nl/TechStuff/TechStuff.html for tips
Last edited by Plons on Apr 07, 2012 - 01:25 PM; edited 1 time in total
|
| |
|
|
|
|
|
|
Posted: Apr 07, 2012 - 01:17 PM |
|
Joined: May 04, 2007
Posts: 3529
Location: Geelong Australia, Home of the "Cats"
|
|
|
Quote:
I got one of these fantastic XProtolabs from Gabotronics which means I can only measure roughly at this frequency
While they are a nice device, I would not call it a definitive test.
Quote:
but I see peaks on the correct Pins.
But are the peaks valid logic signals?
Quote:
G1 is tied to A15 and shows of course the same peak as the other Adress lines -> is that a problem?
I suspect so! You could try connecting G1 to Vcc temporarily, which means you are at least 100% certain of enabling it and you should get at least one active output.
If that gives you you outputs, perhaps a pull-up(4.7-10K)on G1 might help ( and more than likely you will require them on A,B & C as well.
Nard brings up a good point if you are going to address memory. I can recall the E signal in MC6809 days(& earlier days) |
_________________
Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
(If you haven't already done so, edit your PostNuke profile and let let us know where you are, what you do & what your interests are.)
|
| |
|
|
|
|
|
|
Posted: Apr 07, 2012 - 02:26 PM |
|
Joined: Dec 09, 2010
Posts: 160
Location: BW, Germany
|
|
|
Quote:
You need some gating signal that tells when an address is valid.
It depends on what you plan to connect to the outputs of the 138.
The output of the 138 controls the CS for an 8255A. A0-A1 are used as inputs to the 8255A on this extension card whereas A12-A15 are used to chose between different cards(different CS).
Plons wrote:
[...]
Edit: if you use ALE as "address is valid"-signal, and connect it to G2A or G2B, you will have clean and glich-free outputs.
That is a good idea.
Quote:
Quote:
but I see peaks on the correct Pins.
But are the peaks valid logic signals?
I can't test that at home. I will have the chance on Tuesday. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 07, 2012 - 02:34 PM |
|
Joined: Nov 01, 2005
Posts: 6354
Location: Hilversum - the Netherlands
|
|
|
Quote:
The output of the 138 controls the CS for an 8255A. A0-A1 are used as inputs to the 8255A on this extension card whereas A12-A15 are used to chose between different cards(different CS).
Then my suggestion for using ALE on G2A or G2B will do fine. Rd and Wr on the 8255A will take care of the rest.
Btw, I had to consult an old Intel databook: 1983. And the typical smell brought back memories ....
Nard |
_________________
Dragon broken ? Or problems with the Parallel Port Programmer ? Scroll down on my projects-page http://www.aplomb.nl/TechStuff/TechStuff.html for tips
|
| |
|
|
|
|
|
|
Posted: Apr 07, 2012 - 09:21 PM |
|
Joined: Nov 01, 2005
Posts: 6354
Location: Hilversum - the Netherlands
|
|
| If the 8255 boards are more than 30-40 cm away from the AVR, put resistors in series and cap's to ground on all signals going to those boards: AVR's and HC(T)logic have larger slewrate values then the old stuff. |
_________________
Dragon broken ? Or problems with the Parallel Port Programmer ? Scroll down on my projects-page http://www.aplomb.nl/TechStuff/TechStuff.html for tips
|
| |
|
|
|
|
|
|
Posted: Apr 07, 2012 - 11:21 PM |
|
Joined: Dec 30, 2004
Posts: 9003
Location: Melbourne,Australia
|
|
| The OP may have to resort to using bit bashing to implement the bus interface. 8255 were not too fast at the gest of times. To see if the decoder is working, use a flipflip or d type latch clocked by the select output and put a led or two on the output. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 08, 2012 - 07:41 AM |
|
Joined: Nov 01, 2005
Posts: 6354
Location: Hilversum - the Netherlands
|
|
|
Quote:
8255 were not too fast at the gest of times.
Indeed.
But I checked the Intel databook and the datasheet of the 1287; with the info that the 1287 is running at 2MHz, my conclusion is that Moonraker is in the clear  |
_________________
Dragon broken ? Or problems with the Parallel Port Programmer ? Scroll down on my projects-page http://www.aplomb.nl/TechStuff/TechStuff.html for tips
|
| |
|
|
|
|
|
|
Posted: Apr 11, 2012 - 01:19 PM |
|
Joined: Dec 09, 2010
Posts: 160
Location: BW, Germany
|
|
It seems that the 138 can't handle that speed. The highest speed that still worked was using 2 NOPs(At 2MHz) between toggling writing 0x0B -> 0x00 to the port. This seems way too slow for this device. This was measured when nothing was connected to the output of the 138. The NXP datasheet claims a max. propagation delay of 35/40 ns for 25°. Which would result in a frequency of 25MHz. Or is the propagation delay the wrong parameter?
Quote:
Quote:
The output of the 138 controls the CS for an 8255A. A0-A1 are used as inputs to the 8255A on this extension card whereas A12-A15 are used to chose between different cards(different CS).
Then my suggestion for using ALE on G2A or G2B will do fine. Rd and Wr on the 8255A will take care of the rest.
Do I really need to do this? G1 is already connected to A15. Only Adresses from 0xB000 - 0xFFFF are used in this System which means chip selects are only generated for valid adresses. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 11, 2012 - 03:32 PM |
|
Joined: Nov 01, 2005
Posts: 6354
Location: Hilversum - the Netherlands
|
|
|
Quote:
Do I really need to do this?
Yes. The address-lines A8~A15 change level when ALE is high. Decoding without ALE to G2A or G2B will result in spikes on the outputs during level-change of A8~A15.
About the 74HTC138N (I assume you mean 74HCT138N): I checked the datasheet, and I see no reason for the need of a 2 NOP delay.
Can you post the complete schematic and the test SW ?
Edit: 2 NOP delay ?? Are you writing to the IO-ports instead of using the external memory interface ? And how do you set SRWn1 and SRWn0 ?? |
_________________
Dragon broken ? Or problems with the Parallel Port Programmer ? Scroll down on my projects-page http://www.aplomb.nl/TechStuff/TechStuff.html for tips
|
| |
|
|
|
|
|
|
Posted: Apr 11, 2012 - 04:30 PM |
|
Joined: Dec 09, 2010
Posts: 160
Location: BW, Germany
|
|
|
Plons wrote:
Quote:
Do I really need to do this?
Yes. The address-lines A8~A15 change level when ALE is high. Decoding without ALE to G2A or G2B will result in spikes on the outputs during level-change of A8~A15.
Ok I'll try that.
Quote:
About the 74HCT138N (I assume you mean 74HCT138N): I checked the datasheet, and I see no reason for the need of a 2 NOP delay.
Can you post the complete schematic and the test SW ?
Yes HCT. I'll fix it.
Both attached
Quote:
Edit: 2 NOP delay ?? Are you writing to the IO-ports instead of using the external memory interface ? And how do you set SRWn1 and SRWn0 ??
Yes I tested everything by writing to the IO-ports because it worked with static levels(as suggested by Chuck-Rowst) but it failed using the XMEM interface @2MHz that's why I lowered the delay between toggling the pins down to 2 Nops.
Using 16MHz Quarz with CKDIV8
Code:
Code:
#define F_CPU 2000000UL
#include <avr/io.h>
#include <stdint.h>
#include <stdio.h>
#include <util/delay.h>
#define OFFSET 0xB000
#define PIO_A_KANAL 0xB000
#define PIO_B_KANAL 0xB001
#define PIO_C_KANAL 0xB002
#define PIO_CTRL 0xB003
#define PIO_INIT 0x90
void test_init();
int main(void)
{
test_init();
while(1)
{
PORTC = 0xB0;
asm("Nop");
asm("Nop");
PORTC = 0x00;
_delay_ms(1000);
}
}
void test_init()
{
DDRC = 0xFF;
PORTC = 0xB0;
}
|
|
|
| |
|
|
|
|
|
|
Posted: Apr 11, 2012 - 04:46 PM |
|
Joined: Nov 01, 2005
Posts: 6354
Location: Hilversum - the Netherlands
|
|
|
Quote:
Yes I tested everything by writing to the IO-ports because it worked with static levels
But my dear fellow, direct accessing the IO-port is a completely different way of "cooking". You will need the external memory interface when you want to control the 8255A's.
With direct access to portC, ALE needs to be handled as well: portE.2
Thanks for posting what I asked for, I will have a further look into it tonight.
PS1 We need the underlying assembler code when we discuss timing
PS2 With the program as posted, can you post scope-picture of the 138 output ? |
_________________
Dragon broken ? Or problems with the Parallel Port Programmer ? Scroll down on my projects-page http://www.aplomb.nl/TechStuff/TechStuff.html for tips
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
