Re: TQFP handling while developing
From: Paul E. Bennett (peb_at_amleth.demon.co.uk)
Date: 05/17/04
- Next message: Rich Webb: "Re: A quick c programming survey question - Update!"
- Previous message: Jim Granville: "Re: TQFP handling while developing"
- In reply to:(deleted message) Paul Rosen: "Re: TQFP handling while developing"
- Next in thread: Paul Rosen: "Re: TQFP handling while developing"
- Reply: Rene Tschaggelar: "Re: TQFP handling while developing"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 16 May 2004 23:04:27 +0100
Paul Rosen wrote:
> Rene Tschaggelar <none@none.net> schrieb:
>
>>What is the problem in creating an application specific board with
>>everything on that is required for the project ?
>
> The problem is, that you do not know before what hardware you need for
> a project, even in analog-applications. Software and hardware are
> developed together. You have not only to change the software, but also
> the hardware. And sometimes you need more than one controller. You
> cannot use a new board for maybe every 20 versions, because you cannot
> produce TQFD boards yourself. You have to give it away. And only one
> PCB is very expensiv and needs much time. If you could produce the PCB
> yourself, you make some changes in the layout and get a new one in
> half an hour.
Either your project planning capabilities and project control are very
naff or you are dealing with the cutting (or even bleeding) edge
technologies. I will stay with the charitable side and consider that
you are on the bleeding edge of developments. This then puts you in the
realm of prototyping designs or parts of designs to ensure that you
achieve the desired performance.
> Further controllers can be damaged, when you have a wild mess of
> soldered components. Especially audio-design and picoampere/microvolt
> measurings and applications with switched high voltage/currents are
> very messed, because her special demands of astral routing.
>
> Because all that I have to solder the TQFP-processor on a special
> ilittle board, which can be inserted in the application developement
> board.
OK, so you are already using prototyping boardlets with impedance
controlled padding. The practice of keeping other component leads
very short should still apply. Use a small tipped soldering iron but
as large as your dare (this is all about plenty of heat for very
short periods of time - mere dabs to connect). If the prototype
boardlets do not keep the footprint close to what you need for the
final layout the trim these boardlets down further till they nearly
fit. Be cognizant of the impedances between layers for your chosen
PCB materials.
> Further there is another problem: If you have finished developing with
> the adapted TQFP Controllers, you have to route the PCB new for the
> not adapted series version. And then things change. The audio or the
> measuring is wrong now, because disturbed by the controller. Or the
> application disturbes the processor now and it crashes.
Sounds like youi may need to also consider your decoupling philosophy
or your layout toplogies to ensure that you minimise cross-talk and
pickup. Take your time doing this.
> And what is about emulation, when the processor is soldered into the
> board?
>
> With socketable controllers like PLCC things were much easier. You
> could socket it and change it, when damaged. You could produce the
> developement versions of PCB yourself. Emulation is no problem: Plug
> the emulator into the socket of the controller. And the last
> developement version could without problems be the series version. And
> if you get problems to leave out the socket in the series version, you
> let him be,
>
> Even for DS you need a controller, which has the same format in the
> development and the series version. And for this purpose PLCC was a
> good solution. It is the skimpiest format, that is reliable
> socketable. But of all things the DS!!-PIC is not available in this
> package. Maybe this shows, that mirochip is new in the
> (digital-)analog segment and is not familiar with its problems.
>
Relax a little more and don't get so flustered. Sit and think a bit
more about what you are doing and whether there may be better
approaches. I haven't followed this thread from the begining but I
am sure that pausing for thought to think what others have said here
will help you resolve the problems you feel you are having.
-- ******************************************************************** Paul E. Bennett ....................<email://peb@a...> Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/> Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE...... Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details. Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
- Next message: Rich Webb: "Re: A quick c programming survey question - Update!"
- Previous message: Jim Granville: "Re: TQFP handling while developing"
- In reply to:(deleted message) Paul Rosen: "Re: TQFP handling while developing"
- Next in thread: Paul Rosen: "Re: TQFP handling while developing"
- Reply: Rene Tschaggelar: "Re: TQFP handling while developing"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|