> There seems to be a handful of us that would really love the Linux based
> PIC tools. Do you think we can stir up enough interest to begin a project?
So, I've got a spoon and am stirring. Is anybody out there interested
in creating a forum and discussing how to go about this and trying to
get a project off the ground. I've given it a lot of thought lately and
would be keen to do something, I don't even think it needs to be PIC
specific, done properly it could work for any programmer and for any
controller/processor. It could even work on any UNIX platform.
If necessary I can set up a mailing list and host a web resource.
Reply direct to me as well as to the list in case I miss the list
postings. My email is spam_OUTdaveTakeThisOuTrestall.net. This of course presumes that
anybody is interested enough to want to reply :-)
Regards,
Dave Restall
mail/pic/980530.tx piclist
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Dave Restall Internet Intranet Resourcing Consultancy Limited +
+ Tel. +44 (0) 1287 653003 Mob. +44 (0) 973 831245 Fax. +44 (0) 1287 653440 +
+ email : .....daveKILLspam@spam@iirc.netdaveKILLspamrestall.net Web : http://www.iirc.net +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ If you can't see o _ _ _ +
+ the picture --------- __o __o /\_ _ \\o (_)\__/o (_) +
+ try a fixed ------- _`\<,_ _`\<,_ _>(_) (_)/<_ \_| \ _|/' \/ +
+ space font ------ (_)/ (_) (_)/ (_) (_) ROCKS (_) (_) (_)' _\o_ +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> So, I've got a spoon and am stirring. Is anybody out there interested
> in creating a forum and discussing how to go about this and trying to
> get a project off the ground.
> If necessary I can set up a mailing list and host a web resource.
--
Don't forget to remove the .antispam at the end of my
reply-to address before sending off any replies.
At 21:25 30/05/98 GMT, you wrote:
>Hi,
>
>In response to an earlier posting I got this :-
>
>> There seems to be a handful of us that would really love the Linux based
>> PIC tools. Do you think we can stir up enough interest to begin a project?
>
>So, I've got a spoon and am stirring. Is anybody out there interested
>in creating a forum and discussing how to go about this and trying to
>get a project off the ground. I've given it a lot of thought lately and
>would be keen to do something, I don't even think it needs to be PIC
>specific, done properly it could work for any programmer and for any
>controller/processor. It could even work on any UNIX platform.
>
>If necessary I can set up a mailing list and host a web resource.
>
>Reply direct to me as well as to the list in case I miss the list
>postings. My email is .....daveKILLspam.....restall.net. This of course presumes that
>anybody is interested enough to want to reply :-)
Spoon?
Huh!
Lo-tech - I have a whisk! (OK so it's manual and not electric...)
I'm interested in developing initially some command line driven tools for
serial and parallel interfacing so I can use them from DOS boxes under
Win95, and portables running Win3 DOS boxes, plus Linux (which I still
haven't installed on my 386! I have used it before of course, and as a
side-question I want to know which is the "best" version - I have a 2 year
old version of slackware), and then from WinNT most likely. I think I won't
bother with the OS2 Warp 3 version.. (still boxed!)
Maybe also simulate some externals, like UMPS?
(And also that way simulate the on-chip pheriperals?)
(PS have actually not yet used neither UNIX nor UMPS bcause of lack of time
and money respectively, but I put in my last cents anyway because it sounds
interesting... DS)
/Morgan
>Hi,
>
>In response to an earlier posting I got this :-
>
>> There seems to be a handful of us that would really love the Linux based
>> PIC tools. Do you think we can stir up enough interest to begin a project?
>
>So, I've got a spoon and am stirring. Is anybody out there interested
>in creating a forum and discussing how to go about this and trying to
>get a project off the ground. I've given it a lot of thought lately and
>would be keen to do something, I don't even think it needs to be PIC
>specific, done properly it could work for any programmer and for any
>controller/processor. It could even work on any UNIX platform.
>
>If necessary I can set up a mailing list and host a web resource.
>
>Reply direct to me as well as to the list in case I miss the list
>postings. My email is @spam@daveKILLspamrestall.net. This of course presumes that
>anybody is interested enough to want to reply :-)
>
>Regards,
>
>
>Dave Restall
>mail/pic/980530.tx piclist
>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++
>+ Dave Restall Internet Intranet Resourcing Consultancy
Limited +
>+ Tel. +44 (0) 1287 653003 Mob. +44 (0) 973 831245 Fax. +44 (0) 1287
653440 +
>+ email : KILLspamdaveKILLspamiirc.netRemoveMEdaveTakeThisOuTrestall.net Web : http://www.iirc.net +
>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++
>+ If you can't see o _ _ _
+
>+ the picture --------- __o __o /\_ _ \\o (_)\__/o (_)
+
>+ try a fixed ------- _`\<,_ _`\<,_ _>(_) (_)/<_ \_| \ _|/' \/
+
>+ space font ------ (_)/ (_) (_)/ (_) (_) ROCKS (_) (_) (_)'
_\o_ +
>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++
>
Nice cartoon!
On Sat, 30 May 1998, Dave Restall - System Administrator wrote:
> Hi,
>
> In response to an earlier posting I got this :-
>
> > There seems to be a handful of us that would really love the Linux based
> > PIC tools. Do you think we can stir up enough interest to begin a project?
>
> So, I've got a spoon and am stirring. Is anybody out there interested
> in creating a forum and discussing how to go about this and trying to
> get a project off the ground. I've given it a lot of thought lately and
> would be keen to do something, I don't even think it needs to be PIC
> specific, done properly it could work for any programmer and for any
> controller/processor. It could even work on any UNIX platform.
>
> > There seems to be a handful of us that would really love the Linux based
> > PIC tools. Do you think we can stir up enough interest to begin a project?
>
At this moment i would not be able to spent much time for such
projects, but i am very interested in Linux software for electronics
development and embedded controllers. I have also some Ideas for
suitable projects ... but no time :-(
...
>
> If necessary I can set up a mailing list and host a web resource.
>
There is alredy a mailing list about free electronics Software. Here is
a
part of the official description :
> This list is about free electronics software; specifically,
> to exchange locations of existing software, recommendations
> as to software for a particular purpase, etc, as well as ideas
> people have for writing new software etc. Integrated development
> environments for micros seems to be high on the wishlist for a lot
> of people, for example.
>
> "Free" refers to licenses like GPL, Artistic, and BSD. In particular
> we are interested in software for Unix, in particular the free
> ones such as Linux and FreeBSD.
At 20:51 98.06.01 +0200, you wrote:
>Hi !
>
>Dave Restall - System Administrator wrote:
>>
>...
>
>>
>> > There seems to be a handful of us that would really love the Linux based
>> > PIC tools. Do you think we can stir up enough interest to begin a
project?
>>
>
[SNIP]
>
>The list adress is :
>
>RemoveMEfesTakeThisOuTrising.com.au
>
>Sorry, I have lost the adress of the majordomo for
>subscribe/unsubscribe.
>
[] Jorge
===============================================================
cumprimentos / best regards
Jorge Ferreira //EraseMEjorgegfmail.telepac.pt
------ Make sure brain is in gear before engaging mouth -------
===============================================================
> > > There seems to be a handful of us that would really love the Linux based
> > > PIC tools. Do you think we can stir up enough interest to begin a project?
A lot of the software has already been written. A lot of work is
needed to put it all together as a single integrated development
environment. The trick, I believe, is to make the package suitable for
any assembly language not just PICs. Here is what I have found to be
suitable for a generic IDE:
Emacs editor
GNU make utility
GNU m4 macro processor
TASM - shareware table driven assembler can be used for any
assembly language
RCSC - free retargettable concurrent small C can be used for any
target processor
UMPS - commercial universal simulator and assembler.
You can see that there are some of the above are not entirely
satisfactory. I don't know what macro features TASM provides; get it
from the cross compilers directory of a SIMTEL archive. UMPS
<http://www.sistudio.com/umps> is commercial and comes only for MS
operating systems and I haven't used it. RCSC can be got from Dr Dobbs
Journal Aug 1997 has limited optimization but could be improved with
more, perhaps target-specific, optimizations. Emacs already provides
major and minor modes for every IDE function, ASM mode, compile
through make utility, Revision control system, debug (simulator)
interface. Finally, the GNU stuff is ported to many operating systems.
If anything else were to be written in Java, then it would be a very
portable and universal IDE. Existing software is very close to making
a universal macro assembler, C compiler and simulator but it still
needs a lot of work to integrate it all into one package.
> There is alredy a mailing list about free electronics Software.
> The list adress is :
>
> RemoveMEfesEraseMEEraseMErising.com.au
>
> Sorry, I have lost the adress of the majordomo for
> subscribe/unsubscribe.
Can you write to the list and ask what the list server address is?
> In response to an earlier posting I got this :-
>
> > There seems to be a handful of us that would really love the Linux based
> > PIC tools. Do you think we can stir up enough interest to begin a project?
PIC tools are free! So what sort of hamster brain would go off and
suggest such a foolish project? Oh - wait, that was me!
But why? Why would I want to go off and re-invent a perfectly good
wheel?
> I would like to see a full suite of assembler, simulator, c compiler,
> disassembler, and progammer software under GPL which will compile under
> most POSIX Unixes, and probably DJGPP as well. Quite a few of these
> things already exist in limited and incomplete forms but we need
> something better if Linux is to become a serious contender for PIC
> development. MPASM isn't too bad apart from the fact that the latest
> versions only run under Billy's wonderful OS, but without the source
> available the only way to fix bugs is to submit an official bug report
> and wait. As for compilers, the best ones are far from free, and still
> contain bugs which due to the lack of freely distributed source it's
> impossible to fix yourself.
I probably could list a dozen reasons why a serious Open-PIC-Project
(OPP?) should be started. As an Engineer I agree with Alex: there's this
over-powering allure in the ability to instantly fix bugs or at least be
part of a team that can respond like wise. MPLAB is wonderful (compared
to other microcontroller IDEs), but their staff-limited programmers can
not respond with the efficacy of a intricately linked network of
dedicated developers.
In a Linux vs. NT debate for EDA, David F. Skoll writes:
> Linux has piqued people's interest because it is free, it is the
> epitome of open, and it was developed by people who like to use it.
>
> I use NT because I have to; I use Linux because I want to.
Linux is Free. Linux is Free! Linux is Free?
Dave continues:
> If necessary I can set up a mailing list and host a web resource.
Dave, if you can start a mailing list that would be wonderful! BTW, I
can also dedicate web resources.
I'm not a Unix expert. So it would be great if you could share some of
your ideas on how such a project should be approached. I'm certain
between you and Mal Goris and Eric Smith (speak up Eric!) and many other
linux/unix users we could define an outline and set some goals.
Rick Miller has done a good job collecting many Linux friendly PIC
programs. It does not seem to include a link to Nexus Computing, at http://www.eskimo.com/~nexus/, where the picprg2.2 resides. But I'll tell
him. He has at least 4 coices each for assemblers, compilers, and burners,
so download 'em all, install a half dozen parallel ports in you linux box,
slap together some burner hardware, and have at it!
As to a discussion list, what's wrong with this one?
Andrius Tamulis wrote:
>
> Did noone see the posted url:
>
> http://www.execpc.com/~rdmiller/gnupic/
>
> Rick Miller has done a good job collecting many Linux friendly PIC
> programs. It does not seem to include a link to Nexus Computing, at
> http://www.eskimo.com/~nexus/, where the picprg2.2 resides. But I'll tell
> him. He has at least 4 coices each for assemblers, compilers, and burners,
> so download 'em all, install a half dozen parallel ports in you linux box,
> slap together some burner hardware, and have at it!
I saw Rick's web page a year ago. And as some one else just mentioned,
it appears to have become stagnate. I hadn't seen the Nexus page until
now. Brian's certainly got the right attitude: PIC's, Linux,
Enlightenment, and GTK+ - A helluva combo!
I think the reason that Rick's page has not taken off is because it is
simply a collection of autonomous packages. What's needed is a serious
integration effort. No one is particularly interested in starting
totally from scratch. I'm am NOT a Linux expert, but what I would
suggest is an initial project with these simple goals:
2) Design an IDE that integrates these three features:
i) Editor. There are a number of them available.
ii) Assembler for the mid-range core. Same for this.
iii) HEX generator. and this.
If a group of us can coordinate development efforts to accomplish this
goal then it will become feasible to suggest more aggresive goals:
Support low and high end cores, Simulator, Interface to Tait's
ubiquitous programmer, hacking PICstart (it's not as hard as it sounds),
create virtual peripherals (e.g. 2X16 LCD display, A2D converter, LED's,
etc...), C-compiler, BASIC compiler, FORTH (why not?), smart code
synthesizer (ala John Payson's magic BASIC program), and so on.
Certainly though, if anyone wants to develop or contribute in these
areas too, no one will stop them.
> As to a discussion list, what's wrong with this one?
Hmm? Initially nothing. However, if the project takes off there will be
details discussed that will not appeal to most others (sort of like the
OT crap of late).
Scott
--
__o
I buy pizza instead of gas. \<
(*)/(*)
>
> Did noone see the posted url:
>
> http://www.execpc.com/~rdmiller/gnupic/
>
> Rick Miller has done a good job collecting many Linux friendly PIC
> programs.
Rick has handed the GNUPIC project to James Bowman:
> Andrius Tamulis wrote:
> >
> > Did noone see the posted url:
> >
> > http://www.execpc.com/~rdmiller/gnupic/
> >
> > Rick Miller has done a good job collecting many Linux friendly PIC
> > programs. It does not seem to include a link to Nexus Computing, at
> > http://www.eskimo.com/~nexus/, where the picprg2.2 resides. But I'll tell
> > him. He has at least 4 coices each for assemblers, compilers, and burners,
> > so download 'em all, install a half dozen parallel ports in you linux box,
> > slap together some burner hardware, and have at it!
>
> I saw Rick's web page a year ago. And as some one else just mentioned,
> it appears to have become stagnate. I hadn't seen the Nexus page until
> now. Brian's certainly got the right attitude: PIC's, Linux,
> Enlightenment, and GTK+ - A helluva combo!
>
> I think the reason that Rick's page has not taken off is because it is
> simply a collection of autonomous packages. What's needed is a serious
> integration effort. No one is particularly interested in starting
> totally from scratch. I'm am NOT a Linux expert, but what I would
> suggest is an initial project with these simple goals:
>
> 1) Select a GUI SDK. I would recommend GTK+ (the Gimp tool kit
> http://www.gtk.org/ ) but there are others: Lesstif at
> http://www.lesstif.org/ , and KDE at http://www.kde.org/ .
>
> 2) Design an IDE that integrates these three features:
> i) Editor. There are a number of them available.
> ii) Assembler for the mid-range core. Same for this.
> iii) HEX generator. and this.
>
> If a group of us can coordinate development efforts to accomplish this
> goal then it will become feasible to suggest more aggresive goals:
> Support low and high end cores, Simulator, Interface to Tait's
> ubiquitous programmer, hacking PICstart (it's not as hard as it sounds),
> create virtual peripherals (e.g. 2X16 LCD display, A2D converter, LED's,
> etc...), C-compiler, BASIC compiler, FORTH (why not?), smart code
> synthesizer (ala John Payson's magic BASIC program), and so on.
> Certainly though, if anyone wants to develop or contribute in these
> areas too, no one will stop them.
>
> > As to a discussion list, what's wrong with this one?
>
> Hmm? Initially nothing. However, if the project takes off there will be
> details discussed that will not appeal to most others (sort of like the
> OT crap of late).
>
> Scott
> --
> __o
> I buy pizza instead of gas. \<
> (*)/(*)
>
>
Hi all,
I have planned to hack PICStart. I kindly asked Microchip, and they said
they forward my request to the responsible group (whatever it means). I'm
in a wait state for a while... Could you also say Microchip they give me
the requested information? It would be a great help...
I certainly hope that if linux versions of PIC software are
developed, they can be happy in a GUI and non GUI environment. I would
think it would be much more useful to have good rugged applications
in which most of the brain power went to make them work properly rather
than to produce an artistic experience that sometimes does weird things that
nobody seems to be able to reproduce or explain. The gcc compiler is a
wonderful piece of design and I must pinch myself to realize that it
is free, especially when you think of the time that must have gone in to it.
There is also a debugger called gdb that is also free and it also works
in a text-based environment.
Shouldn't we have a choice? The whole idea of computing is that
there is more than one way to skin a cat and the end result is what matters.
Why even bother if the end result is a choice between GUI or GUI?
Martin McCormick WB5AGZ Stillwater, OK
OSU Center for Computing and Information Services Data Communications Group
What is Linux/FreeBSD/NetBSD binary compatibility like? Traditionally,
a major problem with releasing "unix" tools is that there are a billion
varieties of unix, and it frequently takes source AND a unix wizard to
produce a running binary for anything different than the developer's version.
Sure! Your choice is: do you want to participate or not. If you do then
your experience, intelligence, and time will be greatly appreciated. If
you don't then... Well I can't promise you anything.
> Why even bother if the end result is a choice between GUI or GUI?
Aesthetics and pragmatism balance precariously on egoism. If I decide to
invest my time then I'll will have to make it worth the effort.
There's no reason that a GUI and text based development system can't
co-exist. Pilot guru, Kenneth Albanowski's text based pilot tools have at
least two different GUIs wrapped around them. The purpose of a GUI for PIC
tools is to provide a convenient (to me) method of integrating several
packages together.
On Sat, 6 Jun 1998, William Chops Westfield wrote:
>
> What is Linux/FreeBSD/NetBSD binary compatibility like? Traditionally,
> a major problem with releasing "unix" tools is that there are a billion
> varieties of unix, and it frequently takes source AND a unix wizard to
> produce a running binary for anything different than the developer's version.
There are binary releases for the popular unices. However, since the
software is free, the source code is also distributed. So theoretically
you can build any package on any system. One of my co-workers has Linux
running on a Power PC and regularly builds and installs software with no
problems.
Time to time I here of problems with code developed within a Linux
environment not compiling under Solaris (for example). But from my
understaning, these problems are easily fixed (usually with #define's and
#ifdef's ...)
Redhat, a popular distibutor of Linux, has created a "package manager" or
RPM (redhat package manager) that among other things addresses some of the
system dependencies.
Scott
PS. You do know the difference between theory and practice, don't you?
I know virtually nothing about how to build a C compiler, but
my vague understanding is that most of them develop pseudo code and then
a module for the particular processor containing a description of all the
rules translates that pseudo code in to OP codes or possibly mnemonics
for an assembler to change in to op codes.
It would seem that for GCC or any other full C compiler, most of the
memory management functions like malloc would have to be turned off for
PIC's since there is such a small amount of memory to work with. Such things
as printf and all that whole family of functions would almost have to go away
because there is not a standard output as such. What exactly is left besides
the math routines and possibly string handling routines?
Another set of routines that would be nice to have in a C compiler
for PIC's but which may simply be too much of a memory hog are all the time
and date building functions. They are absolutely clever and while Y-2K
compliant will die in 2037 when the 32-bit counter runs out. That is of
course unless somebody writes a new version of the routine with a new epochal
time at which point, you get another 68 or so years.
All you need for a clock is a 32-bit counter and the software does
all the rest. Setting the clock involves a formula that is the reverse
of the first formula. It calculates how many seconds to put in to the
counter based on the epoch date and the date you told it to set. These
routines also can understand time zones and even Daylight Savings time rules.
On another part of this same thread, the usual problem that people
run in to porting C source to a given platform is that of differences
between libraries. AIX, for example has something called sys/select that
has a lot of network code in it. You can get programs that call for this
library to compile on Solaris, but you must specify a different set of
libraries when building your Makefile or when you compile a single program
you have written that needs these libs. What you otherwise get is a flood
of unresolved references and undeclared variable errors for things you never
heard of and certainly didn't put in your program. Actually, you did put
them there by virtue of using the libraries and the new system you are trying
to port this code to sees that you need these things and they aren't there.
Sometimes, it is as easy as finding out which libraries do provide what you
need and including them in the compilation. Other times, it gets to be a
grand mess, but that is one of the most common headaches you will run in to.
Martin McCormick WB5AGZ Stillwater, OK
OSU Center for Computing and Information Services Data Communications Group
On Thu, 11 Jun 1998 RemoveMEbillwspam_OUTKILLspamCISCO.COM wrote:
> What is Linux/FreeBSD/NetBSD binary compatibility like? Traditionally,
> a major problem with releasing "unix" tools is that there are a billion
> varieties of unix, and it frequently takes source AND a unix wizard to
> produce a running binary for anything different than the developer's version.
They aren't binary compatible, but we're talking about free tools with all
source available. Getting the source to compile on different platforms can
be a problem, but there are ways around it such as Autoconf, a script
which autodetects a million and one things about your platform and sets
everything up for you. I don't like it much though, because it can be a
pain for the developer to get working properly in the first place and
tends to make a mess of the Makefile(s). Another way is just to have a set
of commented out #defines your Makefile, and tell the installer to
"comment out the relevant #defines in the Makefile".
--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
---------- http://www.geocities.com/CapeCanaveral/Lab/1532/ ---------
On Thu, 11 Jun 1998 RemoveMEmartinTakeThisOuTspamDC.CIS.OKSTATE.EDU wrote:
> I certainly hope that if linux versions of PIC software are
> developed, they can be happy in a GUI and non GUI environment. I would
> think it would be much more useful to have good rugged applications
> in which most of the brain power went to make them work properly rather
> than to produce an artistic experience that sometimes does weird things that
> nobody seems to be able to reproduce or explain. The gcc compiler is a
> wonderful piece of design and I must pinch myself to realize that it
> is free, especially when you think of the time that must have gone in to it.
> There is also a debugger called gdb that is also free and it also works
> in a text-based environment.
I agree wholeheartedly. I only use XWindows for applications which require
a graphical environment such as Netscape and the Gimp, and I don't think a
PIC development environment is one of those things. If people want to
develop a GUI IDE (or better, adapt one of the existing ones to PICs), I
think it's a great idea, but all the basic tools such as assemblers,
compilers, etc. should have a command line interface. It isn't difficult
to run a graphical front end on top of a command line tool, or even write
the tool so that (like emacs) it checks for the presence of X when it
starts up, and runs in X mode if possible or text mode if not.
--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
---------- http://www.geocities.com/CapeCanaveral/Lab/1532/ ---------
Generally, Linux binary compatibility is given, if
- both systems (source & target) having both a.out (very obsolete) or ELF
format
- both have the same libc version and the associated stuff. It is not very
hard as downward compatibility is ensured.
What do you mean with "unix wizard"? I'm working for 3 years with Linux,
and there is no wizard. None.
Regards,
Imre
On Sat, 6 Jun 1998, William Chops Westfield wrote:
> What is Linux/FreeBSD/NetBSD binary compatibility like? Traditionally,
> a major problem with releasing "unix" tools is that there are a billion
> varieties of unix, and it frequently takes source AND a unix wizard to
> produce a running binary for anything different than the developer's version.
>
> BillW
>
>
What do you mean with "unix wizard"? I'm working for 3 years with Linux,
and there is no wizard. None.
In this case, a "unix wizard" would be someone familiar enough with the
version of unix running on their system AND other versions, so that they
can modify make files and/or source code so that the "free source" they
got will actually work on their system.
In a day and age where some (many?) unix systems are provided with no C
compiler included, this is far from a given. Distributing source is NOT a
panacea toward universal usability. (Having just gone through a sunos to
solaris "upgrade" that has left my (text mode) mail reader with mysterious
bugs that no one is likely to fix...)
There is a 3rd requirement for binary compatibility:
- both source and target platforms must have the same architecture (e. g.
i386 family).
As I have experienced, the Makefile -s and the configure scripts are
playing a role for an unix wizard. However, it does not hurt if the user
her/himself has an idea about unix/linux. Linux developes rapidly and the
unconveniences of the former state have almost completely disappeared, so
for such complicated systems as Netscape or RLab or rvaudio etc. the
binary compatibility IS ensured.
Regards,
Imre
On Sun, 7 Jun 1998, William Chops Westfield wrote:
> What do you mean with "unix wizard"? I'm working for 3 years with Linux,
> and there is no wizard. None.
>
> In this case, a "unix wizard" would be someone familiar enough with the
> version of unix running on their system AND other versions, so that they
> can modify make files and/or source code so that the "free source" they
> got will actually work on their system.
>
> In a day and age where some (many?) unix systems are provided with no C
> compiler included, this is far from a given. Distributing source is NOT a
> panacea toward universal usability. (Having just gone through a sunos to
> solaris "upgrade" that has left my (text mode) mail reader with mysterious
> bugs that no one is likely to fix...)
>
> BillW
>
>
Martin McCormick <EraseMEmartinspamspamBeGoneDC.CIS.OKSTATE.EDU> Wrote:-
> I certainly hope that if linux versions of PIC software are
>developed, they can be happy in a GUI and non GUI environment. I would
>think it would be much more useful to have good rugged applications
>in which most of the brain power went to make them work properly rather
>than to produce an artistic experience that sometimes does weird things that
>nobody seems to be able to reproduce or explain. The gcc compiler is a
>wonderful piece of design and I must pinch myself to realize that it
>is free, especially when you think of the time that must have gone in to it.
>There is also a debugger called gdb that is also free and it also works
>in a text-based environment.
>
> Shouldn't we have a choice? The whole idea of computing is that
>there is more than one way to skin a cat and the end result is what matters.
>
> Why even bother if the end result is a choice between GUI or GUI?
>
---------------------------------------------------------------------
I would like to add my support to the development of an open source
PIC development system, there seems to be enough list members
running linux to make this a worthwhile project...count me in!
As far as the user interface is concerned, it would be best to
have as much flexibilty as possible.
1. command line driven interface
2. character cell style interface (ie. doesn't need X)
3. GUI interface Qt/KDE or whatever..(GNOME?)
These are not incompatible objectives. Although I prefer KDE :-)
1. What is needed to start the ball rolling?
2. Specifications?... What about mplab functionality as a minimum.
3. Should discussion be on a seperate list? (probably!)
4. What open source pic assemblers/compilers are already available?
The ONLY thing I would insist on is standard MPASM mnemonics!
restall.net. This of course presumes that
