Atmel serial backpack

penjuin · Post by **penjuin** » November 4th, 2005, 9:06 am

Hey all,

I'm making an atmel backpack for a hd44780 lcd similar to _X7JAY7X_'s pic->serial lcd but I am eventually going to port it to usb as usb is much easier to implement in an atmel then a pic. If anyone else knows anything about atmels could you please tell me? I am especially interested in UART. I am competent in completing this myself, but I am extremely busy at present but I would like to have it done.

Post by **limbo** » November 4th, 2005, 9:40 am

I used to play with some atmels but my programmer died and I'm now in a search for new one...
I can't help with you UART since I'm a begginer in AVR programming.
However there is a site called AVR Freaks (In case that you didn't noticed about it) that may help you... http://www.avrfreaks.com/

penjuin · Post by **penjuin** » November 4th, 2005, 9:47 am

ok thanks limbo, but I am well aware of the site. If you are looking for a new programmer, I realise you are far away from me, but I use this one. I like ISP programmers as I can build a board and reprogram the chip as much as I like.

_X7JAY7X_ · Post by **_X7JAY7X_** » November 4th, 2005, 2:42 pm

USB would be a nice feature. The only way I could do it right now would be to add a USB to rs232 conversion chip. The 18F series pics have USB and ethernet capabilites, but my programming software doesnt support it yet.

J

penjuin · Post by **penjuin** » November 4th, 2005, 11:45 pm

I can connect a LCD to usb using an atmel, but the controlling program is in C so it may not be easy to interface that with a delphi program such as smartie. It would be true usb1.1, not an emulated serial port.

ReverseEngineered · January 19th, 2006, 4:38 am

Hey guys,

Just found LCD Smartie a couple of hours ago and already have a 16x1 LCD up and running. Noticed that somebody is looking to make a Matrix-compatiable serial adapter using an Atmel. Guess I found the right topic.

I'm a 4th year university student studying Electrical Engineering and Computer Science (dual degree). I've been playing around with Atmel's AVRs for over a year now and have a small handful of cool stuff working.

Making a serial adapter should be quite easy. I've got all the relevant code for controlling an LCD already, just need to write a small routine to process the serial commands and all should be good. I'd suggest using one of the more common chips that they have available; the ATmega48 is one I currently have sitting around. It's a 20-pin DIP (regular 0.3 inch width, not like the double-wide 40-pin chips) with ADC, UART, two independent PWM outputs, and all the fun stuff one could use for a project like this.

And best of all, Digikey (which has American as well as Canadian locations) carries it!

What kind of features would you like to see? I'd be more than happy to throw together some code to do everything X7JAY7X has added onto his PIC design.

Possible list of features so far:

- All standard screen sizes
- Selectable 4- or 8-bit LCD interface (bit in EEPROM or external pin)
- Backlight control (with PWM)
- Selectable serial speed (115200 max) (bit in EEPROM or external pins)
- External buttons which send commands back to LCD smartie

I'm not yet familiar with the entire Matrix Orbital command set, but I can certainly implement the entire selection from the PIC version. Who knows, might even be able to use PWM to control the contrast.

I'd be more than happy to design a circuit like this for you guys. Any preferences? Should interface/serial speeds be set using bytes in EEPROM (which is programmable at the same time as the rest of the firmware), or would you rather use external pins (for jumpers or dip switches)? Would you like to eliminate the need for a crystal (possible, but makes serial speed selection limited).

Actually, looking over one of their manuals, there are definitely some cool commands, which although slightly complicated, certainly wouldn't be beyond me to build. Anybody up for making a fully-compatiable adapter? I'm in!

Only thing I need is an LCD

I've got a couple of 20x4s on the way from that eBay Hong Kong company mentioned elsewhere on these forums, so once I get those I should be able to start development.

Let me know what your ideas/intentions are and I'd be more than happy to help out.

Post by **limbo** » January 19th, 2006, 6:28 pm

The main target is to make the simplest (possible) circuit with ability to communicate with our program.

The serial interface is a very good starting point (and if its possible a USB interface).
Some Outputs (like Matrix Orbital's GPOs) may be heplful.
Some buttons in order to give commands to the system (its a MO Feature too)
Also some function like backlight ON/OFF is a must.

Of course you can add a "Startup" message...

I have more ideas for this but I'm not sure about the way to achieve them.

ReverseEngineered · January 19th, 2006, 9:21 pm

Simple circuit isn't a problem. At a minimum, almost everything can be done exactly like X7JAY7X did it. However, in order to use some features (anything which has to communicate back to the computer), a true RS232 level converter will be needed (MAX232A). It's simple to hookup, but adds a small amount to the cost/complexity.

USB is an absolute pain in the butt. It's doable, but if you plan on doing anything more advanced than serial (RS232) emulation, it's going to be an absolute pain in the ass.

My suggestion for anybody wanting to do that is to use a USB UART from FTDI. In particular the FT232R is a single-chip solution that requires no coding and allows any serial device to use USB. It uses a standard Virtual Com Port driver under Windows and Linux (both should already have one available, no download necessary) to make it seem as though there is an extra COM port.

If you really want your own USB device, it can be accomplished using a USB FIFO, like the FT245R. It's the same idea, but instead of having a serial UART on the output, it has an 8-bit interface that can be accessed just like any external memory (EEPROM, RAM, etc). It has a rather large buffer (>256 bytes if I remember correctly), so one can do very high speed transfers using it (surely unnecessary here).

My suggestion would then be to make a plain old serial adapter, and add on one of those chips should a USB connection be desired. It's the easiest all-around solution.

I'll draw up a schematic tonight to work from. Once you toss in the basic necessities, you already have almost all the functionality possible. It only takes a couple more components to get added stuff (like inputs or outputs).

I'm glad to hear that you have ideas. Even if you don't know how to acheive them, feel free to ask; I'm sure I can think up an easy solution for you.

_X7JAY7X_ · Post by **_X7JAY7X_** » January 19th, 2006, 9:29 pm

The buttons are probably the hardest part, at least from a PIC standpoint. I got them working but they will pause the data stream long enough to throw off the start and stop bits. This creates a bunch of garbage on the screen. My only option is to use interrupts. Dont know much about the ATMELS.

Selectable 4 or 8 bit LCD support is not really a necessity. 4 bit uses less data lines and is easier to hook up than 8 bit. Selectable serial is nice, I hope to add that into the next version.....for some reason I cannot get it to work above 9600bps. This is just something I have to play with.

I found a USB converter with virtual porting and built in drivers for about $15 from Linx Technologies. I am going to be getting one soon to mess with.

J

Post by **limbo** » January 19th, 2006, 9:56 pm

I believe that the serial solution described by you is a quite good for starting point.
I'm already awared about FTDI but I was not sure about the way to use these chips.
There also available an usb to parallel converter from this manufacturer.
Can you tell if its possible to use this to direct interface a HD44780 LCD to an USB port? (Stupid question? )

Anyway, I was impressed by the PIC solution created by _X7JAY7X_ and I can't wait to see the AVR too. (I'm really happy about it)

As you can see, I'm an LCD Smartie maniac

Large Image

Rafael_Brazil · Post by **Rafael_Brazil** » January 20th, 2006, 6:22 pm

Where can I found the _X7JAY7X_ solutions? I have study a lot C and Assembly to use in PICs. I have bought a PIC programmer!

Rafael_Brazil · Post by **Rafael_Brazil** » January 20th, 2006, 6:27 pm

I found!

http://www.freewebs.com/x7jay7x/

It?s possible use a PIC 16F628 in a 4x40?

And... the source code... is not a freeware yet?

_X7JAY7X_ · Post by **_X7JAY7X_** » January 20th, 2006, 10:03 pm

The source is written in basic. I just posted the .hex file. One of the things I was working on was 4x40 support when I stopped the project. I got too busy with school. I will be getting back to it soon hopefully.

The 628 is definetly capable of 4x40 support. It just uses another enable line (one more pin) because there is actually two controllers in a 4x40 LCD.

J

penjuin · Post by **penjuin** » January 22nd, 2006, 12:14 pm

Hey all,

Sorry I havent been part of this post. I have recently been on holidays, got a new job and just about turned my whole life upside down

. Anyway, I'm back and I want to help. My project can do everything except pwm and serial. I originally wrote it for a 90s2313 but am thinking of porting it to a mega8 or mega32. While a mega32 is overkill (40pin chip), it leaves a lot of room for extra features. For example, an ADC pin could be connected to an LDR, the atmel would send the amount of light to the pc and adjust the backlight on the lcd accordingly. LEDs could flash, keypads could be connected, etc.

My problem is that no matter what I do, I always get frame errors. If I try to display the data on the lcd all I get is blocks and the average symbol (x with a line over the top) and occasionally random gibberish. All of this was expected though, as I am completely self taught

. It was so frustrating and I was so busy that I just forgot about it. I would really like to get it to work though.

If anyone has anything to offer, I set up a small forum on my server to collaborate the making of it. You can find it here.

_X7JAY7X_ · Post by **_X7JAY7X_** » January 22nd, 2006, 5:08 pm

Whats up penjuin... havent heard from you in a while.

J

penjuin · Post by **penjuin** » January 23rd, 2006, 2:27 am

Hey man, ive been away for a bit.

Anyway, does anyone have some atmel UART code I can use?

ReverseEngineered · January 25th, 2006, 1:51 am

Your UART problem good quite possibly be because of a bug in the 90s2313. Check Atmel's site (or avrfreaks.net) for the errata. Basically, if the receive pin is held low when the UART receiver is enabled (perhaps by using zeners to limit the receiving line to TTL levels), then the receiver will think it has seen a start bit and will begin the receiving process, ultimately getting a framing error.

A simple fix is to put a pull up on it. A better fix is to use a MAX232 or other RS232-line level converter.

Attached is a small test program that I made for the ATmega16 while developing a thermostat. It's written in C (for avr-gcc) and uses a mix of interrupt-driven and polling techniques. I've updated it to work (hopefully) with the latest avr-libc; I can't guarantee that it works (no micro handy), but it compiles and has had minimal changes. Though not necessarily the optimal way of handling things (uses blocking reads and writes), it does show the initialization and use of the UART in as much detail as we would need for this project.

(sorry for huge post: no "attach" function apparently)

Code: Select all

#include <inttypes.h>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>
#define __STDIO_FDEVOPEN_COMPAT_12
// ensures avr-libc-1.2-style fdevopen functioning
#include <stdio.h>
#include <math.h>

#define F_CLK 16000000;

volatile uint16_t adc1;
volatile uint8_t temp_ready;
volatile FILE* uart;

void print_temp(void);

ISR(SIG_ADC)
{
    // Save results of ADC reading
	adc1 = ADCL + (ADCH<<8);
}

ISR(SIG_UART_RECV)
{
    // Print temperature if a character is received
	unsigned char c = UDR;

	if (c == '\n')
	{
	    // Responds to LF character (works for either LF or CR/LF styles)
		print_temp();
	}
}

void adcinit (void)
{
	// AVCC (AREF bypass cap to GND), right-justify (10-bit), ADC0 selected
	ADMUX = _BV (REFS0);
	// enable ADC, interrupt enabled, prescaler/128
	ADCSRA = _BV (ADEN) | _BV (ADIE) | _BV (ADPS2) | _BV (ADPS1) | _BV (ADPS0);
}

void start_conversion (void)
{
	ADCSRA |= _BV (ADSC);
}

void uartinit (void)
{
	// 16MHz clock, 9600 bps (no U2X), 8N1, interrupt-driven
	UBRRL = 103;
	UCSRB = _BV (RXCIE) | _BV (RXEN) | _BV (TXEN);
	UCSRC = _BV (URSEL) | _BV (UCSZ1) | _BV (UCSZ0);
}

void print_temp(void)
{
    uint16_t adc_value;
    float temp;
    
    // disable interrupts to save current value
    cli();
    adc_value = adc1;
    sei();
    
    // calculate actual temperature using empirically-determined constants
	temp = (adc_value - 284) * 0.089198;
	printf("ADC: %x (%d), Temperature: %3.2f\r\n", adc_value, adc_value, temp);
	// send CR/LF explicitly, since \n represents just LF (binary-safe)
}

int uart_putchar_blocking(char c)
{
	UDR = c; // write char
	loop_until_bit_is_set(UCSRA, UDRE); // wait for send to finish
	return 0;
}

int uart_getchar_blocking(void)
{
	char c;
	loop_until_bit_is_set(UCSRA, RXC); // wait for character to be received
	c = UDR; // read received char
	return (int)c;
}

int main (void)
{
	adcinit();
	uartinit();
	uart = fdevopen(uart_putchar_blocking, uart_getchar_blocking, 0);
	// above allows UART to be written/read like a file (and as stdin)
	// this is useful for printf/scanf functions

	temp_ready = 0;
	sei();

	/* loop and recheck temperature every ~100ms */
	for (;;)
	{
		start_conversion();
		_delay_ms(100);
		if (temp_ready)
		{
			print_temp();
			temp_ready = 0;
		}
	}

	return (0);
}

penjuin · Post by **penjuin** » January 25th, 2006, 11:53 am

Thanks heaps for the code man! I think I will try my code on an atmega8 first just to see if it is the bug. I've got a day off thanks to Australia day so im gonna try it then. Will report back with results.

ReverseEngineered · January 29th, 2006, 2:34 am

After a couple of hours of trying to figure out why some of my output pins weren't working, it finally dawned on me that the JTAG port is enabled by default.

Now that that's solved, I have basic functionality done, including initializing, displaying characters, and moving the cursor. Just working on character generation at the moment and then on to the more advanced MO capabilities. I expect to have all the code done tomorrow night. Testing might have to wait (found out the serial port on my laptop is screwed).

Sorry I don't have any preliminary code to post, but I'm taking a quick hour nap between jobs (weekends are the busiest times for me). I should have everything up Monday night.

Be back soon with more information.

ReverseEngineered · January 30th, 2006, 7:21 am

Okay, I have some starting code ready to go. It prints a small message to the screen, sends the cursor back to home (currently underlined for testing), and waits for input. Handles some very basic commands (clear display, home cursor, set position). Most of the code is already written to handle more complicated stuff.

Currently only 9600bps 8N1. See comments for pinout (can be changed via #defines). Be sure to adjust number of rows and columns for your display. Code is written for latest avr-gcc and avr-libc with Linux makefile. Setup for ATmega16 with 16MHz crystal. THIS IS TESTING CODE ONLY. The final version will be much nicer, I promise.

If you have the required hardware, please test it on any size of LCD you can find. I assume the code will "just work" on any LCD <= 80 characters. All I currently have to test with is a 1x16.

http://members.shaw.ca/jamescooper/moavr/lcdtest.tar.gz

Expect many more improvements soon. Schematic should be online tomorrow night.

Hex file is included. Currently set to use 1x16 display with a 16MHz clock. MAKE SURE YOUR JTAG FUSE IS DISABLED! If the screen doesn't initialize and display a message, this is probably why.

PS: Do not expect this to work properly. There WILL be bugs, I guarantee it. This is by no means complete. If you notice a serious bug (i.e. doesn't work properly for certain display sizes) or something of that nature, please post here. If it's missing a feature, check the code--I haven't implemented most of the fun things yet. But rest assured, this will be 100% MO compatiable.

_X7JAY7X_ · Post by **_X7JAY7X_** » January 30th, 2006, 3:41 pm

Does yours support 4x40?

J

penjuin · Post by **penjuin** » January 30th, 2006, 9:30 pm

Ill try and build one on the weekend, except it looks like ill be recompiling for a mega8 or mega32 as i dont have any spare 16s. Just a note: I started off like you, but am now using a lcd lib to do all the work for me

ReverseEngineered · January 30th, 2006, 11:17 pm

I considered using a library, however I had trouble getting the LCD working in the first place. Ended up being because of the aforementiond JTAG problem, but I wrote a small library to test with in the mean time, so I continued using it. Also, it was a good way to learn the hardware.

4x40 support isn't in there yet, but I can certainly add it with a minimum of fuss. Since I just received my two 2x40s, perhaps I can make a faux 4x40 from there (I certainly have enough free pins).

In the end I plan on having two versions of the code: one for a simple serial-to-LCD conversion (low part count, low cost), and another that is completely compatiable with the Matrix Orbital (right down to the more advanced auto-wrap/auto-scroll and bar graph functions). The code you see now is almost the entirety of the simple version (though horribly unrefined).

I have the night to myself tonight, so I should make some good progress. Unfortunately I also have midterms starting next week, so anything outside of the next couple of days will probably be minimal until the 14th (which is our midterm break). My goal is to have everything functioning and published by the end of that week.

ReverseEngineered · January 31st, 2006, 2:52 am

Okay, several fixes already.

I wasn't initializing them properly (the page I read didn't mention the really weird repetition of the Function Set command), so only the first line works (which was fine for my 1x16). I now have that fixed.

Also, when being fed a steady stream of serial data it resets itself (especially as the data rate increases). This could be an overrun error, but I'm not sure why that would be. In any case, I'm implementing a 16-byte FIFO right now. That should help out, especially when processing long commands (like a screen erase).

Progress has been slow (that f*&#ing initialization thing was quite elusive), but I'm working hard at it. Hopefully more news as the night (and the week) goes on.

_X7JAY7X_ · Post by **_X7JAY7X_** » January 31st, 2006, 4:37 pm

I would assume that most people do not use 90% of the commands on a MO display.

What speed are you trying to run it at when it messes up?

J