Need help to implement a bi-directional parallel interface

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

Hi everybody,
I need help in order to implement a bi-directional parallel interface to be able to communicate with a PC program.
I use ATmega128 @ 7.3728MHz. I do have 8 pins reserved for data lines (Data0...Data7 on PORTA) and also I reserved 7 lines for control signals on PORTC (no problem if some of these will be left used, it would be just better). Unfortunately, none of this signals corresponds to an external interrupt of AVR :-( ... But, that's life: you can't have everything you want.
Thx in advance!

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

I have noticed several of your posts on a similar theme.
Think about using RS232 in asychronous mode (as it is the easiest way to communicate with a PC). Just needs 3 wires, TX,RX and gnd.

Use MAX232 or similar and connect it to the USART, add a 9 pin D connector.....and you're done.

You only need a few lines of code....and then you can use printf, (which makes life much easier). To start with, you can use brays terminal (or similar) to cumminicate with your AVR.

Alternatively, if you have the STK500 (or similar) you already have everything you need......it is a 5 minute job.

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

A very common scheme is just your N data lines, one direction control line (read/write, as viewed from one end of the interface) and a "strobe" used to signal "valid data". Depending on the latency (response speed) of the PC, the hold time after ValidData = true might be quite long. You might want to add another line or two to indicate to the other device that data is ready to transfer (one owned by AVR, other owned by PC).

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

AppNote AVR325 describes communication PC<->AVR using an EPP-mode
parallel port. As I recall it's capable of 66KB/s each way using a 4MHz AVR.
It's certainly capable of eating up most of your 15 pins, if that's your goal (:-)).

Though AVR325 is a pretty cute hack (if I do say so myself) I think that in the
meantime UARTs have gotten faster (or should I say: have gotten more reliable at
high speeds), so you may be able to get the same sort of throughput using
just a serial port -- much simpler and lots fewer pins. Or add a USB chip and
it should really zoom.

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

Quote:
I have noticed several of your posts on a similar theme.

Absolutely impossible :-( I think you are making a confusion here!
This "parallel interface" project has been started just today!
Quote:
Think about using RS232...

I know almost everything about RS232/RS485 etc... but this is not what I need now.
The project requires a parallel interface... (it's not up to me).
Thx anyway :-)

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

Quote:
AppNote AVR325

Yes... :-(... I already got it... but it's assembler & it's not very snug for me.
And, BTW: it does use an external interrupt (INT0 if I remember well).
I searched all day for something written in C and found nothing suitable (yet).

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

Quote:
The project requires a parallel interface.

I'm not going to disagree with you, but on the face of it this seems like a
curious requirement. Is it the case that a serial interface that runs at
least as fast as the parallel "competition" is disqualified? (If I felt pedantic,
I could probably make a case that a serial interface -- particularly a
synchronous one -- is simply a 1-bit-wide parallel interface (:-)).)

I'm not picking on you -- I'm really curious.

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

Quote:
I searched all day for something written in C

If it's worth that much of a time investment, I'll point out that AVR325
doesn't really contain that much code (quite a lot of blather, er, comments).

1) It probably wouldn't require much to make it C-callable, by re-arranging
the register usage to accomodate your chosen C compiler.
2) It wouldn't take a whole lot more effort to re-write part/all of it in C.
The only thing to watch out for is that the ISR has a hard 10us deadline,
but this is probably do-able, particularly with 2x the clock cycles.

But yes, it does depend on an INT pin -- though I suspect you'll have to
deal with that in some form for whatever protocol you end up with.

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

Sorry... I don't think I understand very well what do you mean by that:

Quote:
2x the clock cycles

#
Finally, I think I'll try to adapt AVR325 from asm to C...

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

Hi,

I suspect mckenney is referring to AVR325 using a 4MHz AVR and you using a 7.xxxxMHz AVR...almost 2x :-) . My apologies if I am speaking wrongly of mckenney's intent.

Regards,
Steve

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

Quote:
2x the clock cycles

The ISR was "sandpapered" to the point that all paths ran in less
than 10us on a 4MHz AVR. Since your device is running (almost)
twice as fast, you should still be able to meet the deadline even if
your C-translation were to (almost) double the longest path length.

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

@mckenney: 2x Xtal obviously...
Oh... yes! :-)
I think I'm very tired after a long day of work (3 projects simultaneously + a bootloader).
Now I'm not "compiling" very well... I will resume tomorrow.

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

It's ok now!
Yesterday I had few hours spare time, so I ported AVR325-asm to C - CodeVision AVR.
And the result is: it works like a charm :-) [tested using the PC program found inside archive AVR325.zip]. The transfer rate is surprisingly good: max. 110 kbytes/sec. (10 times faster than my 115200 bps COM port). Well... I'm really happy: instead of waiting 2 minutes, now I'll wait only 10-12 seconds for the data transfer to B ready :-) ).
Thx U all! especially mckenney.

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

Hang on... you transferred stuff at 10K per sec for 120 sec.... so you sent 1.2megabytes to an avr with 128K of rom and 4 k of ram? What am I missing in this picture?

Imagecraft compiler user

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

Quote:

Hang on... you transferred stuff at 10K per sec for 120 sec.... so you sent 1.2megabytes to an avr with 128K of rom and 4 k of ram? What am I missing in this picture?

Could it be that the transmitted data is from I/O ?

I'll believe corporations
are people when Texas executes one.

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

Could be, but I was going to suggest converting the hex file to binary to speed up a program download by another factor of 2, assuming you can burn the pages that fast....

Imagecraft compiler user

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

Quote:

Hang on... you transferred stuff at 10K per sec for 120 sec.... so you sent 1.2megabytes to an avr with 128K of rom and 4 k of ram? What am I missing in this picture?

It could be that the data comes from I/O....

I'll believe corporations
are people when Texas executes one.

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

bobgardner wrote:
Hang on... you transferred stuff at 10K per sec for 120 sec.... so you sent 1.2megabytes to an avr with 128K of rom and 4 k of ram? What am I missing in this picture?

Hi Bob!
Check this: AT45DCB002 :arrow: AVR :arrow: PC104 :wink:

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

bobgardner wrote:
Could be, but I was going to suggest converting the hex file to binary to speed up a program download by another factor of 2, assuming you can burn the pages that fast....

Oh, for a BL you mean... Of course, good idea.

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

Quote:
it works like a charm

Nifty! I'm curious: How did you deal with the (absent) INTx line? The only
solutions I could think of required a very patient/cooperative host.

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

Quote:
Nifty! I'm curious: How did you deal with the (absent) INTx line?

Hi! Your curiosity is rightful! :-)
I moved the STROBE line on pin 28 (INT3). Lucky me, 'cause in this project I need only the Rx on UART1, otherwise...

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.