Lpc2000

The LPC3180 is the industry's first 90nm ARM9-based microcontroller. 
The new 32-bit MCU provides high performance with low power 
dissipation, and is the only ARM9 microcontroller that provides a 
vector floating-point co-processor and integrated USB On-The-Go, as 
well as the ability to operate in ultra-low-power mode down to 0.9V. 
With speeds of up to 200 MHz, the LPC3180 is ideal for a wide range 
of high-precision applications such as point-of-sale (POS) 
equipment, medical and industrial devices, global positioning 
systems (GPS), and robotics. 

The LPC3180 is the first microcontroller available in the LPC3000 
family, which is based on the popular, high-performance ARM926EJ-S 
core. The on-board MMU supports major operating systems, including 
Linux which is the leading major embedded OS. The on-chip Java byte-
code co-processor provides for basic security and authentication 
applications. 

The LPC3180 is the only ARM9 microcontroller on the market today 
that offers a hardware vector floating-point unit for speed and 
efficiency. The LPC3180 is the first ARM9 MCU to offer USB On-The-Go 
(OTG) integrated with full host capability for direct connection to 
PDAs, smart-card readers, and printers. The large array of 
peripherals available on-chip also include 7 UARTs, SPI, I2C, a real-
time clock with a separate power domain, and NAND Flash and DDR 
memory controllers. 

Flexible power management allows high peak performance, especially 
for floating-point calculations, and allows shutting down the core 
power domain while retaining Real-Time Clock and wake-up 
functionality. The hardware floating-point co-processor speeds up 
typical calculations by a factor of 4 to 5 in scalar mode and much 
more in optimized vector mode. 

http://www.standardics.philips.com/products/lpc3000/

But no ethernet :(

Hello everyone,

I've got a bit of a strange problem with the RTC in my setup.  I have a 
dedicated lithium battery going to the Vbat pin to power the RTC, and it 
usually works fine, however periodically the clock changes to an invalid 
value and stops running.  Usually this value is something like "Year:129 
Month:00 Day:16 Hour:02 Min:09 Sec:08", and unless I reset the RTC to a 
valid value it stops running.  This will usually happen after several hours 
of Vcc absent (i.e. device powered off) or after a day or two running 
constantly.  Nothing else is disrupted.  I have a 3.6V lithium running 
through a diode which drops the voltage at the pin down to 3.165V when Vcc 
present and to 3.232V when Vcc absent (implying that more current is drawn 
when the micro is powered on??)

Does anyone have any ideas?

-- Sean

--- In lpc2000@yahoogroups.com, David Hawkins <dwh@o...> wrote:
>
> 
> But no ethernet :(
>

Hehe, this device is targeting handheld market. Isn't nexperia 90nm?
Same core (no VPF). 

Hey... what about LPC2888? I didn't know that Philips is advertising
products before the "real official annoucement"? I can see it in the
new selection guide. 

http://www.standardics.philips.com/literature/other/microcontrollers/pdf/selection.guide.pdf

--- In lpc2000@yahoogroups.com, Sean <embeddedrelated@w...> wrote:
>
> Hello everyone,
> 
> I've got a bit of a strange problem with the RTC in my setup.  I have a 
> dedicated lithium battery going to the Vbat pin to power the RTC,
and it 
> usually works fine, however periodically the clock changes to an
invalid 
> value and stops running.  Usually this value is something like
"Year:129 
> Month:00 Day:16 Hour:02 Min:09 Sec:08", and unless I reset the RTC to a 
> valid value it stops running.  This will usually happen after
several hours 
> of Vcc absent (i.e. device powered off) or after a day or two running 
> constantly.  Nothing else is disrupted.  I have a 3.6V lithium running 
> through a diode which drops the voltage at the pin down to 3.165V
when Vcc 
> present and to 3.232V when Vcc absent (implying that more current is
drawn 
> when the micro is powered on??)
> 
> Does anyone have any ideas?
> 
> -- Sean

I have had my setup working for a week already with a 3V lithium.  I'm
using a MMBD2838LT1 dual diode cathode connected.  I have a 560ohm
after the battery (which is probably not necessary) to one anode. 
Cathodes to the VBAT pin.  Other anode to VDD so it is powering it
when VDD
is up.  I haven't seen anything like what you are seeing. Also, I have
 a SE2417 separate crystal.
Steve

> But no ethernet :(

It sure seems the LPC23xx has dropped way down in priority.  I'd be
surprised if it was available this year.


Joel

--- In lpc2000@yahoogroups.com, "philips_marketing_usa"
<philips_marketing_usa@y...> wrote:
>

*Press stuff*

Conveniently not mentioning that it's in the dreaded BGA format only.
So  we can forget prototyping with it. Looks like they didn't listen :o(

I'm not asking for a huge chip with 320 legs, just something like the
Atmel AT91RM9200. 

Mike

BGA ....
I don't know in other countries, but here in Brasil, unless you have a 
lot of money that means : "Hey don't use me"
I know of a lot of good ICs that I just cannot use, just because here is 
very hard to assembly this boards ans almost impossible to prototype BGA 
components.
But... That's the way life is...

Mike wrote:
> --- In lpc2000@yahoogroups.com, "philips_marketing_usa"
> <philips_marketing_usa@y...> wrote:
> >
>
> *Press stuff*
>
> Conveniently not mentioning that it's in the dreaded BGA format only.
> So  we can forget prototyping with it. Looks like they didn't listen :o(
>
> I'm not asking for a huge chip with 320 legs, just something like the
> Atmel AT91RM9200.
>
> Mike
>
>
>
>
>
>
>
>
>
>
> SPONSORED LINKS
> Microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=mfaAujKZXA2Z_vxre9sGnQ> 
> 	Microprocessor 
> <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=9jjd2D3GOLIESVQssLmLsA> 
> 	Intel microprocessors 
> <http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=OMnZuqMZX95mgutt4B-tDw> 
>
> Pic microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=Malspbd0T4Rq3M4Q0nHrfw> 
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "lpc2000
>       <http://groups.yahoo.com/group/lpc2000>" on the web.
>        
>     *  To unsubscribe from this group, send an email to:
>        lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>



[Non-text portions of this message have been removed]

Ok, so it seems I'm not the only one concerned with BGA
prototyping or 'hobbiest' use of such devices.

What kind of expense have people experienced for board
manufacturing?

I have used subcontractors to load boards with *LOTS* of
BGA devices, and if I recall correctly, there was a $3k
NRE charge to setup the reflow machines. We had a bad
FPGA on one board, and that same company was able to
remove and replace the BGA using a hot air gun. A
pretty impressive feat - given that there were lots of
FPGAs around the one they removed (it was a correlator
board)

http://www.ovro.caltech.edu/~dwh/correlator

How about the guys reading this list that have played with
homemade reflow machines based on quartz ovens - any attempts
at loading BGA devices? Any success?

Dave

Sean wrote:

>Hello everyone,
>
>I've got a bit of a strange problem with the RTC in my setup.  I have a 
>dedicated lithium battery going to the Vbat pin to power the RTC, and it 
>usually works fine, however periodically the clock changes to an invalid 
>value and stops running.  Usually this value is something like "Year:129 
>Month:00 Day:16 Hour:02 Min:09 Sec:08", and unless I reset the RTC to a 
>valid value it stops running.  This will usually happen after several hours 
>of Vcc absent (i.e. device powered off) or after a day or two running 
>constantly.  Nothing else is disrupted.  I have a 3.6V lithium running 
>through a diode which drops the voltage at the pin down to 3.165V when Vcc 
>present and to 3.232V when Vcc absent (implying that more current is drawn 
>when the micro is powered on??)
>
>  
>
Diode switching is needed to maintain the Vbat when Vdd (3.3v main) is 
absent and to switch over to the battery when Vdd disappears.  It sounds 
like you have that working?  It will take two diodes (1N4148A) and a 
resistor (560ohm) to do this properly.  Cathodes of both diodes go to 
Vbat line, anode of one diode goes to Vdd, anode of other diode is 
series with 560ohm to positive terminal of Lithium cell.

This is half the solution, the hardware half.  I found that my clock 
would also "explode" on occasion and seemingly at random.  The solution 
I took was a bit more aggressive in the software.  Study my clock 
routines, especially awakenClock() and sleepClock().  Essentially, when 
the clock registers are not needed, they are "disconnected".

=============== begin RTCfuncs.c ===================
/*************************************************************
 * RealTime awareness functions.  Provide for elapsed time
 * intervals as well as reading data & time from RTC.
 *
 * (C) 2005 - Tom Walsh <tom@...>
 * May be used for hobby or commercial purposes as long as
 * this notice remains intact.
*************************************************************/
#include <LPC21xx.h>
#include <lpcRTC.h>
#include <time.h>
#include <sys/times.h>
#include    <sysdefs.h>
#include <system.h>

#define    CCR_CLKEN        BIT(0)
#define    CCR_CTCRST        BIT(1)
#define    CCR_CTTEST0        BIT(2)
#define    CCR_CTTEST1        BIT(3)
#define    CCR_CLKSRC        BIT(4)
#define    T0_MS_DIV        (PCLK / 10000)


long systemTickCounter;

static inline void sleepClock(void)
{// place RTC on 32kHz xtal and disconnect power.
    RTCCCR = (CCR_CLKEN | CCR_CLKSRC);
        // power off the clock registers.
    PCONP &= ~PCRTC;
}

static inline void awakenClock(void)
{// prepare clock for interactive use.
    RTCCCR = (CCR_CLKEN | CCR_CLKSRC);
        // power up the clock registers.
    PCONP |= PCRTC;
}

static void startMsTimer (void)
{// tick timer, 1ms heartbeat for the system.
        // connect VIC to Timer0
    Timer0VectAddr = (uint32_t)timer0ISR;    // address of the ISR
    Timer0VectCntl = VIC_ENABLE | VIC_TIMER0;
    VICIntSelect &= ~VIC_BIT(VIC_TIMER0);  // Timer0 selected as IRQ
    VICIntEnable = VIC_BIT(VIC_TIMER0);    // Timer0 interrupt enabled
    T0TCR = TCR_RESET;                        // reset & disable timer 0
    T0PC = 0;
    T0PR = T0_MS_DIV;
    T0CCR = 0;    // timer mode.
    T0EMR = 0;    // no external match.
    T0MR0 = 9;
    T0MCR = 3;    // reset and interrupt on terminal count.
    T0TCR = TCR_ENABLE;
        // init the system ticks.
    systemTickCounter = 0;
}

void setElapsed (int HowLong, struct TIMER * timer, timertype_t TimerType)
{ /* set for a TimeElapsed event. */
    timer->HowLong = HowLong;
    timer->Type = TimerType;
    if (timer->Type == TimerInMilli) timer->SetTime = times (0);
    else timer->SetTime = time (0);
}

bool timeElapsed (struct TIMER * timer)
{ /* return True if preset interval has expired. */
time_t TestTimerNow, TestTimeStart;
    if (timer->Type == TimerInMilli) TestTimerNow = times (0);
    else TestTimerNow = time (0);
    TestTimeStart = timer->SetTime;
     if (((TestTimeStart>TestTimerNow) ? (TestTimerNow + 
(~TestTimeStart)) : (TestTimerNow - TestTimeStart)) > timer->HowLong) {
        return True;
    }
    return False;
}

void initRTC(void)
{// start clock so that the sytsem may use it.
#ifdef HAS_CLOCK
bool nonsense = False;
rtcCTIME0_t    ctime0;
rtcCTIME1_t    ctime1;
rtcCTIME2_t    ctime2;
struct tm newTime;
time_t resetTime;
    awakenClock();
        // see if clock contains nonsense values.
        // grab time as consolidated to avoid misses.
    ctime0 = RTCCTIME0; ctime1 = RTCCTIME1; ctime2 = RTCCTIME2;
        // leisurely tear the packed time apart into individual time.
    if ((ctime0.seconds < 0) || (ctime0.seconds > 59)) nonsense = True;
    if ((ctime0.minutes < 0) || (ctime0.minutes > 59)) nonsense = True;
    if ((ctime0.hours < 0) || (ctime0.hours > 23)) nonsense = True;
    if ((ctime1.dayOfMonth < 1) || (ctime1.dayOfMonth > 31)) nonsense = 
True;
    if ((ctime1.month < 1) || (ctime1.month > 12)) nonsense = True;
    if ((ctime1.year < 1980) || (ctime1.year > 2050)) nonsense = True;
    if ((ctime0.dayOfWeek < 0) || (ctime0.dayOfWeek > 6)) nonsense = True;
    if ((ctime2.dayOfYear < 0) || (ctime2.dayOfYear > 366)) nonsense = True;
    sleepClock ();
    if (nonsense) {
        // set the clock to Jan 1, 2006 00:00:00
        resetTime = 1136073600l;
        localtime_r (&resetTime, &newTime);
        newTime.tm_year += 1900;
        newTime.tm_mon += 1;
        newTime.tm_yday += 1;
        writeRTC (&newTime);
    }
#endif
        // start realtime heartbeat (1ms period).
    startMsTimer();
}

/**************************************************
 *
 * readRTC & writeRTC are supporting functions
 * for the newlib stubs.
 *
**************************************************/

void readRTC (struct tm *theTime)
{// read clock registers and return tm structure.
#ifdef HAS_CLOCK
rtcCTIME0_t    ctime0;
rtcCTIME1_t    ctime1;
rtcCTIME2_t    ctime2;
    awakenClock();
        // grab time as consolidated to avoid misses.
    ctime0 = RTCCTIME0; ctime1 = RTCCTIME1; ctime2 = RTCCTIME2;
        // leisurely tear the packed time apart into individual time.
    theTime->tm_sec = ctime0.seconds;
    theTime->tm_min = ctime0.minutes;
    theTime->tm_hour = ctime0.hours;
    theTime->tm_mday = ctime1.dayOfMonth;
    theTime->tm_mon = ctime1.month;
    theTime->tm_year = ctime1.year;
    theTime->tm_wday = ctime0.dayOfWeek;
    theTime->tm_yday = ctime2.dayOfYear;
    theTime->tm_isdst = False;
    sleepClock ();
#endif
}

void writeRTC (struct tm *newTime)
{// set clock to new values.
#ifdef HAS_CLOCK
    awakenClock();
        // grab time as consolidated to avoid misses.
    RTCTCR->seconds = newTime->tm_sec;
    RTCTCR->minutes = newTime->tm_min;
    RTCTCR->hours = newTime->tm_hour;
    RTCTCR->dayOfMonth = newTime->tm_mday;
    RTCTCR->month = newTime->tm_mon;
    RTCTCR->year = newTime->tm_year;
    RTCTCR->dayOfWeek = newTime->tm_wday;
    RTCTCR->dayOfYear = newTime->tm_yday;
    sleepClock ();
#endif
}

================== snip ========================

The above functions are designed to work with the newlib gettimeofday(), 
settimeofday(), localtime(), etc..

My clock has been running for several months without failure.  It has 
lost about 5 minutes, so I need to tweak the crystal capacitance...


What also may be of note is how I setup my power control during system 
initialization:

   PCONP = ((PCTIM0 | PCTIM1 | PCUART0 | PCUART1 | PCRTC |
          PCSPI1 | PCAD0) & ~PCONP_MASK);

Hope this helps,

TomW


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

David Hawkins wrote:

>Ok, so it seems I'm not the only one concerned with BGA
>prototyping or 'hobbiest' use of such devices.
>
>What kind of expense have people experienced for board
>manufacturing?
>
>I have used subcontractors to load boards with *LOTS* of
>BGA devices, and if I recall correctly, there was a $3k
>NRE charge to setup the reflow machines. We had a bad
>FPGA on one board, and that same company was able to
>remove and replace the BGA using a hot air gun. A
>pretty impressive feat - given that there were lots of
>FPGAs around the one they removed (it was a correlator
>board)
>
>http://www.ovro.caltech.edu/~dwh/correlator
>
>How about the guys reading this list that have played with
>homemade reflow machines based on quartz ovens - any attempts
>at loading BGA devices? Any success?
>
>  
>
I'd be intereested in that answer myself.  I've had excellent results 
using a quartz 1500W toaster oven + mylar stencils for the LPC2xxx 
processors and other fine pitch packages.  I'm not sure how successful I 
could be with BGA though.  From what I hear, placement of the device is 
very critical and difficult to do.  Aside from that, I suspect (nobody 
will confirm this) that a hot "gas" is needed to push heat under the 
carrier.

 From what I've been told, large scale operations use a hot nitrogen gas 
to reflow such boards.  I know of the hot air unit you are referring 
to.  AFAIK, those units are pushing 700..900F hot air flow.  
Temperatures not possible in a quartz (IR) oven.

TomW


>Dave
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

As willing as Philips in promoting LPC in this forum, I am wondering
if Philips be as willing discuss CRP and boot loader vulnerability
issues here?

--- In lpc2000@yahoogroups.com, "philips_marketing_usa"
<philips_marketing_usa@y...> wrote:

>
> The LPC3180 is the industry's first 90nm ARM9-based microcontroller. 
> ...
> http://www.standardics.philips.com/products/lpc3000/

Tom:

Thanks for the code!

Is it *necessary* to have the switching in place (as opposed to use leaving 
the lithium to power the RTC all the time)?  Just curious.

Instead of using the batt->res->diode what if I used a FET instead to 
provide switching between Vcc and Vbat?  This would also extend the battery 
life (since it's also powering external SRAM as well).  From Digikey a FET 
is the same price as a single diode, so that would actually be cheaper (?)

-- Sean

At 22:24 1/30/2006, you wrote:

>Sean wrote:
>
> >Hello everyone,
> >
> >I've got a bit of a strange problem with the RTC in my setup.  I have a
> >dedicated lithium battery going to the Vbat pin to power the RTC, and it
> >usually works fine, however periodically the clock changes to an invalid
> >value and stops running.  Usually this value is something like "Year:129
> >Month:00 Day:16 Hour:02 Min:09 Sec:08", and unless I reset the RTC to a
> >valid value it stops running.  This will usually happen after several hours
> >of Vcc absent (i.e. device powered off) or after a day or two running
> >constantly.  Nothing else is disrupted.  I have a 3.6V lithium running
> >through a diode which drops the voltage at the pin down to 3.165V when Vcc
> >present and to 3.232V when Vcc absent (implying that more current is drawn
> >when the micro is powered on??)
>
>Diode switching is needed to maintain the Vbat when Vdd (3.3v main) is
>absent and to switch over to the battery when Vdd disappears.  It sounds
>like you have that working?  It will take two diodes (1N4148A) and a
>resistor (560ohm) to do this properly.  Cathodes of both diodes go to
>Vbat line, anode of one diode goes to Vdd, anode of other diode is
>series with 560ohm to positive terminal of Lithium cell.
>
>This is half the solution, the hardware half.  I found that my clock
>would also "explode" on occasion and seemingly at random.  The solution
>I took was a bit more aggressive in the software.  Study my clock
>routines, especially awakenClock() and sleepClock().  Essentially, when
>the clock registers are not needed, they are "disconnected".

Use a BAT54C. Inside this component you have the 2 diodes (schotky ones 
that have only 0,3V dropout) with their cathodes connected.




Sean wrote:
> Tom:
>
> Thanks for the code!
>
> Is it *necessary* to have the switching in place (as opposed to use 
> leaving
> the lithium to power the RTC all the time)?  Just curious.
>
> Instead of using the batt->res->diode what if I used a FET instead to
> provide switching between Vcc and Vbat?  This would also extend the 
> battery
> life (since it's also powering external SRAM as well).  From Digikey a 
> FET
> is the same price as a single diode, so that would actually be cheaper (?)
>
> -- Sean
>
> At 22:24 1/30/2006, you wrote:
> >Sean wrote:
> >
> > >Hello everyone,
> > >
> > >I've got a bit of a strange problem with the RTC in my setup.  I have a
> > >dedicated lithium battery going to the Vbat pin to power the RTC, 
> and it
> > >usually works fine, however periodically the clock changes to an 
> invalid
> > >value and stops running.  Usually this value is something like 
> "Year:129
> > >Month:00 Day:16 Hour:02 Min:09 Sec:08", and unless I reset the RTC to a
> > >valid value it stops running.  This will usually happen after 
> several hours
> > >of Vcc absent (i.e. device powered off) or after a day or two running
> > >constantly.  Nothing else is disrupted.  I have a 3.6V lithium running
> > >through a diode which drops the voltage at the pin down to 3.165V 
> when Vcc
> > >present and to 3.232V when Vcc absent (implying that more current 
> is drawn
> > >when the micro is powered on??)
> >
> >Diode switching is needed to maintain the Vbat when Vdd (3.3v main) is
> >absent and to switch over to the battery when Vdd disappears.  It sounds
> >like you have that working?  It will take two diodes (1N4148A) and a
> >resistor (560ohm) to do this properly.  Cathodes of both diodes go to
> >Vbat line, anode of one diode goes to Vdd, anode of other diode is
> >series with 560ohm to positive terminal of Lithium cell.
> >
> >This is half the solution, the hardware half.  I found that my clock
> >would also "explode" on occasion and seemingly at random.  The solution
> >I took was a bit more aggressive in the software.  Study my clock
> >routines, especially awakenClock() and sleepClock().  Essentially, when
> >the clock registers are not needed, they are "disconnected".
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "lpc2000
>       <http://groups.yahoo.com/group/lpc2000>" on the web.
>        
>     *  To unsubscribe from this group, send an email to:
>        lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>



[Non-text portions of this message have been removed]

There's not enough market for microcontroller with embedded ethernet 
according to Philips. Who would like to have one at home, anyway? 

As an example of prototype unfriendly device is LM4921 audio codec 
from National coming in 20 bump micro smd package and it needs a 4-
layer pcb for less than 20 connections (some bumps are NC)

Atmel already have SAM7X with embedded ethernet or at least an 
evaluation board.

Jan



--- In lpc2000@yahoogroups.com, "slawcus" <slawcus@y...> wrote:
>
> --- In lpc2000@yahoogroups.com, David Hawkins <dwh@o...> wrote:
> >
> > 
> > But no ethernet :(
> >
> 
> Hehe, this device is targeting handheld market. Isn't nexperia 
90nm?
> Same core (no VPF). 
> 
> Hey... what about LPC2888? I didn't know that Philips is 
advertising
> products before the "real official annoucement"? I can see it in 
the
> new selection guide. 
> 
> 
http://www.standardics.philips.com/literature/other/microcontrollers/
pdf/selection.guide.pdf
>

> There's not enough market for microcontroller with embedded ethernet
> according to Philips. Who would like to have one at home, anyway?

If they produced the LPC23xx they might be found in many homes...

Until then the SAM7X is in the queue.


Joel

> Atmel already have SAM7X with embedded ethernet or at least an 
> evaluation board.

ok, but what you really benefit from the embedded MAC when you anyway 
will need external PHY connected to the chip?

I'll tell you from manufacturing point of view: almost nothing, no 
space saving, no price reduction, still two chip solution the price 
difference between MAC+PHY chip is just add to the SAM7S vs. SAM7X 
price.

So why do you need SAM7X instead SAM7S+ENC28J60 for instance? 
ENC28J60 nice and small footprint taking only *few* uC ports, ohh 
yeah well it takes 250mA while running at 10Mbit... so what? I don't 
intent to use it in battery powered equipment and the power adapter 
will source these 250mA without problem, and 10Mbit cover most of 
embedded applications these microcontrollers can be used for.

So just think again, why do you need microcontroller with only MAC 
embedded?

and of course it's pitty LPC3xxx comes in LFBGA-320 package, this 
means bye bye low cost development, hello expensive 8-10 layers, 
blind and burried vias protos :)

Best regards
Tsvetan
---
PCB prototypes for $26 at http://run.to/pcb 
(http://www.olimex.com/pcb)
PCB any volume assembly (http://www.olimex.com/pcb/protoa.html)
Development boards for ARM, AVR, PIC, MAXQ2000 and MSP430  
(http://www.olimex.com/dev)

The BAT54C's that I see ($0.12 qty 100) all have horrible forward voltage 
drops (some are as bad as 1V at 50mA current!) and I'll still need to drop 
the voltage further with a resistor, which drops the efficiency even 
further.  This device can also run off of a battery for main power, and 
this circuit needs to power SRAM, so the peak will be around 50mA.

Do you know of any BAT54C's that have a much lower voltage drop?  I see 
Philips has BAT54CW which is 420mV at 50mA current, that's the best I can 
find (yes, these are schottky).

The FET is the same price but will give me 0.2V drop without needing the 
extra resistor, and because this disconnects the lithium there is no drop 
at all when on main power.  Is there any reason this wouldn't work?

-- Sean

At 00:17 1/31/2006, you wrote:

>Use a BAT54C. Inside this component you have the 2 diodes (schotky ones
>that have only 0,3V dropout) with their cathodes connected.
>
>
>
>
>Sean wrote:
> > Tom:
> >
> > Thanks for the code!
> >
> > Is it *necessary* to have the switching in place (as opposed to use
> > leaving
> > the lithium to power the RTC all the time)?  Just curious.
> >
> > Instead of using the batt->res->diode what if I used a FET instead to
> > provide switching between Vcc and Vbat?  This would also extend the
> > battery
> > life (since it's also powering external SRAM as well).  From Digikey a
> > FET
> > is the same price as a single diode, so that would actually be cheaper (?)
> >
> > -- Sean
> >
> > At 22:24 1/30/2006, you wrote:
> > >Sean wrote:
> > >
> > > >Hello everyone,
> > > >
> > > >I've got a bit of a strange problem with the RTC in my setup.  I have a
> > > >dedicated lithium battery going to the Vbat pin to power the RTC,
> > and it
> > > >usually works fine, however periodically the clock changes to an
> > invalid
> > > >value and stops running.  Usually this value is something like
> > "Year:129
> > > >Month:00 Day:16 Hour:02 Min:09 Sec:08", and unless I reset the RTC to a
> > > >valid value it stops running.  This will usually happen after
> > several hours
> > > >of Vcc absent (i.e. device powered off) or after a day or two running
> > > >constantly.  Nothing else is disrupted.  I have a 3.6V lithium running
> > > >through a diode which drops the voltage at the pin down to 3.165V
> > when Vcc
> > > >present and to 3.232V when Vcc absent (implying that more current
> > is drawn
> > > >when the micro is powered on??)
> > >
> > >Diode switching is needed to maintain the Vbat when Vdd (3.3v main) is
> > >absent and to switch over to the battery when Vdd disappears.  It sounds
> > >like you have that working?  It will take two diodes (1N4148A) and a
> > >resistor (560ohm) to do this properly.  Cathodes of both diodes go to
> > >Vbat line, anode of one diode goes to Vdd, anode of other diode is
> > >series with 560ohm to positive terminal of Lithium cell.
> > >
> > >This is half the solution, the hardware half.  I found that my clock
> > >would also "explode" on occasion and seemingly at random.  The solution
> > >I took was a bit more aggressive in the software.  Study my clock
> > >routines, especially awakenClock() and sleepClock().  Essentially, when
> > >the clock registers are not needed, they are "disconnected".

tsvetanusunov <tusunov@...> schrieb am Tue, 31 Jan 2006 09:42:53 -0000:

>> Atmel already have SAM7X with embedded ethernet or at least an
>> evaluation board.
>
> ok, but what you really benefit from the embedded MAC when you anyway
> will need external PHY connected to the chip?
>
> I'll tell you from manufacturing point of view: almost nothing, no
> space saving, no price reduction, still two chip solution the price
> difference between MAC+PHY chip is just add to the SAM7S vs. SAM7X
> price.

But from the programming point an embedded MAC is easier and faster unless
you use an external MAC+Phy which completely is memory mapped.

I wonder, is there no connector with integrated Phy ?


> So why do you need SAM7X instead SAM7S+ENC28J60 for instance?
> ENC28J60 nice and small footprint taking only *few* uC ports, ohh
> yeah well it takes 250mA while running at 10Mbit... so what? I don't

Your power-regulators on the board must be layed out for this too.

> intent to use it in battery powered equipment and the power adapter
> will source these 250mA without problem, and 10Mbit cover most of
> embedded applications these microcontrollers can be used for.

What about PoE ? How much can this drive ?

> So just think again, why do you need microcontroller with only MAC
> embedded?

BTW: Freescale should present soon a Coldfire with MAC+Phy (as the NE64).


-- 
42Bastian Schick

Jan

> There's not enough market for microcontroller with embedded ethernet
> according to Philips. Who would like to have one at home, anyway?

I wonder whom Philips has asked.
Our sales-people see at least in 80% of the projects embedded ethernet.
Many of those would prefer single-chip solutions.

-- 
42Bastian Schick

> ok, but what you really benefit from the embedded MAC when you anyway
> will need external PHY connected to the chip?

Sure, I/O bandwith and PHY choice.  Having a built-in PHY locks your part
into a niche, while limiting potential markets.

The Dallas DS80C390/400 series took the separate PHY approach, they did
pretty good.  They aren't even Flash based.

> I'll tell you from manufacturing point of view: almost nothing, no
> space saving, no price reduction, still two chip solution the price
> difference between MAC+PHY chip is just add to the SAM7S vs. SAM7X
> price.

The Infineon 10/100 ADM7001 PHY is ~$0.86 each in qty of 2500.  Cheapest
I've seen.  My guess is the LPC2300 doesn't implement a built-in PHY.

> So why do you need SAM7X instead SAM7S+ENC28J60 for instance?
> ENC28J60 nice and small footprint taking only *few* uC ports, ohh
> yeah well it takes 250mA while running at 10Mbit... so what? I don't
> intent to use it in battery powered equipment and the power adapter
> will source these 250mA without problem, and 10Mbit cover most of
> embedded applications these microcontrollers can be used for.

250ma for Ethernet on a cost conscience product is a tough sell, no matter
how you slice it.

> and of course it's pitty LPC3xxx comes in LFBGA-320 package, this
> means bye bye low cost development, hello expensive 8-10 layers,
> blind and burried vias protos :)

I understand TQFP-100 will be available first.


Joel

> The LPC3180 is the first ARM9 MCU to offer USB On-The-Go
> (OTG) integrated with full host capability for direct connection to
> PDAs, smart-card readers, and printers.

Not quiet right: Atmel has also one.


-- 
42Bastian Schick

philips_marketing_usa <philips_marketing_usa@...> schrieb am Mon, 30

> With speeds of up to 200 MHz, the LPC3180 is ideal for a wide range
> of high-precision applications such as point-of-sale (POS)
> equipment, medical and industrial devices, global positioning
> systems (GPS), and robotics.

For targeting robotics, the chip lacks: CAN and Ethernet.

For POS it lacks LCD support.

Just my 2cents
-- 
42Bastian Schick

----- Original Message ----- 

From: "42Bastian Schick" <bastian42@...>
To: <lpc2000@yahoogroups.com>
Sent: Tuesday, January 31, 2006 10:28 AM
Subject: Re: [lpc2000] Philips LPC3180 - ARM9 MCU Press Release


> philips_marketing_usa <philips_marketing_usa@...> schrieb am Mon, 30
>
>> With speeds of up to 200 MHz, the LPC3180 is ideal for a wide range
>> of high-precision applications such as point-of-sale (POS)
>> equipment, medical and industrial devices, global positioning
>> systems (GPS), and robotics.
>
> For targeting robotics, the chip lacks: CAN and Ethernet.

Lack of CAN is a pity, otherwise it would be ideal for a company I used to 
work for.

Leon

> -----Original Message-----
> From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf
> Of Tom Walsh
> Sent: Monday, January 30, 2006 9:31 PM
> To: lpc2000@yahoogroups.com
> Subject: Re: [lpc2000] Philips LPC3180 - BGA loading Qs
> I'd be intereested in that answer myself.  I've had excellent results
> using a quartz 1500W toaster oven + mylar stencils for the LPC2xxx
> processors and other fine pitch packages.  I'm not sure how successful I
> could be with BGA though.  From what I hear, placement of the device is
> very critical and difficult to do.  Aside from that, I suspect (nobody
> will confirm this) that a hot "gas" is needed to push heat under the
> carrier.
> 
>  From what I've been told, large scale operations use a hot nitrogen gas
> to reflow such boards.  I know of the hot air unit you are referring
> to.  AFAIK, those units are pushing 700..900F hot air flow.
> Temperatures not possible in a quartz (IR) oven.

See full text below..

I use a hot air re-work machine and it does a great job.  The great things
about BGA's are they are self centering.  They can be off pad up to 60% and
when the balls flow they will pull the package into proper alignment.   For
a big production run you want to go to a place that does IR re-flow, but for
the qnt we do here our hot air machine work nicely.  It's not all that
hard!!!

Greg Deuerling
Fermi National Accelerator Laboratory
Feynman Computing Center, Room 370, MS 368
P.O.Box 500 Batavia, IL 60510
(630)840-4629     FAX  (630)840-8208
Electronic Systems Engineering Group
Work: egads@...

> -----Original Message-----
> From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf
> Of Tom Walsh
> Sent: Monday, January 30, 2006 9:31 PM
> To: lpc2000@yahoogroups.com
> Subject: Re: [lpc2000] Philips LPC3180 - BGA loading Qs
> 
> David Hawkins wrote:
> 
> >Ok, so it seems I'm not the only one concerned with BGA
> >prototyping or 'hobbiest' use of such devices.
> >
> >What kind of expense have people experienced for board
> >manufacturing?
> >
> >I have used subcontractors to load boards with *LOTS* of
> >BGA devices, and if I recall correctly, there was a $3k
> >NRE charge to setup the reflow machines. We had a bad
> >FPGA on one board, and that same company was able to
> >remove and replace the BGA using a hot air gun. A
> >pretty impressive feat - given that there were lots of
> >FPGAs around the one they removed (it was a correlator
> >board)
> >
> >http://www.ovro.caltech.edu/~dwh/correlator
> >
> >How about the guys reading this list that have played with
> >homemade reflow machines based on quartz ovens - any attempts
> >at loading BGA devices? Any success?
> >
> >
> >
> I'd be intereested in that answer myself.  I've had excellent results
> using a quartz 1500W toaster oven + mylar stencils for the LPC2xxx
> processors and other fine pitch packages.  I'm not sure how successful I
> could be with BGA though.  From what I hear, placement of the device is
> very critical and difficult to do.  Aside from that, I suspect (nobody
> will confirm this) that a hot "gas" is needed to push heat under the
> carrier.
> 
>  From what I've been told, large scale operations use a hot nitrogen gas
> to reflow such boards.  I know of the hot air unit you are referring
> to.  AFAIK, those units are pushing 700..900F hot air flow.
> Temperatures not possible in a quartz (IR) oven.
> 
> TomW
> 
> 
> >Dave
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> 
> 
> --
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net, http://cyberiansoftware.com
> "Windows? No thanks, I have work to do..."
> ----------------------------------------------------
> 
> 
> 
> 
> 
> Yahoo! Groups Links
> 
> 
> 
> 
>

--- In lpc2000@yahoogroups.com, Greg Deuerling <egads@f...> wrote:
> I use a hot air re-work machine and it does a great job.  The 
> great things about BGA's are they are self centering.  They can be
> off pad up to 60% and when the balls flow they will pull the 
> package into proper alignment.   For a big production run you want
> to go to a place that does IR re-flow, but for the qnt we do here 
> our hot air machine work nicely.  It's not all that
> hard!!!

We used hot air blower (600W SMT rework/desodlering tools) to solder 
BGA on prototype boards but could only get 20-30% successful rate.
Difficult part would be chip blown completely out of PCB footprint.
Self-centering does not always pull the chip back to proper alignment
also.   Any special skill/experience to share??
Regards

----- Original Message ----- 

From: "unity0724" <unity0724@...>
To: <lpc2000@yahoogroups.com>
Sent: Tuesday, January 31, 2006 1:20 PM
Subject: [lpc2000] Re: Philips LPC3180 - BGA loading Qs


> --- In lpc2000@yahoogroups.com, Greg Deuerling <egads@f...> wrote:
>> I use a hot air re-work machine and it does a great job.  The
>> great things about BGA's are they are self centering.  They can be
>> off pad up to 60% and when the balls flow they will pull the
>> package into proper alignment.   For a big production run you want
>> to go to a place that does IR re-flow, but for the qnt we do here
>> our hot air machine work nicely.  It's not all that
>> hard!!!
>
> We used hot air blower (600W SMT rework/desodlering tools) to solder
> BGA on prototype boards but could only get 20-30% successful rate.
> Difficult part would be chip blown completely out of PCB footprint.
> Self-centering does not always pull the chip back to proper alignment
> also.   Any special skill/experience to share??

An electrically heated skillet is supposed to be very good, although I 
haven't heard of anyone using one with BGAs. It does work OK with QFN 
packages, which are similar. I've bought a cheap toaster oven which I was 
intending to use with a controller, but the skillet is supposed to be 
better.

Leon

From the Philips Datasheet

Price : 0,08 / 100 pcs @ Digikey
240mV @ 0,1mA (that's far more than the RTC uses)

With do you need this resistor ? And even if you need it, let's see:
Using a 1K resistor, and a RTC current of 20uA gives you a dropout of  
20mV ....

I use this a lot and I'm sure it works very well.

But I can't see how do you want to use a fet in this application.

Mauricio




Sean wrote:
> The BAT54C's that I see ($0.12 qty 100) all have horrible forward voltage
> drops (some are as bad as 1V at 50mA current!) and I'll still need to 
> drop
> the voltage further with a resistor, which drops the efficiency even
> further.  This device can also run off of a battery for main power, and
> this circuit needs to power SRAM, so the peak will be around 50mA.
>
> Do you know of any BAT54C's that have a much lower voltage drop?  I see
> Philips has BAT54CW which is 420mV at 50mA current, that's the best I can
> find (yes, these are schottky).
>
> The FET is the same price but will give me 0.2V drop without needing the
> extra resistor, and because this disconnects the lithium there is no drop
> at all when on main power.  Is there any reason this wouldn't work?
>
> -- Sean
>
> At 00:17 1/31/2006, you wrote:
> >Use a BAT54C. Inside this component you have the 2 diodes (schotky ones
> >that have only 0,3V dropout) with their cathodes connected.
> >
> >
> >
> >
> >Sean wrote:
> > > Tom:
> > >
> > > Thanks for the code!
> > >
> > > Is it *necessary* to have the switching in place (as opposed to use
> > > leaving
> > > the lithium to power the RTC all the time)?  Just curious.
> > >
> > > Instead of using the batt->res->diode what if I used a FET instead to
> > > provide switching between Vcc and Vbat?  This would also extend the
> > > battery
> > > life (since it's also powering external SRAM as well).  From Digikey a
> > > FET
> > > is the same price as a single diode, so that would actually be 
> cheaper (?)
> > >
> > > -- Sean
> > >
> > > At 22:24 1/30/2006, you wrote:
> > > >Sean wrote:
> > > >
> > > > >Hello everyone,
> > > > >
> > > > >I've got a bit of a strange problem with the RTC in my setup.  
> I have a
> > > > >dedicated lithium battery going to the Vbat pin to power the RTC,
> > > and it
> > > > >usually works fine, however periodically the clock changes to an
> > > invalid
> > > > >value and stops running.  Usually this value is something like
> > > "Year:129
> > > > >Month:00 Day:16 Hour:02 Min:09 Sec:08", and unless I reset the 
> RTC to a
> > > > >valid value it stops running.  This will usually happen after
> > > several hours
> > > > >of Vcc absent (i.e. device powered off) or after a day or two 
> running
> > > > >constantly.  Nothing else is disrupted.  I have a 3.6V lithium 
> running
> > > > >through a diode which drops the voltage at the pin down to 3.165V
> > > when Vcc
> > > > >present and to 3.232V when Vcc absent (implying that more current
> > > is drawn
> > > > >when the micro is powered on??)
> > > >
> > > >Diode switching is needed to maintain the Vbat when Vdd (3.3v 
> main) is
> > > >absent and to switch over to the battery when Vdd disappears.  It 
> sounds
> > > >like you have that working?  It will take two diodes (1N4148A) and a
> > > >resistor (560ohm) to do this properly.  Cathodes of both diodes go to
> > > >Vbat line, anode of one diode goes to Vdd, anode of other diode is
> > > >series with 560ohm to positive terminal of Lithium cell.
> > > >
> > > >This is half the solution, the hardware half.  I found that my clock
> > > >would also "explode" on occasion and seemingly at random.  The 
> solution
> > > >I took was a bit more aggressive in the software.  Study my clock
> > > >routines, especially awakenClock() and sleepClock().  
> Essentially, when
> > > >the clock registers are not needed, they are "disconnected".
>
>
>
> SPONSORED LINKS
> Microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=mfaAujKZXA2Z_vxre9sGnQ> 
> 	Microprocessor 
> <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=9jjd2D3GOLIESVQssLmLsA> 
> 	Intel microprocessors 
> <http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=OMnZuqMZX95mgutt4B-tDw> 
>
> Pic microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=Malspbd0T4Rq3M4Q0nHrfw> 
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "lpc2000
>       <http://groups.yahoo.com/group/lpc2000>" on the web.
>        
>     *  To unsubscribe from this group, send an email to:
>        lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>



[Non-text portions of this message have been removed]

> Of unity0724
> Sent: Tuesday, January 31, 2006 7:21 AM
> To: lpc2000@yahoogroups.com
> Subject: [lpc2000] Re: Philips LPC3180 - BGA loading Qs
> 
> --- In lpc2000@yahoogroups.com, Greg Deuerling <egads@f...> wrote:
> > I use a hot air re-work machine and it does a great job.  The
> > great things about BGA's are they are self centering.  They can be
> > off pad up to 60% and when the balls flow they will pull the
> > package into proper alignment.   For a big production run you want
> > to go to a place that does IR re-flow, but for the qnt we do here
> > our hot air machine work nicely.  It's not all that
> > hard!!!
> 
> We used hot air blower (600W SMT rework/desodlering tools) to solder
> BGA on prototype boards but could only get 20-30% successful rate.
> Difficult part would be chip blown completely out of PCB footprint.
> Self-centering does not always pull the chip back to proper alignment
> also.   Any special skill/experience to share??
> Regards

Special skill's?  Yes, lots of practice and the temperature and timing have
to be closely controlled.  I recently mounted 40 672pin PBGA's and had a
100% success rate.  Altera and Xilinx will usually give you 10 or so dummy
packages to practice on before you try to place that $1000 FPGA the 1st time
:)

Our system heats the PCB from the top and the bottom board.  We use a three
step process:

1) Pre-heat the PCB to 200C for a minute or so.

2) Next soak the PCB to just 20-30C under where the solder starts to flow
for 2 minutes.  Most 10 to 12 layer PCB's I use 230C.

3) Next hit the PCB with enough heat to flow the solder for 10-30 seconds.
Most 10 to 12 layer PCB's I use 300C for 10 seconds.  This is the real
trick, you only want to flow the solder for a very short time or the package
will lay down too flat and short out balls.

The air speed on the above steps is pretty slow.  I've had 0402 cap's that
were not held down by anything but solder paste and they did not blow away.

We use a Metcal/OKI BGA-3500 series re-work station.  Metcal does not make
the BGA-3500 any more, but I think the APR-5000 replaced it.

See: http://www.okinternational.com/product_advanced



Greg Deuerling
Fermi National Accelerator Laboratory
Feynman Computing Center, Room 370, MS 368
P.O.Box 500 Batavia, IL 60510
(630)840-4629     FAX  (630)840-8208
Electronic Systems Engineering Group
Work: egads@...

Mauricio Scaff wrote:

> From the Philips Datasheet
>
>Price : 0,08 / 100 pcs @ Digikey
>240mV @ 0,1mA (that's far more than the RTC uses)
>
>With do you need this resistor ? And even if you need it, let's see:
>Using a 1K resistor, and a RTC current of 20uA gives you a dropout of  
>20mV ....
>
>I use this a lot and I'm sure it works very well.
>
>  
>
If you are doing a commercial design which has to under Underwriters 
Labratories testing,  They require that you need the current limiting 
resistor in the event that the diode shorts the battery won't rupture 
due to excessive current.

TomW


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Hi Joel and Co.

Just to confirm - the SAM7X consumes 200mA when running at 50MHz 
with 100M LAN (Micrel). Layout is very simple indeed - footpint 
adequately small for more embedded stuff. See example at 
http://www.altec-ag.ch/ger/Produkte/DOWNLOADS/DS_AL6000S_V3.pdf

Complete port time of a system to ATMEL took 9 days from start (no 
knowledge) to completion incl. serial, MAC, ext. PHY and FLASH file 
system - where the code is running from internal FLASH (very simple 
to use is the FLASH.. [easier than LPC2000, but I still love the 
LPC - would be great to finally get Ethernet]) downloading with 
loader utility (similar to LPC2000 utility). Maybe 2 days lost due 
to a hardware issue (silly mistake so won't go into details..)

The ENC28J60 gives me nightmares when I see the 250mA at 10M - then 
it needs a processor as well!! I would also like to see a design 
working with it; it is over a year since first samples were promised 
but it still doesn't seem to be really ready (or do you know more?).

ATMEL will be in full production from March and may well make a big 
splash! Then watch out for the new Coldfire with MAC + PHY which 
will follow!!
Internal MAC is neat, whereas the external PHY is not a big deal 
since they are basically compatible and quite small.

For internal MAC+PHY I have been using the MC9S12NE64 for a year now 
with good success. Memory is quite tight but it is still surprising 
what can be packed into it (helps to have a good compiler).

One point to note is that MAC+PHY using one clock (quarz) forces 
25MHz (depending on PLL flexibility), which is not very suitable for 
generating fast serial speeds. So there can also be advantages in 
keepimg the separate...

A couple of demos always online at www.mjbc.ch

Cheers

Mark Butcher
www.mjbc.ch


--- In lpc2000@yahoogroups.com, "Joel Winarske" <joelw@i...> wrote:
>
> > ok, but what you really benefit from the embedded MAC when you 
anyway
> > will need external PHY connected to the chip?
> 
> Sure, I/O bandwith and PHY choice.  Having a built-in PHY locks 
your part
> into a niche, while limiting potential markets.
> 
> The Dallas DS80C390/400 series took the separate PHY approach, 
they did
> pretty good.  They aren't even Flash based.
> 
> > I'll tell you from manufacturing point of view: almost nothing, 
no
> > space saving, no price reduction, still two chip solution the 
price
> > difference between MAC+PHY chip is just add to the SAM7S vs. 
SAM7X
> > price.
> 
> The Infineon 10/100 ADM7001 PHY is ~$0.86 each in qty of 2500.  
Cheapest
> I've seen.  My guess is the LPC2300 doesn't implement a built-in 
PHY.
> 
> > So why do you need SAM7X instead SAM7S+ENC28J60 for instance?
> > ENC28J60 nice and small footprint taking only *few* uC ports, ohh
> > yeah well it takes 250mA while running at 10Mbit... so what? I 
don't
> > intent to use it in battery powered equipment and the power 
adapter
> > will source these 250mA without problem, and 10Mbit cover most of
> > embedded applications these microcontrollers can be used for.
> 
> 250ma for Ethernet on a cost conscience product is a tough sell, 
no matter

> how you slice it.
> 
> > and of course it's pitty LPC3xxx comes in LFBGA-320 package, this
> > means bye bye low cost development, hello expensive 8-10 layers,
> > blind and burried vias protos :)
> 
> I understand TQFP-100 will be available first.
> 
> 
> Joel
>

Hi, Thanks,
Tool used here is a handheld Leister CH-6056 hot-air blower/
desoldering tools (~US$400 cheap tool)  This tool is meant for
removing SMT/QFP parts and is NOT a proper BGA rework tool.  
Will try your way of pre-heating PCB and make sure solder balls do
not get "sandwiched" too much, also reducing that air-flow rate.
Regards

--- In lpc2000@yahoogroups.com, Greg Deuerling <egads@...> wrote:
>
> 
> > Of unity0724
> > Sent: Tuesday, January 31, 2006 7:21 AM
> > To: lpc2000@yahoogroups.com
> > Subject: [lpc2000] Re: Philips LPC3180 - BGA loading Qs
> > 
> > --- In lpc2000@yahoogroups.com, Greg Deuerling <egads@f...> 
wrote:
> > > I use a hot air re-work machine and it does a great job.  The
> > > great things about BGA's are they are self centering.  They 
can be
> > > off pad up to 60% and when the balls flow they will pull the
> > > package into proper alignment.   For a big production run you 
want
> > > to go to a place that does IR re-flow, but for the qnt we do 
here
> > > our hot air machine work nicely.  It's not all that
> > > hard!!!
> > 
> > We used hot air blower (600W SMT rework/desodlering tools) to 
solder
> > BGA on prototype boards but could only get 20-30% successful 
rate.
> > Difficult part would be chip blown completely out of PCB 
footprint.
> > Self-centering does not always pull the chip back to proper 
alignment
> > also.   Any special skill/experience to share??
> > Regards
> 
> Special skill's?  Yes, lots of practice and the temperature and 
timing have
> to be closely controlled.  I recently mounted 40 672pin PBGA's and 
had a
> 100% success rate.  Altera and Xilinx will usually give you 10 or 
so dummy
> packages to practice on before you try to place that $1000 FPGA 
the 1st time
> :)
> 
> Our system heats the PCB from the top and the bottom board.  We 
use a three
> step process:
> 
> 1) Pre-heat the PCB to 200C for a minute or so.
> 
> 2) Next soak the PCB to just 20-30C under where the solder starts 
to flow
> for 2 minutes.  Most 10 to 12 layer PCB's I use 230C.
> 
> 3) Next hit the PCB with enough heat to flow the solder for 10-30 
seconds.
> Most 10 to 12 layer PCB's I use 300C for 10 seconds.  This is the 
real
> trick, you only want to flow the solder for a very short time or 
the package
> will lay down too flat and short out balls.
> 
> The air speed on the above steps is pretty slow.  I've had 0402 
cap's that
> were not held down by anything but solder paste and they did not 
blow away.
> 
> We use a Metcal/OKI BGA-3500 series re-work station.  Metcal does 
not make

> the BGA-3500 any more, but I think the APR-5000 replaced it.
> 
> See: http://www.okinternational.com/product_advanced
> 
> 
> 
> Greg Deuerling
> Fermi National Accelerator Laboratory
> Feynman Computing Center, Room 370, MS 368
> P.O.Box 500 Batavia, IL 60510
> (630)840-4629     FAX  (630)840-8208
> Electronic Systems Engineering Group
> Work: egads@...
>

Oven/Skillet might work.  But foresee hard to control timing and
temperature.  Hee, You seem like having some "weird" ideas as me of
using home appliances for prototyping...  
- fridge/oven for reliability/environmental testing
- dish washer for PCB washing.   (I'm using a tank with an aquarium
  pump for washing water-soluble flux/solder, works fine)
- Oven for removing moisture on PCB before soldering

Pls eMail me your procedure when you can get your BGA mounting
successful and thanks.   Most chips will be on BGA in future... :(
Regards

--- In lpc2000@yahoogroups.com, "Leon Heller" <leon.heller@...> 
wrote:
>
> ----- Original Message ----- 
> From: "unity0724" <unity0724@...>
> To: <lpc2000@yahoogroups.com>
> Sent: Tuesday, January 31, 2006 1:20 PM
> Subject: [lpc2000] Re: Philips LPC3180 - BGA loading Qs
> 
> 
> > --- In lpc2000@yahoogroups.com, Greg Deuerling <egads@f...> 
wrote:
> >> I use a hot air re-work machine and it does a great job.  The
> >> great things about BGA's are they are self centering.  They can 
be
> >> off pad up to 60% and when the balls flow they will pull the
> >> package into proper alignment.   For a big production run you 
want
> >> to go to a place that does IR re-flow, but for the qnt we do 
here
> >> our hot air machine work nicely.  It's not all that
> >> hard!!!
> >
> > We used hot air blower (600W SMT rework/desodlering tools) to 
solder
> > BGA on prototype boards but could only get 20-30% successful 
rate.
> > Difficult part would be chip blown completely out of PCB 
footprint.
> > Self-centering does not always pull the chip back to proper 
alignment
> > also.   Any special skill/experience to share??
> 
> An electrically heated skillet is supposed to be very good, 
although I 
> haven't heard of anyone using one with BGAs. It does work OK with 
QFN 
> packages, which are similar. I've bought a cheap toaster oven 
which I was 
> intending to use with a controller, but the skillet is supposed to 
be 

> better.
> 
> Leon
>

Just as a follow up, in case someone runs into this problem:

The answer to my question is yes, apparently you need to have the Vcc 
switching in place to run the RTCK off of Vcc when Vcc is present, and Vbat 
when Vcc is not present.  If Vbat is used to power the RTC when Vcc is 
present then the clock will do some strange things.

-- Sean

At 22:51 1/30/2006, you wrote:

>Tom:
>
>Thanks for the code!
>
>Is it *necessary* to have the switching in place (as opposed to use leaving
>the lithium to power the RTC all the time)?  Just curious.
>
>-- Sean
>
>At 22:24 1/30/2006, you wrote:
> >Sean wrote:
> >
> > >Hello everyone,
> > >
> > >I've got a bit of a strange problem with the RTC in my setup.  I have a
> > >dedicated lithium battery going to the Vbat pin to power the RTC, and it
> > >usually works fine, however periodically the clock changes to an invalid
> > >value and stops running.  Usually this value is something like "Year:129
> > >Month:00 Day:16 Hour:02 Min:09 Sec:08", and unless I reset the RTC to a
> > >valid value it stops running.  This will usually happen after several 
> hours
> > >of Vcc absent (i.e. device powered off) or after a day or two running
> > >constantly.  Nothing else is disrupted.  I have a 3.6V lithium running
> > >through a diode which drops the voltage at the pin down to 3.165V when Vcc
> > >present and to 3.232V when Vcc absent (implying that more current is drawn
> > >when the micro is powered on??)
> >
> >Diode switching is needed to maintain the Vbat when Vdd (3.3v main) is
> >absent and to switch over to the battery when Vdd disappears.  It sounds
> >like you have that working?  It will take two diodes (1N4148A) and a
> >resistor (560ohm) to do this properly.  Cathodes of both diodes go to
> >Vbat line, anode of one diode goes to Vdd, anode of other diode is
> >series with 560ohm to positive terminal of Lithium cell.
> >
> >This is half the solution, the hardware half.  I found that my clock
> >would also "explode" on occasion and seemingly at random.  The solution
> >I took was a bit more aggressive in the software.  Study my clock
> >routines, especially awakenClock() and sleepClock().  Essentially, when
> >the clock registers are not needed, they are "disconnected".
>
>
>
>----------
>YAHOO! GROUPS LINKS
>
>    *  Visit your group "<http://groups.yahoo.com/group/lpc2000>lpc2000" 
> on the web.
>    *
>    *  To unsubscribe from this group, send an email to:
>    * 
> <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>lpc2000-unsubscribe@yahoogroups.com 
>
>    *
>    *  Your use of Yahoo! Groups is subject to the 
> <http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service.
>
>
>----------

Chaps,

I'd like to pick your collective brains.

I'm using a 2194 that communicates with lots of other devices using all 
four CAN ports and both UARTs. One UART communicates with an AVR which 
does some real time stuff and passes data to the ARM, and the other 
talks to a PC. I need to add another UART, which means I need to somehow 
free up the serial port that talks to the AVR and come up with an 
alternative way of getting the two devices to communicate.

I would do it as a parallel interface using P1 if it wasn't for the 
ridiculous pinout of that port! The next best way seems like it might be 
SPI (as I'm not using the SPI port). I would almost definitely have to 
go to four layer if I did it this way, and I don't want to do that.

Would I be mad to try this? It strikes me from reading about various SPI 
issues on here I might be asking for trouble. I need to get information 
out of the AVR and into the ARM as rapidly as possible and also get 
configuration data from the ARM to the AVR, so I'm assuming I would have 
to change which was master and slave from time to time?

I would add I've done lots of SPI in the past, but always with the micro 
being the master and talking to D/As, EEPROMs etc. I'm wondering how 
difficult it is to get a micro running as a slave, and in particular the 
2194, as my perception is the LPC family has some SPI issues. (This may 
well be a false impression of course.)

I have thought about using an SPI UART, but I think only Maxim do those 
and I refuse to use Maxim stuff!

Many thanks,

Rob

----- Original Message ----- 

From: "Robert Wood" <robert.wood@...>
To: <lpc2000@yahoogroups.com>
Sent: Monday, March 06, 2006 8:06 PM
Subject: [lpc2000] SPI comms with another micro


> Chaps,
>
> I'd like to pick your collective brains.
>
> I'm using a 2194 that communicates with lots of other devices using all
> four CAN ports and both UARTs. One UART communicates with an AVR which
> does some real time stuff and passes data to the ARM, and the other
> talks to a PC. I need to add another UART, which means I need to somehow
> free up the serial port that talks to the AVR and come up with an
> alternative way of getting the two devices to communicate.
>
> I would do it as a parallel interface using P1 if it wasn't for the
> ridiculous pinout of that port! The next best way seems like it might be
> SPI (as I'm not using the SPI port). I would almost definitely have to
> go to four layer if I did it this way, and I don't want to do that.
>
> Would I be mad to try this? It strikes me from reading about various SPI
> issues on here I might be asking for trouble. I need to get information
> out of the AVR and into the ARM as rapidly as possible and also get
> configuration data from the ARM to the AVR, so I'm assuming I would have
> to change which was master and slave from time to time?
>
> I would add I've done lots of SPI in the past, but always with the micro
> being the master and talking to D/As, EEPROMs etc. I'm wondering how
> difficult it is to get a micro running as a slave, and in particular the
> 2194, as my perception is the LPC family has some SPI issues. (This may
> well be a false impression of course.)
>
> I have thought about using an SPI UART, but I think only Maxim do those
> and I refuse to use Maxim stuff!

I've used the Maxim chip (interfaced to a PIC) and it works OK. I've also 
used 2313 AVRs interfaced to a PIC (using bit-banged SPI on the AVRs) when I 
needed several UARTS. The latter also worked very well.

Leon 

---
[This E-mail has been scanned for viruses but it is your responsibility 
to maintain up to date anti virus software on the device that you are
currently using to read this email. ]

Hi Leon,

 >> I've used the Maxim chip (interfaced to a PIC) and it works OK. I've 
also used 2313 AVRs interfaced to a PIC (using bit-banged SPI on the 
AVRs) when I needed several UARTS. The latter also worked very well. <<

I have no issues with Maxim stuff working, just their dire record in 
actually having stuff available!

I've just found Philips do an I2C/SPI interface UART. :-) No idea how 
much it is. Might find it's cheaper to go four layer and do it parallel! 
;-)

Cheers,

Rob

Robert Wood wrote:

>Hi Leon,
>
> >> I've used the Maxim chip (interfaced to a PIC) and it works OK. I've 
>also used 2313 AVRs interfaced to a PIC (using bit-banged SPI on the 
>AVRs) when I needed several UARTS. The latter also worked very well. <<
>
>I have no issues with Maxim stuff working, just their dire record in 
>actually having stuff available!
>
>  
>
BTDT, Maxim can be a pain with finding something nice and then find out 
it is not in production.  Seems they have a rich portfolio of ideas and 
wait until somebody orders a few thousand before the actually make the 
stuff..

That being said, I did incorporate the MAX3100 SPI UART into my design.  
There are three of them on the board.  I did this after looking at the 
inventory at DigiKey.  They seem to be selling significant quantities of 
them to others, so I bit.

If you do look to an SPI UART, I would recommend that one to you.  It 
even is capable of 9bit communication, although it is not automatic, you 
have to set the ninth bit but it is a 16bit word that is sent to the 
UART for each transaction.

TomW



-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Robert Wood wrote:
> Chaps,
> 
> I'd like to pick your collective brains.
> 
> I'm using a 2194 that communicates with lots of other devices using all 
> four CAN ports and both UARTs. One UART communicates with an AVR which 
> does some real time stuff and passes data to the ARM, and the other 
> talks to a PC. I need to add another UART, which means I need to somehow 
> free up the serial port that talks to the AVR and come up with an 
> alternative way of getting the two devices to communicate.
> 
>
What is the max required uart bit rate?

Don

I am using *ehem* MAX3100 to talk with a GPS module from my LPC2138's 
SPI0 port and I have no issues at all. I don't have the need for 
control lines (though MAX3100 supports them), but I do need a non-
polling mechanism, so I'm using MAX3100's IRQ line into one of the 
LPC's IRQ. I am performing fully-bidirectional communications (mostly 
inbound) and everything works fine. In my scheme, LPC is the SPI 
master. The software part was tricky, although I experimented no 
issues with LPC2138's SPI implementation.

Philips just released (or is about to release) an I2C/SPI UART, 
SC16IS750IPW+112. I got one via the Philips sample program. I haven't 
tested it, nor checked its availability. Looks promising. Here's a 
link:

http://www.semiconductors.philips.com/pip/SC16IS750.html

Guille

--- In lpc2000@yahoogroups.com, Robert Wood <robert.wood@...> wrote:
>
> Chaps,
> 
> I'd like to pick your collective brains.
> 
> I'm using a 2194 that communicates with lots of other devices using 
all 
> four CAN ports and both UARTs. One UART communicates with an AVR 
which 
> does some real time stuff and passes data to the ARM, and the other 
> talks to a PC. I need to add another UART, which means I need to 
somehow 
> free up the serial port that talks to the AVR and come up with an 
> alternative way of getting the two devices to communicate.
> 
> I would do it as a parallel interface using P1 if it wasn't for the 
> ridiculous pinout of that port! The next best way seems like it 
might be 
> SPI (as I'm not using the SPI port). I would almost definitely have 
to 
> go to four layer if I did it this way, and I don't want to do that.
> 
> Would I be mad to try this? It strikes me from reading about 
various SPI 
> issues on here I might be asking for trouble. I need to get 
information 
> out of the AVR and into the ARM as rapidly as possible and also get 
> configuration data from the ARM to the AVR, so I'm assuming I would 
have 
> to change which was master and slave from time to time?
> 
> I would add I've done lots of SPI in the past, but always with the 
micro 
> being the master and talking to D/As, EEPROMs etc. I'm wondering 
how 
> difficult it is to get a micro running as a slave, and in 
particular the 
> 2194, as my perception is the LPC family has some SPI issues. (This 
may 
> well be a false impression of course.)
> 
> I have thought about using an SPI UART, but I think only Maxim do 
those 

> and I refuse to use Maxim stuff!
> 
> Many thanks,
> 
> Rob
>

>> What is the max required uart bit rate? <<

For the third UART I could get away 9600baud.

Robert Wood wrote:
>  >> What is the max required uart bit rate? <<
> 
> For the third UART I could get away 9600baud.
> 

YMMV, but the MAX3100 style of device always looks like a CPU that I can't 
access & so I end up using a CPU that I can access instead...  Less cost, better 
availability, more package options. Have to write handler code either way.

That is one extra UART on a similar sized chip & at less cost. The beauty is 
that now you have a dedicated protocol handler which has on-board FIFO's,  and 
so the interrupt loading is less on the main CPU. Not to mention putting the 
main system to sleep & just running the slave CPU to listen for a wakeup on the 
network.

There is code floating about that will allow you to bit bash serial ports on an 
AVR very efficiently, this can provide a bunch of extra lower speed ports for 
interface to GPS & similar. Effectively the CPU treats the UART channels as a 
bunch of parallel shift registers & clocks the parallel byte in and out of the 
device at a multiple of the UART bit rate.

Cheers

Don

>    From: Don Ingram <don@...>
> 
> Robert Wood wrote:
> >  >> What is the max required uart bit rate? <<
> > 
> > For the third UART I could get away 9600baud.
> > 
> 
> YMMV, but the MAX3100 style of device always looks like
> a CPU that I can't access & so I end up using a CPU that
> I can access instead...  Less cost, better availability,
> more package options. Have to write handler code either
> way. 

Ho, hum - bit-bang a few GPIO lines on the LPC. It works fine 
for us. We use a 38400 Hz interrupt on FIQ to reduce jitter, and 
a state machine to run the protocol. It's been tested with three 
bit-banged UARTs.

If we can do this in high-level Forth without a line of 
assembler, the C-weenies ought to be able to cope ...

Stephen
P.S. implicit smiley!
--
Stephen Pelc, stephen@...
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

Curse you Forth people!!! Engaging in carefree coding without the affliction of 
C-Sickness ;-)

Don
P.S Explicit smiley ;-)  Lest I wind up in the flame zone...

> 
> If we can do this in high-level Forth without a line of 
> assembler, the C-weenies ought to be able to cope ...
> 
> Stephen
> P.S. implicit smiley!
> --
> Stephen Pelc, stephen@...
> MicroProcessor Engineering Ltd - More Real, Less Time
> 133 Hill Lane, Southampton SO15 5AF, England
> tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
> web: http://www.mpeforth.com - free VFX Forth downloads
>

>> Curse you Forth people!!! Engaging in carefree coding without the 
affliction of
C-Sickness  ;-)  <<

I used to work for a company that swore by Forth. They would always bang 
on about how it was so easy and quick to develop with it. However, they 
could never properly explain to me what it was or supply details of why 
it was so much better than C. IIRC, it has to have some monitor type 
program running to do the debug. Thank goodness for JTAG type OCD 
systems. :)

>> Ho, hum - bit-bang a few GPIO lines on the LPC. It works fine
for us. We use a 38400 Hz interrupt on FIQ to reduce jitter, and
a state machine to run the protocol. It's been tested with three
bit-banged UARTs.

If we can do this in high-level Forth without a line of
assembler, the C-weenies ought to be able to cope ... <<

I'd do it in assembler - I'm not afraid of getting down and dirty, but 
the application is just too real-time to be messing around with bit bashing.

>    From: Robert Wood <robert.wood@...>
> 
>  >> Curse you Forth people!!! Engaging in carefree coding without the 
> affliction of
> C-Sickness  ;-)  <<
> 
> I used to work for a company that swore by Forth. They would always bang
> on about how it was so easy and quick to develop with it. However, they 
> could never properly explain to me what it was or supply details of why 
> it was so much better than C. IIRC, it has to have some monitor type 
> program running to do the debug. Thank goodness for JTAG type OCD 
> systems.

Forth gives you interactive debugging on the target with *every* 
function ("word" in Forth parlance) visible to you. This means 
that you can do bottom-up testing. Feeding test scripts for 
execution on the target is usually trivial using a professional-
grade Forth system. 

Forth *is* the monitor you mention. The importance of 
interactive debugging is hard to understand until you have 
experienced it, especially when commissioning equipment.

The interactivity can be provided by the target itself, or by an 
umbilical link to a host PC application. Modern Forth systems 
generate code using compilation techniques like those used in C 
and other compilers, so there is no loss of performance.

Although we make ARM JTAG debuggers, we use them mostly for 
hardware bring-up and production programming. Once the Forth 
system is running, it's faster to debug the system using the 
Forth console.

For more details and a free book about Forth see:
  http://www.mpeforth.com

Stephen
--
Stephen Pelc, stephen@...
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

Hi Stephen,

I'm honestly not wishing to be rude -*please* don't take offence, but I 
just don't see anything that gives you any advantage over running an OCD 
with a JTAG type interface and writing in C. I am not saying there isn't 
one, but the explanation below means nothing to me. This is exactly the 
sort of stuff the chaps at PAC would say and when I asked them why that 
was good they'd just shrug and say because it helps you develop faster! 
They couldn't explain why what you have said below is faster than 
assembler/C with an emulator/OCD.

I understand that Forth is the monitor program, but statements like: 
"The importance of interactive debugging is hard to understand until you 
have experienced it," just remind me of PAC and my impression that 
because they couldn't explain *why* it was so good and how it worked, 
they didn't really understand exactly what they were doing. (Again, I am 
*not* saying there is no advantage, just that statements like that 
completely fail to convince me!)

Also, it does nothing to convince me Forth is better (a claim I heard 
over and over) that the method of writing code I'd been brought up with.

Why does this:

"Forth gives you interactive debugging on the target with *every*
function ("word" in Forth parlance) visible to you."

Give you any more than a compiler/debugger/emulator type method?

Cheers,

Rob (Genuinely interested in why Forth chaps are so evangelical about 
their stuff! :-)

--------------------------------------------------------

Forth gives you interactive debugging on the target with *every*
function ("word" in Forth parlance) visible to you. This means
that you can do bottom-up testing. Feeding test scripts for
execution on the target is usually trivial using a professional-
grade Forth system.

Forth *is* the monitor you mention. The importance of
interactive debugging is hard to understand until you have
experienced it, especially when commissioning equipment.

The interactivity can be provided by the target itself, or by an
umbilical link to a host PC application. Modern Forth systems
generate code using compilation techniques like those used in C
and other compilers, so there is no loss of performance.

Although we make ARM JTAG debuggers, we use them mostly for
hardware bring-up and production programming. Once the Forth
system is running, it's faster to debug the system using the
Forth console.

MANY years ago I was involved with writing the code to hang hard
drives and run CP/M on Apple IIs.

At the time, disk controllers were complex circuit boards with lot of
parts and drives weren't all that reliable.

One of the controller manufacturers I visited used Forth extensively
in their testing process because it allowed for bottom-up testing and
debugging.

Write the code to send bits to a port.
Write code to call the port code and send commands to the port.
...etc.  Always building from the bottom up.

At each step of the development all the lower level code was available. 

Now, the neat thing was the simplicity of interactively defining a new
word (function) that would simply extend the underlying, already known
working, code.  Need a different functional test?  Define a word that
uses what is already known working and interactively available.

I was staggered by the simplicity.  I was not converted, just staggered. 

I have no intention of using Forth nor any desire to start a language
war but there is a certain elegance in the approach.  It is also
obscure, backward reading and a lot of other things.  But it is elegant.

It's odd how some languages stick and others fall away.  Twenty five
years ago I thought C would be replaced by D (fictious successor to C)
or even Pascal.  I still prefer Pascal.  Shows you what I know...

Richard

rtstofer wrote:

>MANY years ago I was involved with writing the code to hang hard
>drives and run CP/M on Apple IIs.
>
>At the time, disk controllers were complex circuit boards with lot of
>parts and drives weren't all that reliable.
>
>One of the controller manufacturers I visited used Forth extensively
>in their testing process because it allowed for bottom-up testing and
>debugging.
>
>Write the code to send bits to a port.
>Write code to call the port code and send commands to the port.
>...etc.  Always building from the bottom up.
>
>At each step of the development all the lower level code was available. 
>
>Now, the neat thing was the simplicity of interactively defining a new
>word (function) that would simply extend the underlying, already known
>working, code.  Need a different functional test?  Define a word that
>uses what is already known working and interactively available.
>
>I was staggered by the simplicity.  I was not converted, just staggered. 
>
>I have no intention of using Forth nor any desire to start a language
>war but there is a certain elegance in the approach.  It is also
>obscure, backward reading and a lot of other things.  But it is elegant.
>
>It's odd how some languages stick and others fall away.  Twenty five
>years ago I thought C would be replaced by D (fictious successor to C)
>or even Pascal.  I still prefer Pascal.  Shows you what I know...
>  
>

WhiteSmiths did bring out a "D" language. It had some ambiguities and 
sometimes it would generate code totally different than what you said.  
I think that I may even have the compiler around someplace on a CD..

TomW


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

>    From: Robert Wood <robert.wood@...>

> I'm honestly not wishing to be rude -*please* don't take offence, but I 
> just don't see anything that gives you any advantage over running an OCD 
> with a JTAG type interface and writing in C.

I've been beaten up so often for using Forth that I'm almost 
impermeable on the topic. Besides, you weren't rude. My response 
is rather long, and I apologise in advance to those I may 
offend, but debugging methodology is a particular hobby-horse of 
mine. 

> This is exactly the sort of stuff the chaps at PAC would
> say and when I asked them why that was good they'd just
> shrug and say because it helps you develop faster! They
> couldn't explain why what you have said below is faster
> than assembler/C with an emulator/OCD. 

At the software debug level, JTAG/emulator/OCD is just the 
interface between the host and the target during debug/test. 
Also important is the user's methodology. What is also important 
is maintenance of the level of abstraction at which you work. 
Debugging is application of scientific method:

while bugs exist:
  while this bug exists:
    observation
    hypothesis
    experiment
    fix

People who can debug well just perform these operations better 
and faster than those who cannot debug well. The core element is 
the innermost loop. Interactive languages such as Forth, 
Smalltalk, Basic and Lisp permit you to write small routines at 
the keyboard and execute them immediately. This promotes the 
hypothesis and experiment sections. Staying within the same 
level of abstraction reduces time. In a good Forth environment, 
you stay at the same level of abstraction all the time.

During debug of hardware I'll regularly type lines such as:

: t begin  $E0000000 @ drop  key? until  ;
t

This defines t to poll an address until a key is pressed. Then 
I'll put a scope probe somewhere. It takes a few seconds, tests 
a hypothesis and gives an experimental result. An interactive 
language with an integral compiler is quicker to use than a 
batch system.

> I understand that Forth is the monitor program

It's not really the monitor program, it's the working 
environment. "Fluffy hand-waving" you may say, but it's the 
difference between approaches that changes how you work.

> but statements like ... just remind me of PAC

We supplied several compilers to them, so it is probably better 
to say nothing.

> Why does this:
> 
> "Forth gives you interactive debugging on the target with *every*
> function ("word" in Forth parlance) visible to you."
> 
> Give you any more than a compiler/debugger/emulator type method?

Because you get round those pesky debugging operations faster in 
many cases.

A secondary advantage comes from the efficient Forth procedure 
call/return mechanism. This is less so with modern frameless C 
compiler techniques, but it promotes writing very short 
routines. These are easier to test, and thorough testing 
enhances software reliability. Well designed short routines are 
reusable, and so code tends to be shorter.

The quote below is relevant.

> From: "rtstofer" <rstofer@...>

> At the time, disk controllers were complex circuit boards with lot of
> parts and drives weren't all that reliable.
> 
> One of the controller manufacturers I visited used Forth extensively
> in their testing process because it allowed for bottom-up testing and
> debugging.
> 
> Write the code to send bits to a port.
> Write code to call the port code and send commands to the port.
> ...etc.  Always building from the bottom up.
> 
> At each step of the development all the lower level code was available. 
> 
> Now, the neat thing was the simplicity of interactively defining a new
> word (function) that would simply extend the underlying, already known
> working, code.  Need a different functional test?  Define a word that
> uses what is already known working and interactively available.
> 
> I was staggered by the simplicity.  I was not converted, just staggered. 

Forth is not a cure for cancer - it's just another programming 
language. In certain application domains it scores very well for 
productivity. Embedded systems is one such domain.

Stephen
--
Stephen Pelc, stephen@...
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

--- In lpc2000@yahoogroups.com, "Stephen Pelc" <stephen@...> wrote:

Stephen,

You seem pretty knowledgeable about Forth. Can you give us a short
rundown on the versions that work with the 68hc12 (and related) devices?

Are there any Forths that are 100% open source? Similarly, are there
any commercial versions that are well supported?

I know that NewMicros has Forth for their boards, but I'm looking for
something of a more general nature.

I played with Forth years ago, but I won't say which version because
that would date me for sure!

Eric

>    From: "Eric Engler" <englere.geo@...>
> Subject: FORTH was Re: SPI comms with another micro
 
> You seem pretty knowledgeable about Forth. Can you give us a short
> rundown on the versions that work with the 68hc12 (and related) devices?

> Are there any Forths that are 100% open source? Similarly, are there
> any commercial versions that are well supported?
 

*** Vendor warning ***
======================
I run MicroProcessor Engineering (MPE). We sell Forth cross-
compilers, amongst other things.

The cross-compiler vendors are, as far as I know, Forth Inc and 
MPE. I haven't used the Forth Inc products, except to play with. 
In my biased opinion, MPE's VFX compilers produce better code. 
Forth Inc's products are cheaper.

The MPE compiler supports the 68HC12 paging, includes multi-
tasking and so on. Client applications include elevator and 
train control systems, and racing-car data-logging. The package 
includes all target source code, and the compiler sources are 
supplied after you sign an NDA.

AM Research produce open-source Forth systems, and there have 
been embedded versions of gForth.

Feel free to contact me directly by email, phone or Skype 
(mpe_sfp).

Stephen
--
Stephen Pelc, stephen@...
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads