Prev: newbie to embedded linux on arm
Next: uP with two ethernet ports (MACs)
From: D Yuniskis on 16 Dec 2009 17:47
Bit Farmer wrote:
> D Yuniskis wrote:
>
>>
>> I can write a small routine to collect the incoming data from the
>> serial port. And put it in a file. Big deal. Now I have
>> a bunch of (X,Y)'s but no *context*! I.e., if digitizing
>> traces on a PCB artwork, how do I know which "points" belong to
>> each "foil"? Which points represent pads and which represent
>> "corners" of traces? Etc.
>>
>> If digitizing blueprints for a house, how do I know which
>> points belong to each "wall"?
>>
>> Sure, I could import all of the points into AutoCAD and
>> then play "connect the dots" -- and *hope* I connect them
>> properly. :-/ I need to be able to replace the tablet
>> driver with a penplot driver, so-to-speak.
>>
>> But, since HP made a point of including this feature in
>> their plotters *and* since large format digitizers were
>> expen$ive during the pen plotter era, one would think
>> there was a mechanism already in place to use this data!
>
> In our work, the reconstruction of the image was the hardest part.
>
> First attempt was to build a follower. We would advance
> in the direction that maintained the contrast. This sort of worked,
> but failed when we hit Tees and branches.
>
> Since we were rasterizing the data, we ended up just building a
> row and column matrix that held the contrast values. Once a section
> was done then we could follow the traces in data matrix. This was
> in the early/mid 80's and because memory was expensive, we could
> only do small sections.

I.e., you were just using it as an input device for a special
application. I would like to use it as a pointing device in
an *existing* application -- one to which it, theoretically,
should be well suited... :<
First  |  Prev  | 
Pages: 1 2
Prev: newbie to embedded linux on arm
Next: uP with two ethernet ports (MACs)