Homebrew PCBs

> Roger wrote:
>
> I am very interested in your approach, code
> etc etc, although I will probably use a PIC
> for the raster handling since I already have
> a PIC controlling the 3 axes and the spark
> control. I never thought of the TIFF format.
> Please post anything you develop, all will
> be gratefully received. 

Roger - I missed this part in the TIFF FAQ

<Quote from a TIFF faq>

Question 7. Can I not stream TIFF? Why does my
library need seeking forward and backward in
my TIFF file?

TIFF is not a streamable format. It is its
very nature that all data blocks can be
written in any order that is convenient for
the particular application and/or TIFF
encoding library.

</Quote>

The first TIFFs I looked at where suitable
for streaming.  They had the information
header in front of the actual picture data.

However the main app I use, and I guess a lot
of people do, is irfanview.  It saves TIFF
with the header at the end of the file.
Many other apps probably do the same.

This just can't work for the plotter (or I
guess for your EDM).  This is because the
ATMEL (or PIC) does not have enough memory
to hold the whole file.  It has to burn each
line as it receives it and then discard that
data to buffer the next line.

Problem here is that you don't get to find
out things like how wide and how long the
file is in pixels until you get to the end
of it.

BMP is a much more strictly organised file
structure and always has the picture info
in front of the picture.  It is an absolute
doddle to read.

The draw back of BMP is that there is no
compression.

a 12 inch by 6 inch 2000 DPI black and white
BMP will be 35 megabytes.

At 115200 baud if you take into account
overheads of a UART, X-Modem and the like
you end up with a 63 minute transfer.

Even at 1 megabaud it takes 7 minutes.

7 minutes IS within the time limit I would
like a plot to come out, but receiving at
1 megabaud is going to be a bigger strain
on resources of the ATMEL than if it where
to be run length compressed.

It would be easier for me to receive a
3.5 megabyte file and decompress it on the
fly than receiving 35 meg.

The EDM requirments are probably not as bad.
I would probably guess 500 dpi (0.05mm) would
be your highest res.

However it would still probably be easier for
your PIC to receive and do the CRC of a
smaller file and then decompress an easy
scheme like G3 or PackBits.

Tell me what you think?  I am now thinking

- Read BMP file in PC software.
- Get PC to compress and send to ATMEL or
  PIC in X-Modem-CRC format.
- Atmel decompresses to actual raster data.