Searching \ for '[PIC] PIC development under Linux with Wine' 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/microchip/devices.htm?key=pic
Search entire site for: 'PIC development under Linux with Wine'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] PIC development under Linux with Wine'
2005\05\22@220501 by Chen Xiao Fan

face
flavicon
face
Over the weekend, I think my exploration of Linux as a MCU
and electronics development platform has made a significant
progress.

1. Linux environment:
Ubuntu 5.04 Hoary + Winetools from Winehq.
(http://www.winehq.org/site/download-deb)

Please follow the instructions of Winetools and install the
following program before proceeding.
DCOM98
IE6
Windows Core Fonts
Windows System Software (MFC42.dll, VB5/VB6 runtime, etc)

You can also install other supported tools as well.

2. Status on PIC development:
Please note I have not done a thorough testing.
1) MPLAB 7.10 (full install) installs okay. But it failed
to recognize the integrated tools due to problem with pipes
(IPC or named pipe? I confess I do not understand the meaning).
2) MPLAB 5.70 installs okay. I have not tried it yet.
3) MPASMWIN from 7.10 and 5.70 works without any problem.
4) MPLAB C18 2.40 student edition fails to install. However
copying the installation from Windows and then setting up
the environment variables (PATH and MCC_INCLUDE) make
it work without any problem.
5) MPLAB C30 1.32 60day demo version installs and seems to
work. I need to try it further
6) There seems to be no USB support under Wine. Therefore
PICKit 1 applications fails to work even though the installation
is okay. As such, MPLAB ICD2 will not work if using
USB interface. I have not tried ICD2 support using serial
port.
7) I do not have other development tools with me now
so I can not test them. Maybe someone else can try it
with Picstart Plus (already working using picp) and Promate
II/III. I doubt MPLAB ICE2000/4000 will work.

8) Hitech PICC Lite works under Linux so I do not want to
try the Windows version. I do know that the DOS IDE (htlpic)
does not work.
9) I will try PICC/PICC18 demo and dsPICC demo a bit later.

Sorry for the long post but I am quite happy with the progress.
Hopefully people will be encouraged by my experiment. I am
a Linux newbie so I guess others will do better than I.


Xiaofan




2005\05\22@222959 by Chen Xiao Fan

face
flavicon
face
For the next step, I would like to try some other tools
under wine as well.

1) Wisp 628 using Xwisp2. I guess it will work.

2) Wisp628 with EasyISP firmware and Olin's PC host program.
I guess it will work as well.

3) Olin's program environment (It fails to install since
Wine is emulating Windows 9x) but I have just unzip
the installation files and set up the environment variables.
I guess the command line tools will still work but I need to
learn make in order to make use of it.

4) To learn make so that I can use all the command line tools
which already works (MPASM, MPLAB C18 and MPLAB C30, Picc Lite).

5) ICD2 with serial port connection.

Maybe someone else can try it with Picstart Plus (already
working using picp) and Promate II/III. I doubt MPLAB
ICE2000/4000 will work.

I hope people will try other tools as well (Kitrus kits, CCS C,
CC5x, etc) and report their success (and failure) here. Thanks.

Xiaofan




2005\05\24@200954 by Chen Xiao Fan

face
flavicon
face
Some progress:
1) and 2): both not working

I was a bit too optimistic on the serial port support of
wine (or Windows serial API?) support of Wine.
However Wouter's Python based program works. However it
supports much less chips than Xwisp2.

I will still explore the serial support under Wine.

3) and 4): In progress. The problem with Olin's environment
under Linux is that it is written for Windows 2K/XP
and does not support Windows 9x which Wine supports
better. That being said, the command line tools should
work.

5) I will say it will not work given both Xwisp2 and
PIC_READ/PIC_PROG are not working. I will try it as
well.

LPLAB seems the only option here. Under Windows it
is able to communicate with ICD2 but I do not
have the supported firmware in place.

I have yet to try it under Linux. It also claims to
support Promate II and PicStart+.

Xiaofan



{Original Message removed}

2005\05\25@034037 by Jan-Erik Soderholm

face picon face
Chen Xiao Fan wrote :

> Some progress:
> 1) and 2): both not working
> I was a bit too optimistic on the serial port support of
> wine (or Windows serial API?) support of Wine.
> However Wouter's Python based program works. However it
> supports much less chips than Xwisp2.

"Supports" and "works" is not the same. I know at least a couple
of newer PICs that works with Wouter's tools but aren't
listed on Wouter's Wisp628/Xwisp pages.

> 3) and 4): In progress. The problem with Olin's environment
> under Linux is that it is written for Windows 2K/XP
> and does not support Windows 9x which Wine supports
> better.

Why would someone even concider using something
(only?) supporting something as old as Win98 ??

{Quote hidden}

Now, I can understand that fiddling with this could be
some fun as such, but, IMHO, it seems *much* easier
to just setup a W2K or WinXP box and go on with
"real" work...

Jan-Erik.

>
>
>
> {Original Message removed}

2005\05\25@043133 by Chen Xiao Fan

face
flavicon
face
Oh yes, I admit it is a bit fun. And there are people who
do not like Windows (not me though). Generally I agree with
you that for most of the people it would be better to set
up a Win2k/Xp box, buy a Wisp628/ICD2 and start the
the "real" work.

However, for me my "real work" is done in Windows in the
daytime and only a minor part of the work is dealing with
PIC. So why not spend some fun time after work on a different
platform? Maybe for me to fiddling with all these is
more "real" than browsing the internet and listening to
music. :) Wine is just an intermediate step. I will
hope more tools like LPLAB/GPutils/GPSim which are native
Linux applications. The best will be that Microchip
release MPLAB under Windows ( wait long long lah, people
in Singapore will say in Singlish).

As for Windows 98, it is a bit older but there are still
people and business using it or even older product. As a
matter of fact, my work PC was just upgraded to XP from
98SE one months ago. It is perfectly okay for Olin to
choose to support only 2K/XP though.

Xiaofan

{Original Message removed}

2005\05\25@081532 by olin_piclist

face picon face
Chen Xiao Fan wrote:
> As for Windows 98, it is a bit older but there are still
> people and business using it or even older product. As a
> matter of fact, my work PC was just upgraded to XP from
> 98SE one months ago. It is perfectly okay for Olin to
> choose to support only 2K/XP though.

Mostly I don't support Windows 9x because I use features in CMD.EXE that
don't exist in COMMAND.COM.  Also there are registry differences so the
Win2K procedure for defining environment variables won't work on all version
of Win9x.  This is the reason the installation program won't run correctly.
If you did manage to set up a Win9x installation manually, I expect the
executables would work.  I don't know anything about WINE, but PIC_PROG and
PIC_READ use generic Win32 calls to do serial I/O, so I expect that would
work.  I'm not doing anything unusual in that area that I know of.

All my host programs are actually written to a portability layer
specifically to allow easy porting to various operating systems.  That layer
has already been on Apollo Domain/OS, four old flavors of Unix, and Win32.
It should be relatively easy to create the low level layer for Linux.  I
just haven't had a good reason (paying customer) to do this yet myself.  If
anyone is seriously interested in having my stuff run on Linux, I would be
willing to make all the source code available and provide some guidance.
However, this will be some work on my end so I don't want to do this unless
someone is serious about it.  Once this is done, all my stuff will
automatically run on the new target operating system.


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

2005\05\25@094539 by Byron A Jeff

face picon face
On Wed, May 25, 2005 at 04:31:31PM +0800, Chen Xiao Fan wrote:
> However, for me my "real work" is done in Windows in the
> daytime and only a minor part of the work is dealing with
> PIC. So why not spend some fun time after work on a different
> platform? Maybe for me to fiddling with all these is
> more "real" than browsing the internet and listening to
> music. :)

Interesting point.

> Wine is just an intermediate step.

I hope so. I've been trying to use Wine for educational games
for nearly 10 years. It's never made any significant progress
in that area.

> I will hope more tools like LPLAB/GPutils/GPSim which are
> native Linux applications.

Well the begs a question: What other tools do you need to
develop under Linux/Mac? The last time I used a non native Linux
based tool for PIC development was running MPASM under DOSEMU.
That was before the advent of gpasm. So that must have been
about 8 years ago.

Most of us on the Linux/multiplatform side of things (Craig, Scott,
Brian Lane for awhile, Alain, Wouter (who is PythonMan! ;-) and
myself) have taken the approach that Open Source native applications
are the way to go. Olin has helped immensely by releasing
specifications and source for EasyProg.

> The best will be that Microchip
> release MPLAB under Windows ( wait long long lah, people
> in Singapore will say in Singlish).

I'm sure you meant "MPLAB under Linux". It'll never happen. And
that's because MPLAB is a tool that drives Microchip's core
business: selling PICs and other hardware.

And that's fine. None of the cross platform developers fault MChip for
that stance.

But I ask the question again: what functionality does MPLAB have that
you cannot find in other tools. At a casual glance I would say ICD
debugging support and possibly dsPIC support in gpasm.

But the toolset is there.

BAJ

2005\05\25@115354 by olin_piclist

face picon face
Byron A Jeff wrote:
> Olin has helped immensely by releasing
> specifications and source for EasyProg.

Does this mean you know of a Linux program to drive the EasyProg?  I am not
aware of anyone actually implementing their own software from the protocol
spec.  I would certainly like to know if this was done, and would be willing
to provide guidance for anyone trying to do this.


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

2005\05\25@140338 by Byron A Jeff

face picon face
On Wed, May 25, 2005 at 11:54:36AM -0400, Olin Lathrop wrote:
> Byron A Jeff wrote:
> >Olin has helped immensely by releasing
> >specifications and source for EasyProg.
>
> Does this mean you know of a Linux program to drive the EasyProg?  I am not
> aware of anyone actually implementing their own software from the protocol
> spec.  I would certainly like to know if this was done, and would be willing
> to provide guidance for anyone trying to do this.

I don't know of one yet. But you've created an environment where it can happen.

It's on my list of things to do. But I have a 2 ton roadblock, my dissertation,
standing inbetween me and pretty much anything else that I want to work on.

BAJ

2005\05\25@201319 by Chen Xiao Fan

face
flavicon
face
The component that MPLAB 7.1 under Wine does not work:
1) Support of project management: can be substituted by MAKE
2) Support for ICD2 for debugging and programming
3) Support for other hardware tools: Pickit 1 not working,
Promate II most likely not working due to broken Serial
support in Wine. MPLAB ICE2000/4000: no chance of working?

The component that MPLAB7.1 and other Microchip tools works
better than similar tools.
1) MPASM: majority of code is written in MPASM, not GPASM
2) MPASM 30: no counterpart in GPASM
3) MCC18: SDCC still has a long way to go. Hitech PICC18 under
Linux may be better but cost quite a lot. MCC18 has a free edition.
4) MPLAB C30: no counterpart yet. Even Hitech dSPICC 30 seems
very weak now (from the demo version). Microchip releases 60
day free version from time to time.
5) Faster support of new chips

Xiaofan

-----Original Message-----
From: Byron A Jeff [spam_OUTbyronTakeThisOuTspamcc.gatech.edu]
Sent: Wednesday, May 25, 2005 9:46 PM
To: Microcontroller discussion list - Public.
Subject: Re: [PIC] PIC development under Linux with Wine
...
But I ask the question again: what functionality does MPLAB have that
you cannot find in other tools. At a casual glance I would say ICD
debugging support and possibly dsPIC support in gpasm.

But the toolset is there.

BAJ

2005\05\25@202957 by Chen Xiao Fan

face
flavicon
face
WINE is a emulator for Windows or more than that.
http://www.winehq.org

The problem is that Wine Serial support is broken. It is still
remarkable that Wine has made so much progress. I will post the
error message for Xwisp2w and PIC_READ later.

To bad I know almost nothing of programming in Linux/Windows. :(

Xiaofan

{Original Message removed}

2005\05\26@004057 by Dave Lag

picon face
I gather there is considerable "inertia" with W98 users, especially
Asia. MS are preparing a $tripped XP to entice.
D

Chen Xiao Fan wrote:
........
> As for Windows 98, it is a bit older but there are still
> people and business using it or even older product. As a
> matter of fact, my work PC was just upgraded to XP from
> 98SE one months ago.
..............
>
> Xiaofan
>
> -----Original Message-----
> From: Jan-Erik Soderholm [.....jan-erik.soderholmKILLspamspam@spam@telia.com]
> Sent: Wednesday, May 25, 2005 3:41 PM
>
>
> Why would someone even concider using something
> (only?) supporting something as old as Win98 ??
............

> Jan-Erik.
>

2005\05\26@011148 by Lonnie

flavicon
face
Also in many businesses there is the need for one machine to support both a windows gui and a true dos mode. One example of this is Radio programming, the radio manufacturer is not willing to re-write the dos programming software for the older models, and the newer models require W9x so W98se is the best platform for this type of use.

----- From: "Dave Lag" <davescomputer@
To: "Microcontroller discussion list - Public." <piclistspamKILLspammit.edu>
Sent: Wednesday, May 25, 2005 11:42 PM
Subject: Re: [PIC] PIC development under Linux with Wine


{Quote hidden}

> --

2005\05\26@011752 by Chen Xiao Fan

face
flavicon
face
No business and nobody will use that $tripped XP. :)
Either they keep the old PCs with Win98SE or they
buy a new PC with Windows XP. Guess this is OT though.

Xiaofan

-----Original Message-----
From: Dave Lag [EraseMEdavescomputerspam_OUTspamTakeThisOuTrogers.com]
Sent: Thursday, May 26, 2005 12:42 PM
To: Microcontroller discussion list - Public.
Subject: Re: [PIC] PIC development under Linux with Wine


I gather there is considerable "inertia" with W98 users, especially
Asia. MS are preparing a $tripped XP to entice.
D

2005\05\26@045532 by Byron A Jeff

face picon face
On Thu, May 26, 2005 at 08:13:17AM +0800, Chen Xiao Fan wrote:
> The component that MPLAB 7.1 under Wine does not work:

Snipped.

> The component that MPLAB7.1 and other Microchip tools works
> better than similar tools.
> 1) MPASM: majority of code is written in MPASM, not GPASM

GPASM is written to be MPASM compatible. There's only a small handful of
exceptions.

> 2) MPASM 30: no counterpart in GPASM

I pointed out that one below.

> 3) MCC18: SDCC still has a long way to go. Hitech PICC18 under
> Linux may be better but cost quite a lot. MCC18 has a free edition.

That's another one I hadn't thought of.

> 4) MPLAB C30: no counterpart yet. Even Hitech dSPICC 30 seems
> very weak now (from the demo version). Microchip releases 60
> day free version from time to time.

I thought that you built a C30 cross compiler for the DSPic. Did I
misread?

> 5) Faster support of new chips

That's simply a cost of doing non Windows business as MChip isn't going
to develop for anything other than Windows.

BAJ
>
> Xiaofan
>
> {Original Message removed}

2005\05\26@070557 by Alan B. Pearce

face picon face
>That's simply a cost of doing non Windows business as MChip
>isn't going to develop for anything other than Windows.

But they could do if they wanted, using tools such as Delphi/Kylix, or
similar C tool pairings. Sure it would have an initial hurdle to get it onto
a compatible compiler pair, but once there it would require minimal work to
do the cross development.

2005\05\26@080137 by Stef Mientki

flavicon
face


Alan B. Pearce wrote:

>>That's simply a cost of doing non Windows business as MChip
>>isn't going to develop for anything other than Windows.
>>    
>>
>
>But they could do if they wanted, using tools such as Delphi/Kylix, or
>similar C tool pairings. Sure it would have an initial hurdle to get it onto
>a compatible compiler pair,
>
I think that's an idefix,
or better said the difference between the free-world and the non-free-world.

If you write applications for the commercial world,
you want to achieve the maximum result with the minimum effort.

Therefor the following rules apply:
1. Writing for windows, catches 90..99% of the market.
2. Developping applications in Delphi is done most efficiently, by
buying as much components as you can. (I don't say the bought programs
are better then freeware, but the support in general is better and
you've more garantee for the future)
3. The guys who makes the components you buy in 2) also know rule 1)  
:-(  :-(

So commercial there's no interest at all, in what kind of surrounding
MASP (or what other tool) is running. Compare it to your desk, it
doens't matter whether you've a modern plastic desk, a woorden desk or
an old iron one, you just need pen,paper, communication and brains.If
necessary, place all different desks next to each other ;-)

Stef Mientki

2005\05\26@143611 by Peter

picon face

On Thu, 26 May 2005, Stef Mientki wrote:

{Quote hidden}

The commercial idea is to push down as many animations, tree widgets and
strange com bindings as possible because they 'look cool'. This is a
trend due to the people who buy the software, not the makers. There are
about 400 good reasons for a well written 4-letter command line program
with about 26 options and a 1000-line manpage to be more bug-free,
functional, and cheaper, not mentioning easier to write and debug (and
port, and use once scripted), than a 26-function 65536-color 1.4 meg
(that passes for small now) gui program.

Peter

2005\05\30@202241 by Chen Xiao Fan

face
flavicon
face
Not me.

I came acorss the C30 cross compiler under Linux in
a Microchip Forum post.

http://forum.microchip.com/fb.asp?m=94243

You can download the package from the following
website. However, the libraries are missing.
http://noel.feld.cvut.cz/dspic/

It will take some more efforts to get the things
going. One thing is that the optimizer is closed
source. The other is the library.

Regards,
Xiaofan


-----Original Message-----
From: Byron A Jeff [byronspamspam_OUTcc.gatech.edu]
Sent: Thursday, May 26, 2005 4:56 PM
To: Microcontroller discussion list - Public.
Subject: Re: [PIC] PIC development under Linux with Wine

> 4) MPLAB C30: no counterpart yet. Even Hitech dSPICC 30 seems
> very weak now (from the demo version). Microchip releases 60
> day free version from time to time.

I thought that you built a C30 cross compiler for the DSPic. Did I
misread?

BAJ

2005\05\30@203533 by Chen Xiao Fan

face
flavicon
face
Some people are interested in the Simulator.
Here is the status.

1. Linux environment:
Ubuntu 5.04 Hoary + Winetools from Winehq.
(http://www.winehq.org/site/download-deb)

2. More status report

1) C30 assembler, compiler, linker and simulator are working.
I've tried the examples under
"C:\Program Files\Microchip\MPLAB C30\examples".
All the batch files work under Wine. So the C30
tool chain works, including the command line simulator (sim30.exe).

2) MPLAB simulator for Pic16/Pic18
The IDE is not working. The assembler and linker are both
working. However you can not assemble your program in
the MPLAB IDE.

The only way for simulating is to import the hex file
and step through the program memory. Source level debugging
is not working now.

Regards,
Xiaofan

2005\05\30@205538 by Chen Xiao Fan

face
flavicon
face
For those who are using the tools from Mikroelektronika
(Basic, Pascal and C compiler for PIC16/dsPIC
http://www.mikroelektronika.co.yu/), there is some good
news as well.

It seems to me both the IDE and compiler works. I only
tried the demo version of mikroPascal and mikroBasic
under Wine. Please take note that I have just done
a very simple test and I have never used the compiler
before.

Regards,
Xiaofan

2005\05\31@023212 by Shawn Tan Ser Ngiap

flavicon
face
On Tuesday 31 May 2005 01:22, Chen Xiao Fan wrote:
> You can download the package from the following
> website. However, the libraries are missing.
> http://noel.feld.cvut.cz/dspic/

Yeah, I had the same problem when I compiled it from source.. Whenever I try
to compile something, it says it's missing -lpic30... but it was possible to
compile it to assembly, and then assemble it manually... Just that it'd lose
the built in library functions..

cheers..

--
with metta,
Shawn Tan

2005\05\31@051551 by Chen Xiao Fan

face
flavicon
face
Therefore now you can only use Wine if you want to carry out
real dsPIC development under Linux.

The C30 tool chain works fine in Wine. You have everything:
the compiler, the linker, the hex file generation utility,
the simulator and the library. The only catch is that it
is only a demo version and will time out 60 days later.

Regards,
Xiaofan

{Original Message removed}

2005\05\31@054712 by Alan B. Pearce

face picon face
>The C30 tool chain works fine in Wine. You have everything:
>the compiler, the linker, the hex file generation utility,
>the simulator and the library. The only catch is that it
>is only a demo version and will time out 60 days later.

Has anyone tried to reload it to see if that resets the demo period like the
C18 compiler?

Not got to use the dsPic yet, so haven't been through the loop.

2005\05\31@194856 by Chen Xiao Fan

face
flavicon
face
No, it will not reset the demo period if in the similar
version (eg: from 1.31 to 1.32).

I think it reset the period if you upgrade from 1.2x
to 1.3x but I am not so sure.

Xiaofan

{Original Message removed}


'[PIC] PIC development under Linux with Wine'
2005\06\22@201834 by Chen Xiao Fan
face
flavicon
face
Just a small update on my Wine testing, Olin's prepic
utility works well under wine.

1. Linux environment:
Ubuntu 5.04 Hoary + Wine + Winetools
2. MPLAB 7.11 (install okay after installing IE6)
3. Embedinc PIC development tools (simply unzip or
just copy from Windows patitiion).
4. Set up environment variables under Wine
5. The batch file from Olin is not working under Wine.
Therefore I was using Make to get it working.
6. The makefile I posted in the thread "RE: [PIC] Makefile
for EasyISP" works under Wine (in the Wine command prompt
simulation environment, simply type 'dos' in the bash
prompt and you will get into it).

It may be better to use the native Linux programs
like gputils and only call prepic.exe from Make
(outside the Wine command prompt simulation environment),
just like what people have done with MPLAB C18. But
I need to tweak my makefile (I just start to learn to
use Make).

Regards,
Xiaofan

2005\06\22@202217 by Chen Xiao Fan

face
flavicon
face
Now that Olin's pascal environment is really working. I look
at the c files generated and they look quite standard. Maybe
some capable person can start to port Olin's host software
to Linux and other OS. Of course it will take some time and
effort to do that.

Regards,
Xiaofan

{Original Message removed}

2005\06\22@210630 by olin piclist

face picon face
Chen Xiao Fan wrote:
> Now that Olin's pascal environment is really working. I look
> at the c files generated and they look quite standard. Maybe
> some capable person can start to port Olin's host software
> to Linux and other OS. Of course it will take some time and
> effort to do that.

It will take some effort, but maybe not as much as you think.  All my host
stuff sits atop a platform independent interface.  This was done
deliberately to make porting easy.  There is a minimum set of routines that
need to be implemented, mostly in the SYS and FILE libraries and a few in
the STRING library.  SST (used to translate Pascal to C) may need to be
tweaked for the particular target C compiler.  Once this is done, everything
else will just work, including all the PICPRG code.

This OS portability layer has already been to four different flavors of
Unix, although a long time ago.  I think I gave away my last Unix machines
about 5 years ago because I hadn't used them for a few years before that,
and they were old then.


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

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