Searching \ for '[PIC]:PIC custom component module for ExpressPCB/E' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/pcbs.htm?key=pcb
Search entire site for: 'PIC custom component module for ExpressPCB/E'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:PIC custom component module for ExpressPCB/E'
2003\01\18@171156 by Mike Singer

picon face
Was [OT]: ...
---------------------

Better throw them out and buy PIC18F442.

  Mike.

Aaron Moore wrote:
...
{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\01\18@173730 by John Hansen

picon face
I don't mean to be picky, but I don't think this is very helpful to the
poor fellow who is just trying to get started.  You can still build (or
buy) a simple programmer for the chips that he's acquired for a very small
amount of money.  Most of those chips are also supported by the free
version of HiTech's C compiler.   You can't yet say this about the 18
series chips.  While I'm very impressed with the capabilities of the 18
series, I think there is still a lot to be said for getting started with
the 628 and/or 877.

John Hansen

At 12:15 AM 1/19/03 +0300, you wrote:
{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\01\18@175024 by Byron A Jeff

face picon face
On Sun, Jan 19, 2003 at 12:15:38AM +0300, Mike Singer wrote:
> Was [OT]: ...
> ---------------------
>
> Better throw them out and buy PIC18F442.

Alright Mike, I'll bite.

Talk to me not about the part, but about the toolchain. Tell us about the
development tools and programmers you'd suggest a new user use to get started.

Then I'll ask you about my curveballs, neither of which you are interested in
(my impression from past conversations with you on the subject):

1) A usable toolchain for non Windows environments.
2) A low cost and easy to obtain toolchain.

And of course in the put up or shut up category, here's my list for the
curveballs:

   Platform: Slackware Linux 8.1
       Part: 16F877
 Programmer: TLVP used to install WLoader bootloader
Dev Software: JAL 04-50 or gpasm 0.10.4
  Simulator: gpsim 0.20.12

Total cost is under $25 USD.

The point I'm making is that it's isn't a cut and dried choice.

BAJ

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\01\18@181946 by Mike Singer

picon face
  Olin argued for 18F many times and much better then I ever could.
  Mike.

John Hansen wrote:
> I don't mean to be picky, but I don't think this is very helpful to
the
> poor fellow who is just trying to get started.  You can still build
(or
> buy) a simple programmer for the chips that he's acquired for a very
small
> amount of money.  Most of those chips are also supported by the free
> version of HiTech's C compiler.   You can't yet say this about the 18
> series chips.  While I'm very impressed with the capabilities of the
18
> series, I think there is still a lot to be said for getting started
with
{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\01\18@192824 by Mike Singer
picon face
Byron A Jeff wrote:
> >
> > Better throw them out and buy PIC18F442.
>
> Alright Mike, I'll bite.

Really? I see too many words below. "Barking dogs don't bite"
You are too nice to the fellow to redirect him in a right way, in
my opinion. He is about to start. The price of mistake, when
starting, could be tremendous, compared to the price of
inconvenience of listening to the truth and the price of few
(almost) obsolete chips.
  In Olin's case, I think, his aggressive rudeness is constructive,
forcing someone to start thinking, that is much better then
pleasant sugar niceness leading nowhere, in my opinion.

> Talk to me not about the part, but about the toolchain.
> Tell us about the development tools and programmers
> you'd suggest a new user use to get started.

  Why should we discuss here toolchain's cost? The guy
didn't complain he couldn't afford right tools to start his
professional career.

  Mike.

P.S. Byron, don't feel offended, please. I really appreciate
       your contribution to the List.
-----------
02:25 a.m. - All thins become blurred. I'm going to bed.




{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\01\18@195349 by Olin Lathrop

face picon face
> Talk to me not about the part, but about the toolchain. Tell us about
the
> development tools and programmers you'd suggest a new user use to get
started.
>
> Then I'll ask you about my curveballs, neither of which you are
interested in
{Quote hidden}

OK Byron, I agree Mike was being harsh and I don't even agree with what he
said, but I don't think this is the best way to start with PICs either.
The **standard** development environment for PICs is Microchip's MPLAB,
which is free on their web site.  This is what most examples out there are
written for, and what you'll get the most support for, including this
list.  Yes, it runs on Windows, like most everything else does.  Most
people already have a Windows machine for other reasons, so MPLAB is
completely free.

I would also advise to get a real programmer as I've seen too many newbies
here with TLVP programmer problems.  In addition, if someone first wants
to really *learn* PICs (as apposed to quickly getting a complicated
project working), then assembler is the way to start.  Even if someone
ends up using a higher level language once they get going, the insight
gained from doing a few assembler projects will be valuable.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\01\18@195803 by Olin Lathrop

face picon face
> Olin argued for 18F many times and much better then
> I ever could.

Yes, I think 18F is the way to start if you haven't already bought some
PICs.  Too bad this guy didn't ask here before plunking down his cash.
However if he's already got some 16F877 and 16F628, then those are
reasonable starters too.  I would not agree that he should toss those and
buy 18F parts.  There still isn't an 18F that can replace the 16F628 (18
pins) although it's coming soon.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\01\18@201016 by Jonathan Johnson

flavicon
face
----- Original Message -----
From: "Mike Singer" <spam_OUTmsingerTakeThisOuTspamPOLUOSTROV.NET>
To: <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU>
Sent: Sunday, January 19, 2003 9:33 AM
Subject: Re: [PIC]:PIC custom component module for ExpressPCB/ExpressSch?


>    In Olin's case, I think, his aggressive rudeness is constructive,
> forcing someone to start thinking, that is much better then
> pleasant sugar niceness leading nowhere, in my opinion.
>

Damn true in my opinion also......I appreciate the blunt but straight  path,
in my offline life I'm not really well known for presenting things politely
in every case but you'll always get it straight ......and a lot quicker than
the other way.......(although sometimes a little tact IS required, not with
any reference to this though).


Cheers

JJ

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\01\18@202918 by Byron A Jeff

face picon face
On Sun, Jan 19, 2003 at 02:33:24AM +0300, Mike Singer wrote:
> Byron A Jeff wrote:
> > >
> > > Better throw them out and buy PIC18F442.
> >
> > Alright Mike, I'll bite.
> > Talk to me not about the part, but about the toolchain.
> > Tell us about the development tools and programmers
> > you'd suggest a new user use to get started.
>
>    Why should we discuss here toolchain's cost? The guy
> didn't complain he couldn't afford right tools to start his
> professional career.

Exactly the point. There's absolutely no indication that this is a professional
career.

You have to take into account the amortization costs with the toolchain. He's
already spent a hell of a lot of money if he's only going to do one or two
hobby projects using a PIC.

It seems like you're talking about marriage while I'm promoting dating. There's
a vast difference between investing $20 in parts, a few web searches, and some
downloads for a hobby project against upwards of several hundreds of dollars
for potentially seldom used development tools.

We're not all professionals here. There are students and folks who do it
because it's fun. And for us toolchain costs are extremely important.

BTW I didn't specifically mention costs in the 1st part of the post. I was
just asking what toolchain (development language, compiler/assembler,
programmer, simulator) did you suggest for the 18F.

BAJ
>
>    Mike.
>
> P.S. Byron, don't feel offended, please. I really appreciate
>         your contribution to the List.

Offended? Certainly not.

> -----------
> 02:25 a.m. - All thins become blurred. I'm going to bed.

Talk to you in the morning.

BAJ

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\01\18@203336 by Spehro Pefhany

picon face
At 07:56 PM 1/18/03 -0500, you wrote:
> > Olin argued for 18F many times and much better then
> > I ever could.
>
>Yes, I think 18F is the way to start if you haven't already bought some
>PICs.  Too bad this guy didn't ask here before plunking down his cash.
>However if he's already got some 16F877 and 16F628, then those are
>reasonable starters too.  I would not agree that he should toss those and
>buy 18F parts.  There still isn't an 18F that can replace the 16F628 (18
>pins) although it's coming soon.

Any idea when 18F252/452 chips that don't have the 0x4000 errata are going
to be available?  I know there are work-arounds, but...

http://www.microchip.com/download/lit/suppdoc/errata/80127c.pdf

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speffspamKILLspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\01\18@204412 by Byron A Jeff

face picon face
On Sat, Jan 18, 2003 at 07:52:25PM -0500, Olin Lathrop wrote:
{Quote hidden}

Nor did I. I just threw it out there so that someone wouldn't say that I
proposed a paradox without giving a solution.

> The **standard** development environment for PICs is Microchip's MPLAB,
> which is free on their web site.  This is what most examples out there are
> written for, and what you'll get the most support for, including this
> list.  Yes, it runs on Windows, like most everything else does.  Most
> people already have a Windows machine for other reasons, so MPLAB is
> completely free.

No problem there. I do wish that there was a similar tool for high level
languages. Can anyone talk about the exact status of the Mchip 18C compiler?

>
> I would also advise to get a real programmer as I've seen too many newbies
> here with TLVP programmer problems.

Actually in my recollection it was a couple of people with lots of TLVP
problems. It in fact has a quite high success rate.

>  In addition, if someone first wants
> to really *learn* PICs (as apposed to quickly getting a complicated
> project working), then assembler is the way to start.

The further along I get into this process, the less I believe this theory.
Assembly usually isn't the most efficient way from the development standpoint
though it generally has the ability to produce the most efficient system
in the end.

Most of the advocacy here has been "Learn assembler 1st, then switch to an HLL"
But it seems to me that it's a path to frustration. I think it would be better
to attack from the top down and teach the 90/10 rule, profiling, and selective
recoding.

>Even if someone
> ends up using a higher level language once they get going, the insight
> gained from doing a few assembler projects will be valuable.

Why doesn't this same theory apply to Macs, Solaris, Windows, or Linux boxes?
What is it about small systems that turns this on its head?

It's almost like the linker argument that gets trotted out every 3 months or
so. The linker is clearly better, yet takes a bit of time to understand. Yet
all the code is written in absolute.

BAJ

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\01\18@210936 by Aaron Moore

flavicon
face
In response to many of your comments, I would like to clarify that I am
in fact on a fairly tight budget. However, because this something I
would like to pursue, I don't mind investing a little sum in the right
tools.

For that reason, I mentioned that I got a Warp-13A programmer instead of
hacking together my own.

Anyhow, I am still trying to figure out what language to start with, and
as mentioned by some of you, I've been leaning toward starting with the
MLabs assembler language because it is both free and there seems to be
lots of support for it.

As to learning a HLL first, I think that the very first project should
really be done at the lowest level so you know what is happening when
working with HLL later on. This was true for me when I was learning C++.
You really can't do much of the "Higher Level" WinAPI and what not
without first understanding the fundamentals of C. Once you understand
that and learn about the WinAPI you can start using things like MFC to
program windows app. The knowledge learned from the API and other
fundamentals are totally essential in writing a better app.

In terms of choosing the right chip, I'm quite happy with my selection
as I am not wanting to do very complicated things with the PIC at the
moment. The PIC16F8XX family looked good because of their PWM A/D and
plenty of I/O. that plus a 20Mhz is more then I need for my project.

I am sure there are advantages of using the 18F series, but for now I
will stick to my selection.

Thanks
Aaron

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\01\18@213259 by Russell McMahon

face
flavicon
face
> I am sure there are advantages of using the 18F series, but for now I
> will stick to my selection.

Just in case the point was missed (but it probably wasn't?)  a major feature
of the 18F series for beginners is that it is EASIER to programme than the
16 series because of the linear addressing model.

       RM

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\01\19@010045 by Dale Botkin

flavicon
face
On Sat, 18 Jan 2003, Byron A Jeff wrote:

> >Even if someone
> > ends up using a higher level language once they get going, the insight
> > gained from doing a few assembler projects will be valuable.
>
> Why doesn't this same theory apply to Macs, Solaris, Windows, or Linux boxes?
> What is it about small systems that turns this on its head?

I don't think it applies any less to those boxes, quite frankly.  The
insight gained from doing assembly programming WILL be vaulable.  A
programmer with a more intimate understanding of the hardware and the
system will eventually write much better, faster, cleaner code than one
who doesn't understand anything but the compiler.

On a PIC, though, it does become much more important.  I can afford to
waste a few KB or even a few MB of memory on a PC or a UNIX box, they have
enough hardware and enough speed to effectively mask some HUGE glaring
inefficient crap code (witness certain operating systems).  On a 2GHz Xeon
box with 2GB of memory and a few 80GB hard drives, even Windows looks
fast. You simply don't have that luxury on a PIC.

Dale
---
It's a thankless job, but I've got a lot of Karma to burn off.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\01\19@064554 by Wouter van Ooijen

face picon face
> I can afford to waste a few KB or even a few MB of
> memory on a PC or a UNIX (snip)
> You simply don't have that luxury on a PIC.

That is nonsense, or more to the point: it does not always hold. As I
stated many times before: total cost = engineering cost + unit cost *
number of units. So depending on how the figures are either engineering
or unit cost will be dominant (in some cases both). When engineering
cost dominates, buy big PICs and whatever programming environment that
gets the job done cheaply (development cost wise). When unit cost
dominates, select the cheapest chip that will probably fit (and consider
non-PIC chips because existing experience is not important!), and get a
very good asm programmer (probably hire one) to cram the application
into the chip.

Sow when you want to give anyone a meaningfull advice, first try to
figure out in which of the two situations he (she) will be. A hobbyist
is not likely to be in the 'unit cost dominates' situation, unless he
values his time very very low.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\01\19@070842 by James Caska

flavicon
face
>total cost = engineering cost + unit cost * number of units.

I would have to agree. Also not to forget other costs..

* future engineering cost (re-useable code can reduce)
* cost of code maintenance & enhancements
* cost of skill re-use
* cost of skills recruitment
* cost of proprietry tools

These are all really good reasons why HLL's such as C and Java start to win
the war over assembler when costs are truly computed.

Assembler is fantastic, but is only one tool in the toolbox. The difference
between a good programmer and a great one is to be fluent in all the
available tools and to be able to chose the appropriate tool or combination
of tools needed to best get the job done.

James Caska
http://www.virtualbreadboard.com
muvium - 'Java Bred for Embedded'



> {Original Message removed}

2003\01\19@082310 by Olin Lathrop

face picon face
> Any idea when 18F252/452 chips that don't have the 0x4000 errata are going
> to be available?  I know there are work-arounds, but...
>
> http://www.microchip.com/download/lit/suppdoc/errata/80127c.pdf

No, but you could ask Microchip.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\01\19@085743 by Olin Lathrop

face picon face
> >Even if someone
> > ends up using a higher level language once they get going, the insight
> > gained from doing a few assembler projects will be valuable.
>
> Why doesn't this same theory apply to Macs, Solaris, Windows, or Linux
boxes?
> What is it about small systems that turns this on its head?

Because those systems have infinite resources for the purpose of most
programs, and all the processor and peripheral details are abstracted thru
drivers and interface libraries.  It's all just software layered on more
software, and a few extra cycles or memory locations don't matter.  You can
write large useful programs without having a clue how a computer really
works, although on rare occasions at the edges of the architecture it can be
an advantage to understand how the compiler is using the stack, for example.
The abstractions and generalizations by and large work.  If your program is
a pig, no problem.  For a few 10s of $$, you can add another 128Mbyte of
memory.  No big deal when the system costs $1,000 in the first place.

I also disagree somewhat that the theory of learning bottom up doesn't apply
to large systems.  Bottom up learning in most subjects generally takes
longer to produce "cool" results, but in the end produces better results.
It therefore makes sense to use that approach for the truly motivated and
those that need to really understand.

If you aked me to teach an accountant how to program so that he could write
his own programs for adding up lists of numbers, I would show him a high
level language.  If you asked me to teach freshman computer science students
with the end result measured 4 years later, I would absolutely start with
the low levels on simple systems and work up.  Each step of the way I would
have them discover for themselves the motivations for things like
assemblers, linkers, device drivers, operating systems, compilers, etc.
Four years later they'd be able to jump into any system anywhere and pick up
new information easily.

You also have to take into account different learning styles.  Some will
want instant gratification.  They just want to get a job done and
superficial knowledge is good enough.  They might delve into the details
later.  Frankly I've seen these types of people produce useful results and
get good but never great.  They get stumped more and end up getting help
from the guru.  However, the truly interested will feel "naked" until they
understand what is really happening.  Working top down will frustrate them.
Teaching them bottom up is how you create the next generation of gurus.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\01\19@091310 by Olin Lathrop

face picon face
> total cost = engineering cost + unit cost * number of units.

Yes Wouter, but this doesn't apply to most hobbyists who do it because its
fun and they want to learn something.  The journey can be as much the reward
as the destination.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\01\19@112357 by Wouter van Ooijen

face picon face
> > total cost = engineering cost + unit cost * number of units.
>
> Yes Wouter, but this doesn't apply to most hobbyists who do
> it because its
> fun and they want to learn something.  The journey can be as
> much the reward
> as the destination.

One more reason to ask a newbie what his circumstances and goals are.
The 'want to learn something' can also vote against assembler because
that way the guy might never achieve something. I admit, it might also
vote against HLL. It might even vote agains PICs and for a DIY computer
system...

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\01\19@112359 by Wouter van Ooijen

face picon face
> Because those systems have infinite resources
> for the purpose of most programs

The true art is to recognise when this aslo holds for your PIC
application. I think this the case is for the majority of applications
(which is not the same as for the majority of PICs!).

> It's all just software layered on more software.

Ever wondered why a lot of people use Jal, which is clearly an inferior
languague with only bytes and bits? Hint: libraries!

> You can write large useful programs without
> having a clue how a computer really works

Same for a PIC, you might now exactly how a FET works, but I don't. Yet
I can do a lot with PICs.

> Bottom up learning in most subjects generally takes
> longer to produce "cool" results, but in the end produces
> better results.

I think I agree on this one, but only for a narrow sense of 'better'.

> Teaching them bottom up is how you create the next generation
> of gurus.

Again I think I agree, but not everyone is fit for that route. At school
I have always been frustrated with 'general picture first, details later
(if at all)' methods, but some people (most?) seem to favour that route.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\01\19@115807 by Olin Lathrop

face picon face
From: "Wouter van Ooijen" <.....wouterKILLspamspam.....VOTI.NL>
> > Because those systems have infinite resources
> > for the purpose of most programs
>
> The true art is to recognise when this aslo holds for your PIC
> application. I think this the case is for the majority of applications
> (which is not the same as for the majority of PICs!).

It is certaily NOT true of the majority of applications I do for real.

> > Teaching them bottom up is how you create the next generation
> > of gurus.
>
> Again I think I agree, but not everyone is fit for that route. At school
> I have always been frustrated with 'general picture first, details later
> (if at all)' methods, but some people (most?) seem to favour that route.

That's why you're a guru and they're not.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\01\19@122431 by Dale Botkin

flavicon
face
On Sun, 19 Jan 2003, Wouter van Ooijen wrote:

> > I can afford to waste a few KB or even a few MB of
> > memory on a PC or a UNIX (snip)
> > You simply don't have that luxury on a PIC.
>
> That is nonsense, or more to the point: it does not always hold.

8< snip...

I stand by my original statement.  It was asked why it's so much more
imporatnt to learn assembly and the hardware details of a PIC, I answered.
Code space is very limited on a PIC, and RAM is minimal.  That's why it is
so much more important.

> Sow when you want to give anyone a meaningfull advice, first try to
> figure out in which of the two situations he (she) will be. A hobbyist
> is not likely to be in the 'unit cost dominates' situation, unless he
> values his time very very low.

It doesn't matter whether you're trying to bang out a one-off hobby
project or a million unit per month low-cost device, the same advice
holds.  Learn the hardware and the instruction set first, THEN decide
whether to move up to a higher level language.  And a hobbyis usually DOES
place a low value his or her time, since they're presumably doing it for
fun and to learn.

Don't take this to mean that I don't think you should use a HLL for PIC
projects.  I haven't coded anything in ASM since my very first project a
few years ago.  I switched to C and never looked back.  But I can look at
the listing generated by the compiler and tell whether it's doing things
in a reasonable way, and see where better speed or code efficiency can be
had.  It even lets me find the occasional bug.  If I didn't speak ASM and
didn't know the hardware as well as I do, half my projects would never get
finished.

Dale

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\01\19@141940 by Wouter van Ooijen

face picon face
> It is certaily NOT true of the majority of applications I do for real.

What is the typical unit_count for applications you make?

> That's why you're a guru and they're not.

Right, but that does not prevent me from trying to think what the best
route is for someone with different capacities / experience / interests
/ goals / financials / etc. than me!

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\01\19@161713 by Olin Lathrop

face picon face
> What is the typical unit_count for applications you make?

It varies a lot.  I've got everything from two units for proof of concept
to lifetime volumes in the hundreds of thousands.  Even if volumes end up
being small, most costomers are optimistic and think everyone will
naturally want their little better moustrap.  There's also the issue of
cramming additional features into an existing design.  Sure, a 16F876
could easily take over from a crammed 16F628, but not without a board
redesign.

The point is that there are a lot of reasons beyond production volume for
chosing a PIC and the development environment.  If you use ONE environment
accross projects, then you end up knowing it very well and and justify
spending some time on customizing and maintaining it.  We've started with
MPASM and enhanced the environment significantly where we found it
lacking.  We've used it so much that we are very comfortable with it and
can whip out a new project quickly.  Also, there are now a lot of modules
and library routines that can be re-used, which is worth a lot.  The
statement often heard here that you can develop a project faster in a
higher level language versus assembler is just plain BS in my opinion.  It
has nothing to do with high or low level language, but how comfortable you
are with the development environment and how much re-usable code you have
sitting around.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\01\19@175205 by William Chops Westfield

face picon face
   > total cost = engineering cost + unit cost * number of units.

   Yes Wouter, but this doesn't apply to most hobbyists who do it because
   its fun and they want to learn something.  The journey can be as much
   the reward as the destination.

It still applies, it's just that "engineering cost" becomes much harder to
measure.  Some "engineering costs" (those part of the "learning something")
are considered zero, while other "unpleasant" tasks have so much "cost"
that they are rejected out-of-hand.  (lots of "hobbyists" have given up on
the ideas of making their own device programmers and UV erasers in favor of
relatively expensive commercial offerings, for instance...)

BillW

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\01\19@181511 by Igor Pokorny

flavicon
face
Boys, I am worried you are forgetting about the engine that is clear in PC
industry. Every product must be developed as quickly as possible. Being the
second is like to be last one... Doesn't your program work in your computer?
You should buy the more powerful one... It will happen with micros. I am old
enough to be allowed to predict the development... We don't care about
sources, we need a result. When Microchip will not have a support how to
speed up our products we will try anything else.
I can't help but the best processor (almost risk) was 6502. It's still
produced by Mitsubishi and somewhere in the Arizona. Instructions were such
powerful you don't need any HLL.
Igor


{Original Message removed}

2003\01\19@220542 by Wouter van Ooijen

face picon face
>> What is the typical unit_count for applications you make?
>
> It varies a lot.  I've got everything from two units for
> proof of concept to lifetime volumes in the hundreds of thousands.
> ... most costomers are optimistic and think everyone will
> naturally want their little better moustrap.

Proof-of-concept for a series that could g to a large volume must of
course be developed with the large volume in mind. Sounds like you are
never doing projects that are sure to have a unit_count of 1 (which is
more typical of what I do), so this explains your maindset to me.

> The statement often heard here that you can develop a project
> faster in a higher level language versus assembler is just
> plain BS in my opinion. It has nothing to do with high or
> low level language, but how comfortable you
> are with the development environment and how much re-usable
> code you have sitting around.

I agree with the last, but IMHO asm offers a very weak environment for
re-useable code, because there is no automatic
- removal of un-used code
- static-stack-like variable allocation


Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\01\20@083405 by Olin Lathrop

face picon face
> I agree with the last, but IMHO asm offers a very weak environment for
> re-useable code, because there is no automatic
> - removal of un-used code

The librarian and linker do that, independent of language.

> - static-stack-like variable allocation

I'm not sure what you mean here.  I don't know how to envision a static
variable that is stack-like.

However, I have a method of RAM useage on PICs that has worked very nicely
accross dozens of projects and is easy to implement.  It works well in
assembler, but could just as easily be applied to a higher level language
(for all I know it has been).

I reserve part of the global RAM as "general registers", much like the
general registers of other machines.  13 of these (REG0 - REG12) are
usually allocated on the 16 family in the 70h - 7Fh global region.  They
are used as call and return arguments to subroutines, and for temporary
scratch inside a subroutine.  By convention, subroutines preserve all
these registers to the caller except those that are explicitly documented
to hold return values.  A software stack is used to save/restore those
general registers used by a subroutine on entry and return.  All this is
automated with the GLBSUB subroutine entry macro, and the LEAVEREST
subroutine end macro.  These and others can be found in STD.INS.ASPIC at
http://www.embedinc.com/pic.

The general registers are usually more than enough for all the temporary
local storage of a subroutine.  Therefore, the only RAM reserved by each
module is the persistant state it needs to maintain.  This scheme makes
very efficient use of RAM, and effective use of the limited global memory.
Of course one size doesn't fit all, so on relatively rare occasions a
subroutine may define a static variable that is really local, use an
overlay, trash some general registers on return, or whatever.  Fortunately
in assembler you can break the rules and do what you need to when you need
to.  But again, this happens quite rarely and of course is well documented
when it does.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

2003\01\20@085657 by Wouter van Ooijen

face picon face
> > I agree with the last, but IMHO asm offers a very weak
> environment for
> > re-useable code, because there is no automatic
> > - removal of un-used code
>
> The librarian and linker do that, independent of language.

Come on Olin, look a bit wider than your assembler view! Take this code
fragment (imagine it being part of the delay needed for I2C or SPI or
the like:

  for( i=0; i+1 < time_in_us; i++ ){
     wait_1us()
  }

time_in_us could be a variable with an unknow value => generate code, or
a constant with a known value => generate different, more compact code,
or a constant that is 0 or 1, or even a variable that is known to hold a
value of 0 or 1 => generate no code at all.

The important point is that the writer of this piece of code does not
have to optimize for each of these situations, the compiler will do it
for him.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2003\01\20@190303 by Mike Singer

picon face
Byron A Jeff wrote:
> >    Why should we discuss here toolchain's cost? The guy
> > didn't complain he couldn't afford right tools to start his
> > professional career.
>
> Exactly the point. There's absolutely no indication that this is
> a professional career.
>
> You have to take into account the amortization costs with the
> toolchain. He's already spent a hell of a lot of money if he's
> only going to do one or two hobby projects using a PIC.
>
> It seems like you're talking about marriage while I'm promoting
> dating...

Cool phrase. You are right, of course. If someone just wanna
f*ck a bit, why is he to spend a lot of time choosing right
person? I mistakenly was thinking that he would invest months
and years of his time in his rising as EE engineer, not just
f*cking around.

  Mike.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

2003\01\20@195125 by Mike Singer

picon face
  Kinda posts that get me silent on the List for a while. Thing usually are not covered in datasheets :-)
Things that could affect the way I think.

  Mike.

Olin Lathrop wrote:
> > >Even if someone
> > > ends up using a higher level language once they get going, the
insight
> > > gained from doing a few assembler projects will be valuable.
> >
> > Why doesn't this same theory apply to Macs, Solaris, Windows, or
Linux
> boxes?
> > What is it about small systems that turns this on its head?
>
> Because those systems have infinite resources for the purpose of most
> programs, and all the processor and peripheral details are abstracted
thru
> drivers and interface libraries.  It's all just software layered on
more
> software, and a few extra cycles or memory locations don't matter.
You can
> write large useful programs without having a clue how a computer
really
> works, although on rare occasions at the edges of the architecture it
can be
> an advantage to understand how the compiler is using the stack, for
example.
> The abstractions and generalizations by and large work.  If your
program is
> a pig, no problem.  For a few 10s of $$, you can add another 128Mbyte
of
> memory.  No big deal when the system costs $1,000 in the first place.
>
> I also disagree somewhat that the theory of learning bottom up doesn't
apply
> to large systems.  Bottom up learning in most subjects generally takes
> longer to produce "cool" results, but in the end produces better
results.
> It therefore makes sense to use that approach for the truly motivated
and
> those that need to really understand.
>
> If you aked me to teach an accountant how to program so that he could
write
> his own programs for adding up lists of numbers, I would show him a
high
> level language.  If you asked me to teach freshman computer science
students
> with the end result measured 4 years later, I would absolutely start
with
> the low levels on simple systems and work up.  Each step of the way I
would
> have them discover for themselves the motivations for things like
> assemblers, linkers, device drivers, operating systems, compilers,
etc.
> Four years later they'd be able to jump into any system anywhere and
pick up
> new information easily.
>
> You also have to take into account different learning styles.  Some
will
> want instant gratification.  They just want to get a job done and
> superficial knowledge is good enough.  They might delve into the
details
> later.  Frankly I've seen these types of people produce useful results
and
> get good but never great.  They get stumped more and end up getting
help
> from the guru.  However, the truly interested will feel "naked" until
they
> understand what is really happening.  Working top down will frustrate
them.
> Teaching them bottom up is how you create the next generation of
gurus.
>
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

2003\01\20@204334 by James Caska

flavicon
face
Hi All,

I just thing there is a really good reason we don't program with punchcards
anymore.. its called productivity.

Lets just face it, regardless of what proprietry macro's you come up with
projects written in assembly are a nightmare to maintain and even worse to
code review. Forcing the developer to think like a micro not a programmer,
relying on special features of the processor like unbanked special general
purpose code sections with the only way to really see the code is to single
step and look at things as they happen.

While I agree that small systems increase the need for this type of low
level understanding... its just a wee bit over the top to expect someone to
wait 4 years to gain the type of knowledge needed to come from bottom up.
Hey, by then the kid has lost interest in flashing LED's and has gone and
got a job as a java programmer earning double his embedded counterpart.

Assembly is a necessary evil for sure, and yes it is mandatory for the
embedded professional but like the rest of the computing world, over time
assembly is sinking to the bottom of the food chain. Those trying to keep it
on the top of the heap will eventually loose their battle.

However, there is no 'silver bullet' in embedded. These are all just tools
in the toolbox, assembly and high level languages should be used in the
optimal configuration for the job at hand and yes, that often depends most
significantly with what a specific developer has used in the past and has
code templates for. But this is a very developer specific mindset and what
is good for one developer is not necessarily the best for the rest of the
world.

My time on the 'soapbox' has come to and end ;-)

Cheers all,

James Caska
http://www.virtualbreadboard.com
http://www.muvium.com
uVM - 'Java Bred for Embedded'



> {Original Message removed}

2003\01\20@215511 by William Chops Westfield

face picon face
   Lets just face it, regardless of what proprietry macro's you come
   up with projects written in assembly are a nightmare to maintain
   and even worse to code review. Forcing the developer to think
   like a micro not a programmer...

For the same reasons that you don't need to worry so much about
efficiency on large mircocomputers, you also don't need to worry QUITE
so much about maintainability and readability on SMALL microcomputers.
I mean, how obscure can you get, being moderately careful, in less than
2K instructions?

Start looking at the bigger micros with 8K or more of program space, and
you can run into problems whether you try to avoid them or not, and even
a TINY program for a desktop PC (say, 64k of code) can easilly become a
nightmare...

BillW

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body

2003\01\21@143141 by Peter L. Peres

picon face
On Mon, 20 Jan 2003, William Chops Westfield wrote:

*>For the same reasons that you don't need to worry so much about
*>efficiency on large mircocomputers, you also don't need to worry QUITE
*>so much about maintainability and readability on SMALL microcomputers.

*>I mean, how obscure can you get, being moderately careful, in less than
*>2K instructions?

Hehehe. I used to write spagetti assembly for 16C54 based on this
assumption. I had not managed to fill the chip (512 code words) before I
started losing track of things in the source between editing sessions
(days apart). Don't do it. I had to learn the hard way.

I also found that I wanted to reuse 80% of what I wrote 'just for that
project' 1-2 years later. Don't do spagetti code, it is a real real
pain.

Imho being moderately careful here is to be fascist about hungarian
notation for symbols, document each code change with 1 line of comment
and keep an outline of why you did things the way you did them in an
associated text file. Also note down any problems that happened while
testing or integrating it. Eg. if integration of module A with module B
breaks something write it down BOTH in module A's comments and in B's,
especially if you can't solve the problem right away.

Last, I think that version numbers are the best thing invented by mankind.
Keep a version number on everyting (like each module and subroutine) and
increment it every time you feel like it, but in any case with each and
every code change, at the latest at the end of a session. If you do not,
later you will have 3 copies of the code (say a backup, the previous
version or the version the text editor wants to recover after a crash or
irregular shutdown, and the last edited version), and you will start
wondering which one was the one that worked right.

Peter

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu>

2003\01\21@160825 by Dennis J. Murray

flavicon
face
I respect James' opinion.  However, I also respectfully disagree with some
of his premises.

I have specialized in assembly languages throughout my programming career.
In 1968, my boss at Boeing told me to get into high level languages 'cause
my days as an assembler language programmer were numbered ( I was a "Systems
Programmer" on mainframes).  He was absolutely convinced by the trade
journals that all computers would end up being programmed using HLL - even
for system functions - in a matter of a few short years.  That was 35 years
ago!

In reality, things are not much cifferent today.  There are STILL things
that are best done in assembly.  Likewise, there are still things that are
MUCH better done in HLL, such as statistical analysis, etc.  But aren't we
really talking about a middle ground here?  Each application should be
reviewed by all salient factors, such as timing (if an issue), complexity,
size and power of the desired platform, etc., in order to make a decision of
the best way to go - HLL, assembly, or a hybrid.  You cannot make such a
decision unless you have a firm grasp of the tools at your disposal - and
assembly language is a vital tool on something as limited as even the most
powerful PIC (personal opinion here!).  Some of the C compilers I've looked
at are very good at optimization, but I still find occasion where assembly
is the best choice - even if it's just a module!

Assembly forces you to understand the architecture of the chip, whereas a
HLL removes much of that need.  That's mostly a good thing, but to really
write a bulletproof  PIC application, knowledge of the hardware is
frequently invaluable.

I vote for learning assembly first.  To me, a RISC arhitecture such as the
PIC is one of the easiest to learn (although maybe harder to master).  You
might want to minimise the pain by learning the 18F series first.  Be aware,
I'm not advocating "mastering" assembly before moving on to HLL, just become
proficient enough to write a decent program, THEN move on if you wish.  That
way, you have the advantage of choosing the best tool for a particular job,
rather than limiting yourself to force fitting every application into the
HLL you know.  It's like the saying - when all you have is a hammer,
everything else had better be a nail!

That's strictly my opinion for what little it's worth!
Dennis

----- Original Message -----
From: "James Caska" <TakeThisOuTcaskaEraseMEspamspam_OUTVIRTUALBREADBOARD.COM>
To: <RemoveMEPICLISTspamTakeThisOuTMITVMA.MIT.EDU>
Sent: Monday, January 20, 2003 8:47 PM
Subject: Re: [PIC]:PIC custom component module for ExpressPCB/ExpressSch?


> Hi All,
>
> I just thing there is a really good reason we don't program with
punchcards
> anymore.. its called productivity.
>
> Lets just face it, regardless of what proprietry macro's you come up with
> projects written in assembly are a nightmare to maintain and even worse to
> code review. Forcing the developer to think like a micro not a programmer,
> relying on special features of the processor like unbanked special general
> purpose code sections with the only way to really see the code is to
single
> step and look at things as they happen.
>
> While I agree that small systems increase the need for this type of low
> level understanding... its just a wee bit over the top to expect someone
to
> wait 4 years to gain the type of knowledge needed to come from bottom up.
> Hey, by then the kid has lost interest in flashing LED's and has gone and
> got a job as a java programmer earning double his embedded counterpart.
>
> Assembly is a necessary evil for sure, and yes it is mandatory for the
> embedded professional but like the rest of the computing world, over time
> assembly is sinking to the bottom of the food chain. Those trying to keep
it
{Quote hidden}

> > {Original Message removed}

2003\01\21@163227 by Dennis J. Murray

flavicon
face
Peter

Your words of wisdom are appropriate no matter WHAT language you're using!
Don't limit this to assembler!  I've seen HLL routines that took me forever
to figure out - just because they didn't follow the rules you've elaborated
on!


{Original Message removed}

2003\01\21@183737 by James Caska

flavicon
face
Hi Dennis/all.

In fact I completetly agree in the 'tools in the toolbox' philosophy you are
advocating here. The optimal result is always going to come from
understanding all the available tools to their deepest level and selecting
the appropriate tools for the appropriate task.

If we agree that we need to learn all the tools ultimately then why start
with the tool that gives you least reward first? Why spend all that time at
college learning a proprietry assembly instruction language and
microcontroller architecture so you can make lights flash on an off when in
the same time you can learn java and apply that one skill to web
application, database application, or results orientated embedded
applications and in most instances get as good or better result than the
hardcore assembly old timers (no disrespect intended). Then once having got
excited about what you can do in embedded start to drill down into the guts
of it so you can optimise parts of your code or even use assembly completely
for some projects.

I agree it is a philosophy shift that's hard to get used to. Top down vs
Bottom up, but with limited resources (time) available to those getting
started with competing programming and potential career interests on the
line the idea of learning a transportable skillset like java first just
makes sense. Even if you are just learning for the sake of learning it makes
sense to get results first and drill down into the guts of it on demand.

Of course, this is only my opinion :-)

Respectfully,
James Caska
http://www.virtualbreadboard.com
http://www.muvium.com
uVM - 'Java Bred for Embedded'


> {Original Message removed}

More... (looser matching)
- Last day of these posts
- In 2003 , 2004 only
- Today
- New search...