External Data Bus on Mega64/128

Log in or register to post comments
Go To Last Post
15 posts / 0 new
Author
Message
frostblu3710
frostblu3710's picture
Level: Wannabe
Joined: Sat. Jan 31, 2009
Posts: 80 View posts
#1
Posted by frostblu3710: Mon. May 24, 2010 - 05:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have been reading up on the external data bus on these chips and have figured out how to operate them in several different setups. One way that interested me was Design Note #028 that uses a ripple counter to walk out the address but the random speed would be terrible! But if handling large groups of data with sequential processing it would be great.

I have heard you can attach an LCD to the external bus and drive it similarly but I cannot find any AppNotes or examples to see how it works. I would presume it would only be able to drive an 8bit LCD directly or a 16bit with a latch. You would need to implement the RS, RW, R, W, E (whichever the module has) in code but then why not just use PORTB = LCD_Data instead of *EXT_MEM = LCD_DATA?

Is the external memory interface substantial faster or something? Anyways If anyone had an example of this setup that I could learn from or an explanation that would be great.

Thanks!

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Top
theusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39612 View posts
Location: Wisconsin USA
Posted by theusch: Mon. May 24, 2010 - 05:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

[full disclosure] I've never hooked an LCD to memory-mapped]

The STK200 had a header port for this. You should be able to find code examples. CodeVision has the set of functions.

I'd be tempted on this to save pins if I already had e.g. external SRAM.

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.

Top
Jepael
Jepael's picture
Level: Raving Lunatic
Joined: Mon. May 24, 2004
Posts: 6279 View posts
Location: Tampere, Finland
Posted by Jepael: Mon. May 24, 2010 - 08:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

frostblu3710 wrote:
You would need to implement the RS, RW, R, W, E (whichever the module has) in code but then why not just use PORTB = LCD_Data instead of *EXT_MEM = LCD_DATA?

Not quite, that would waste the whole idea of putting the LCD on external bus.

The external bus has both data and address regarding a read or write operation. For example with HD44780 compatible interface with RS,RW and E, you put some glue logic there, so you have the LCD in two addresses that pulse E, in the other address RS is low and in the other it is high, and RW line comes from the difference of read or write operation.

frostblu3710 wrote:

Is the external memory interface substantial faster or something? Anyways If anyone had an example of this setup that I could learn from or an explanation that would be great.

Not faster, but allows you to easily connect anything that would like to sit on a 8-bit data bus with 16-bit address bus, like memory chips or LCDs or video scalers etc, so they are memory-mapped. Then in C code, you just assign memory addresses used by devices into your own registers, so accessing devices on the bus is as easy as reading or writing a variable, that just happens to live at certain address.

For a simple case of HD44780 compatible display, no point of using the memory interface, unless you have to use external memory anyway and you can then save pins by putting LCD there.


 // either the external bus and address decoding does the  
 // transaction for you, first setting RS and RW right
 // then E high and data on bus before E low.
 set_up_external_mem_interface();
 LCDCTRL=CMD_HOME;
 LCDDATA='a';

 // or then just make subroutines that just wiggles GPIO   
 // ports to achieve that
 initialize_lcd_directly();
 lcd_cmd(CMD_HOME);
 lcd_data('A');
Top
frostblu3710
frostblu3710's picture
Level: Wannabe
Joined: Sat. Jan 31, 2009
Posts: 80 View posts
Posted by frostblu3710: Mon. May 24, 2010 - 11:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have been reading through This Page and understand how we are mapping the 4 different functions to the address bus. (RS1/R, RS1/W, RS0/R, RS0/W ) but do not see how the Enable strobe is created properly.

If you where to say output data to address 0x8100 (RS0/W) the enable line would pull up the same instant as the data and the controller would probably have issues reading correctly. I assume the reason he put two 74HC00 NAND gates in is because this creates ~15ns delay on the enable line.

My goal is to run an AT90USB1287 with CMOS camera, A 320x240 LGDP4531/ILI9325 LCD, And SRAM all on the data bus and use DMA or some CS combination to make a digital camera/pda setup. Have the ability to display the CMOS directly to the LCD and on a button press load it onto the SRAM. Might use flash if I can find the right kind but I have two 128kB SRAM on hand to try out.

Top
Kartman
Kartman's picture
Level: 10k+ Postman
Joined: Thu. Dec 30, 2004
Posts: 23019 View posts
Location: Melbourne,Australia
Posted by Kartman: Tue. May 25, 2010 - 01:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd say for the quoted application that the AVR would not be my choice - there are chips better suited to your specific application.
example:

http://www.friendlyarm.net/produ...

I got this including the 3.5" lcd for $100usd off ebay recently. I also got the camera module or you can use a suitable usb camera as well.

Top
frostblu3710
frostblu3710's picture
Level: Wannabe
Joined: Sat. Jan 31, 2009
Posts: 80 View posts
Posted by frostblu3710: Tue. May 25, 2010 - 03:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I like the FriendlyARM's especially the 7in one but the point of my project is to learn how to choose hardware, pcb layout, and write software. Especially focusing on how to use a data/address bus for inter chip data transfer. I see people who have made z80 emulators and complete systems and I would like to learn how they got all that hardware to work on the same bus. The project itself is not overly usefull. If I chose to actually make it as something people might actually want to buy I would go with an AVR Cortex M3 or something similar.

Top
Kartman
Kartman's picture
Level: 10k+ Postman
Joined: Thu. Dec 30, 2004
Posts: 23019 View posts
Location: Melbourne,Australia
Posted by Kartman: Tue. May 25, 2010 - 05:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

in reference to the mem mapped lcd, the enable signal is created from /rd /wr and A15. According to the logic the enable signal will be high when A15 is high along with /rd or /wr being low. Put simply the lcd will be addressed when you do a read or write to addresses 0x8000 to 0xffff.
In this instance you need to be aware that the average lcd module is quite slow with its bus timing so this example most likely will not work with an AVR over 4MHz.

As for Z80s etc - we had no choice but to add peripheral chips, ram and eprom. With everthing on chip these days, the requirement for doing this diminishes. But , if you want to learn then you must read up about the bus cycle times, setup and hold times etc and match these with the peripherals.

Top
frostblu3710
frostblu3710's picture
Level: Wannabe
Joined: Sat. Jan 31, 2009
Posts: 80 View posts
Posted by frostblu3710: Tue. May 25, 2010 - 08:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am planning on using a LGDP4531 controller:
http://www.datasheet4u.com/html/...
and it has a RS, RD, WR interface. The USB1287 Has RD & WR pins on its external bus but I read they strobe if their is a read but no data change while ALE remains low. Should I AND my RD/WR with ALE and have RS on A15 as usual?

I'm unsure of what cycle times and such I should be looking at as LCD controller datasheets have way to much info in them. The AVR datasheets quite clear on how long to hold the data/address before ALE strobing and such info.

Page 83 is the interface I am going to use (80-system 8-bit interface) I know that on write RD = Hi, WR strobes. on read WR = Hi, RD strobes. I assume the mega128 behaves this way as its a standard.

To address the module I have RS tied to A15 so Instructions @ 0x8000 BUT having A15 low for Data would make the address 0x0000, would I use the XMEM start address of 0x2100 for data? The only other way I can think of doing it is AND A14 & A15 so RS = Hi on address 0xC000 and Low on 0x8000 or 0x6000.

The mega128 is running at 16MHz which I know is much faster than the LCD I was going to use a timer to update the display at a more reasonable speed but do I still need to logic chips on RD and WR to delay the pulse so the LCD can read the data properly?

Last Edited: Tue. May 25, 2010 - 08:54 PM
Top
theusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39612 View posts
Location: Wisconsin USA
Posted by theusch: Tue. May 25, 2010 - 08:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Especially focusing on how to use a data/address bus for inter chip data transfer.

Yah know, I've done 100+ production AVR apps and I've yet to use the external memory interface.

Yes I do have many apps that do "inter-chip data transfer". In almost all cases other AVRs are remote (usually over a wire or on different cards) and a serial link such as UART or SPI is used.

We also tend to "just use a bigger AVR" if the job is bigger (needs more pins/peripherals).

But maybe I live in a whole different app arena. ADCs, DACs, protocol interfaces (MCP2150 for IrDA; various RF modules), 20mA current drivers, shift registers--all serial for me; none parallel.

I guess character LCDs in 4-bit mode are a kind of parallel interface. I cannot take your link but I guess I see where it (external memory interface) might be useful for a graphics display.

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.

Top
frostblu3710
frostblu3710's picture
Level: Wannabe
Joined: Sat. Jan 31, 2009
Posts: 80 View posts
Posted by frostblu3710: Tue. May 25, 2010 - 10:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

Yah know, I've done 100+ production AVR apps and I've yet to use the external memory interface.

I have not heard of many people using the external memory interface but I wonder how do you access large amounts of FLASH and high resolution LCD's? I have seen SPI flash with <40ns timing but driving a 16bit TFT takes quite a lot of cycles to hammer out its data.

I will be migrating to ARM eventually but I wanna see what I can squeeze out of an AVR and learn to optimize things. Also makes a good basis to lean ASM as I still suck horribly at it.

Top
Kartman
Kartman's picture
Level: 10k+ Postman
Joined: Thu. Dec 30, 2004
Posts: 23019 View posts
Location: Melbourne,Australia
Posted by Kartman: Wed. May 26, 2010 - 04:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After a quick read of the specs - the lcd is a 3V device so make sure as to what speed the AVR will actually work at. The write cycles seems quite fast whereas the read cycle seems to be up to 250ns. Seems like all you need is A0 to the RS, /RD & /WR connect straight up and the /CS can be tied to A15 or you can properly decode it if you have other peripherals on the same bus.

You'll learn to optimise doing this, as it is a most un-optimal solution! Polishing a turd methinks.

Top
frostblu3710
frostblu3710's picture
Level: Wannabe
Joined: Sat. Jan 31, 2009
Posts: 80 View posts
Posted by frostblu3710: Wed. May 26, 2010 - 05:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Un-optimal solution? How would you go about handling 64kB SRAM, 320x240 TFT LCD, 128MB FLASH?

I have always used shift registers to address VFD's and 7seg displays and found the idea in the Design Note #28 of having the SRAM/FLASH data tied to the AD0..7 and using a counter to walk out the address. The memory would be only slightly slower if I used an output compare pin and internal counter than a traditional SPI interface but the data read would be quicker.

Top
Kartman
Kartman's picture
Level: 10k+ Postman
Joined: Thu. Dec 30, 2004
Posts: 23019 View posts
Location: Melbourne,Australia
Posted by Kartman: Wed. May 26, 2010 - 07:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Un-optimal solution? How would you go about handling 64kB SRAM, 320x240 TFT LCD, 128MB FLASH?


Use a more suitable chip!

The actual solution depends on what sort of performance you require. At 3V, most of the AVRs only operate at 8MHz, so you're behind the eight ball to begin with in terms of performance if you're using a mega128. Nevertheless, with 128k of flash, 64k of ram you'll need to implement some form of page selection as the AVR only has 16 bits of address available sand you need >192k of space. Port pins would help here but you'll need to make sure that there is only one thread of execution accessing the memory system at one time - you cant be twiddling the lcd when an interrupt comes along and does a page swap and reads or writes to ram without taking precautions to interlock the accesses. This further degrades the performance. Since you can only use the flash to store data, using a spi dataflash device might be a simpler solution.

Top
frostblu3710
frostblu3710's picture
Level: Wannabe
Joined: Sat. Jan 31, 2009
Posts: 80 View posts
Posted by frostblu3710: Wed. May 26, 2010 - 07:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How do the big dog chips handle things then? I have seen a few ARM's (OMAP3 and XScale) that have a 32bit data bus, camera bus, and lcd bus. They also have very large DDR and Flash chips on the same data bus. Is the majority of all handling done in hardware as when I dig through some of the code access to the devices seem quite similar and exist in the same addressing scheme.

I understand that the AVR is not meant to stretched to such extremes but the best way to learn is to try something overboard and find solutions to problems. For a good example of the power you can squeeze out of an AVR check out this guys work:
http://rossum.posterous.com/

Top
Kartman
Kartman's picture
Level: 10k+ Postman
Joined: Thu. Dec 30, 2004
Posts: 23019 View posts
Location: Melbourne,Australia
Posted by Kartman: Thu. May 27, 2010 - 01:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In the 'big' chips (these are usually System on Chip SoC)the grunt work is done in the hardware - if it has a ddr or sdram interface, you just hook these devices up, set some parameters in the internal registers and the ram appears in the memory space, similarly for the flash devices. The camera interface usually consists of a i2c bus to configure the camera and a data bus for the image data. The hardware will most likly have a dma controller that you tell it where in memory to place the image data and off it goes - you code only has to access an area of ram that has the image data. For the display interface, again, there is a dma controller and specific hardware that outputs the image data from ram to the display. Since these devices have 32 bit busses, this gives you 4GB of address space to place with whereas the AVR has only 16 bit address and 64kB. Thus the need to play tricks if you want > 64kB of memory accessable. For an example of ram and memory mapped peripherals, have a look at the earlier EtherNut boards - they used a mega128 with 32k ram and a bus interfaced ethernet chip.

Top