> >Didn't Jan-Erik do this a few years ago?
>
> I don't know who originaly wrote the PIC ASM
> wordlist, but the Ultraedit web has had hundreds of
> wordlists (including PIC ASM) available for download
> ever since I started using it many years ago.
> Perhaps the OP means they are putting the PIC ASM
> wordlist into the default install?
>
> Regards
>
> Mike
>
>

> This e-mail is intended for the person it is
> addressed to only. The
> information contained in it may be confidential
> and/or protected by
> law. If you are not the intended recipient of this
> message, you must
> not make any use of this information, or copy or
> show it to any
> person. Please contact us immediately to tell us
> that you have
> received this e-mail, and return the original to us.
> Any use,
> forwarding, printing or copying of this message is
> strictly prohibited.
> No part of this message can be considered a request
> for goods or
> services.
>

>
> On 7/19/06, John Chung <KILLspamkravnusKILLspamyahoo.com> wrote:
> > If you are using Ultraedit, PIC asm code now has
> > color. Finally!
> >
> >
> www.ultraedit.com/index.php?name=Content&pa=showpage&pid=40#wordfiles
> >
>
> Back in the MPLAB 5.x days, MPLAB editor is not so good. Now
> MPLAB editor is good enough for ASM/C editing for PIC development.
> I think the reason for using Ultraedit is not as great as before
> even though I like the column editing mode and the integrated file
> comparator.
>
> Now I do not have access to Ultraedit and I am exploring the
> alternatives. Programmer's Notepad / Crimson Editor seem to be
> quite okay. Under Linux, I like to use the simple gedit. Not so sure
> if it is available for Windows.
>
> Any other recommendations? I'd like the editor to support gcc/
> python/MPASM and maybe ARM C compilers and Keil C51.
>
> Regards,
> Xiaofan

>
> On 7/19/06, Tamas Rudnai <TakeThisOuTtamas.rudnaiEraseMEspam_OUTgmail.com> wrote:
> > VIM / GVIM ... not easy to learn, but once you get use to it you will
> never
> > ever would like to use 'standard' editors for programming. It has
> millions
> > of features, syntax highlighting, has console/terminal interface as well
> as
> > GUI. I could talk a lot about this but would have been a bit off-topic
> :-)
> >
> > Regards,
> > Tamas
>
> Installed gvim under Windows once and I do not like it. I do not need
> tons of features but it does not seem to support Column Mode editing
> (maybe I did not dig deep enough). Under Linux, I still occasionally using
> vi in the console but now I prefer pico and still use gedit the most.
>
> Regards,
> Xiaofan

>
> James Newton, Host wrote:
> > but is open source (in MASM, Windows 32 bit assembly (yes,
> > assembly))
>
> While I think assembly is often a good answer for PICs and other small
> processors, I think this is silly.  The x86 compilers are heavily used,
> very
> solid, and do a very good job of optimization.  This editor may be fast,
> but
> I seriously doubt there would be any noticeable difference if it were
> competently written in C.
>
> > Assembly isn't just for PIC's!
>
> But it should be, or at least for small resource-limited processors or
> otherwise very exceptional cases.  There are a few cases where assembly is
> used on PC systems, but they are quite rare for good reason.  The only
> case
> I'm familiar with is a small part of the graphics driver of a major
> graphics
> chip vendor.  This is a piece of code that really can be called 100s of
> millions of times when performance is critical.  Assembly allowed making
> optimum use of the floating point processor and the new (at the time) MMX
> instructions.  Even then, assembly was limited to the 3D floating point
> critical path routines.  There just isn't any advantage for "normal" code
> on
> a PC.
>
>
> ******************************************************************
> Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
> consultant in 2004 program year.  http://www.embedinc.com/products

> James Newton, Host wrote:
> > but is open source (in MASM, Windows 32 bit
> assembly (yes,
> > assembly))
>
> While I think assembly is often a good answer for
> PICs and other small
> processors, I think this is silly.  The x86
> compilers are heavily used, very
> solid, and do a very good job of optimization.  This
> editor may be fast, but
> I seriously doubt there would be any noticeable
> difference if it were
> competently written in C.
>
> > Assembly isn't just for PIC's!
>
> But it should be, or at least for small
> resource-limited processors or
> otherwise very exceptional cases.  There are a few
> cases where assembly is
> used on PC systems, but they are quite rare for good
> reason.  The only case
> I'm familiar with is a small part of the graphics
> driver of a major graphics
> chip vendor.  This is a piece of code that really
> can be called 100s of
> millions of times when performance is critical.
> Assembly allowed making
> optimum use of the floating point processor and the
> new (at the time) MMX
> instructions.  Even then, assembly was limited to
> the 3D floating point
> critical path routines.  There just isn't any
> advantage for "normal" code on
> a PC.
>
>
>

>
> In most PC application assembly is not required. Less
> and less ppl know what is assembly. Thank the Unis for
> that. HLL compiler can do a pretty good job but when
> it comes to computational stuff like video decoding
> and encoding assembly helps. Suprisingly we use quite
> a few assembly dll in our machine. From video to audio
> playback.
>
> I have to agree with Olin here. When it comes to
> calling the UI api, assembly has no advantage here.
> There might be *some* improvement but not noticable.
> There are functions within the editor that may benefit
> from assembly like the *search* function.
>
> John
>
>
>
> --- Olin Lathrop <RemoveMEolin_piclistspam_OUTKILLspamembedinc.com> wrote:
>
> > James Newton, Host wrote:
> > > but is open source (in MASM, Windows 32 bit
> > assembly (yes,
> > > assembly))
> >
> > While I think assembly is often a good answer for
> > PICs and other small
> > processors, I think this is silly.  The x86
> > compilers are heavily used, very
> > solid, and do a very good job of optimization.  This
> > editor may be fast, but
> > I seriously doubt there would be any noticeable
> > difference if it were
> > competently written in C.
> >
> > > Assembly isn't just for PIC's!
> >
> > But it should be, or at least for small
> > resource-limited processors or
> > otherwise very exceptional cases.  There are a few
> > cases where assembly is
> > used on PC systems, but they are quite rare for good
> > reason.  The only case
> > I'm familiar with is a small part of the graphics
> > driver of a major graphics
> > chip vendor.  This is a piece of code that really
> > can be called 100s of
> > millions of times when performance is critical.
> > Assembly allowed making
> > optimum use of the floating point processor and the
> > new (at the time) MMX
> > instructions.  Even then, assembly was limited to
> > the 3D floating point
> > critical path routines.  There just isn't any
> > advantage for "normal" code on
> > a PC.
> >
> >
> >
> ******************************************************************
> > Embed Inc, Littleton Massachusetts, (978) 742-9014.
> > #1 PIC
> > consultant in 2004 program year.
> > http://www.embedinc.com/products
> > --

> The same happens here in the PICs world: recently
> just disassembled a HEX
> file which I did not have the source and realised
> that the whole code was
> written in HLL, most possibly in C. The code almost
> not fit in the 2K
> program memory, and I started to thinking how could
> I rewrite it, it seems
> that 256 prg mem would be ok for the same job. But
> who cares? The bigger PIC
> is only few cents more expensive...
>

> It is also comparable to the electronics design:
> Let's say you would like to
> produce an mp3 player that stores files in a flash,
> play mp3 in it and you
> can upload the files using USB, right? In low level
> point of view (assembly)
> you have to design the whole: how to decode mp3
> music, how to connect to the
> usb port, read lot of docs on mp3 decodings, fat
> filesystem, usb stuff etc.
> In high level point of view: you buy the mp3 decoder
> chip and the usb
> capable PIC and basically that's it, just have to
> put the things together.
> Like a configurator, not a developer.
>

>
>
> On 21/07/06, John Chung <EraseMEkravnusspamspamBeGoneyahoo.com> wrote:
> >
> > In most PC application assembly is not required.
> Less
> > and less ppl know what is assembly. Thank the Unis
> for
> > that. HLL compiler can do a pretty good job but
> when
> > it comes to computational stuff like video
> decoding
> > and encoding assembly helps. Suprisingly we use
> quite
> > a few assembly dll in our machine. From video to
> audio
> > playback.
> >
> > I have to agree with Olin here. When it comes to
> > calling the UI api, assembly has no advantage
> here.
> > There might be *some* improvement but not
> noticable.
> > There are functions within the editor that may
> benefit
> > from assembly like the *search* function.
> >
> > John
> >
> >
> >
> > --- Olin Lathrop <RemoveMEolin_piclistKILLspamembedinc.com>
> wrote:
> >
> > > James Newton, Host wrote:
> > > > but is open source (in MASM, Windows 32 bit
> > > assembly (yes,
> > > > assembly))
> > >
> > > While I think assembly is often a good answer
> for
> > > PICs and other small
> > > processors, I think this is silly.  The x86
> > > compilers are heavily used, very
> > > solid, and do a very good job of optimization.
> This
> > > editor may be fast, but
> > > I seriously doubt there would be any noticeable
> > > difference if it were
> > > competently written in C.
> > >
> > > > Assembly isn't just for PIC's!
> > >
> > > But it should be, or at least for small
> > > resource-limited processors or
> > > otherwise very exceptional cases.  There are a
> few
> > > cases where assembly is
> > > used on PC systems, but they are quite rare for
> good
> > > reason.  The only case
> > > I'm familiar with is a small part of the
> graphics
> > > driver of a major graphics
> > > chip vendor.  This is a piece of code that
> really
> > > can be called 100s of
> > > millions of times when performance is critical.
> > > Assembly allowed making
> > > optimum use of the floating point processor and
> the
> > > new (at the time) MMX
> > > instructions.  Even then, assembly was limited
> to
> > > the 3D floating point
> > > critical path routines.  There just isn't any
> > > advantage for "normal" code on
> > > a PC.
> > >
> > >
> > >
> >
>

>
> Tamas Rudnai wrote:
> > Maybe I have to open a new topic on how do you measure pulse with
> > modulation signal between 1-2 ms reliable using 10F200 :-)
>
> You could set the timer 0 prescaler to 8, which would result in 125
> increments in 1mS.  There is a 3 cycles uncertainty in measuring the start
> of the pulse and another 3 cycles measuring the end, for a total of 6uS
> error.  It looks like overall you get about 1% accuracy.  I imagine that's
> good enough for many applications, especially if this part is inside a
> higher level control feedback loop.
>
>
> ******************************************************************
> Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
> consultant in 2004 program year.  http://www.embedinc.com/products

>
> But still, if you use C for PIC programming, can you
> make a cross-PIC code
> that measures digital signals, A/D conversions, USB
> access so that you can
> compile / put that program to many different chips?
> I have never seen PIC
> independent program, but pretty much interested, if
> there is any articles
> and/or sources codes?
>
> Thanks,
>  Tamas

>
> Tamas Rudnai wrote:
> > That would be ok for me, however, the max length of the signal is
> > around 2 ms,
>
> But you said that the minimum length is 1mS, so you are only really
> measuring 1 mS.  You measure the length of the pulse, which in theory gets
> you 125 to 250, then subtract off the 125 fixed part.  I would do a check
> for large values above 200 or so that are really negative in this context
> (pulse was shorter than 1mS) and clip the resulting value to 0.
>
>
> ******************************************************************
> Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
> consultant in 2004 program year.  http://www.embedinc.com/products

>
> I assume that you mean by PIC independant code? If so
> you use wrappers around it. That is how I would
> attempt it. In short, don't use the memory directly
> but use an identifier for it which can be reassigned
> to other values for diff. PIC.
>
> John
>
> PS: Such function like A/D conversion may require you
> to evaluate the machine code for the function in your
> HLL that use it. The acqusition and conversion time
> needs to be taken into account. HLL can do it well but
> needs tender care :(
>
>
>
> >
> > But still, if you use C for PIC programming, can you
> > make a cross-PIC code
> > that measures digital signals, A/D conversions, USB
> > access so that you can
> > compile / put that program to many different chips?
> > I have never seen PIC
> > independent program, but pretty much interested, if
> > there is any articles
> > and/or sources codes?
> >
> > Thanks,
> >  Tamas
> > --

> I agree, but using cblock, equ, call-retlw
> (functions), macros etc.. I can
> do the same with asm, can't I? So that if the asm
> program well structured
> and designed to port to other PICs in mind then it
> is pretty much the same
> as using macros and functions / libraries for HLL,
> isn't it?
>
> Tamas
>
>
> On 21/07/06, John Chung <spamBeGonekravnusKILLspamyahoo.com> wrote:
> >
> > I assume that you mean by PIC independant code? If
> so
> > you use wrappers around it. That is how I would
> > attempt it. In short, don't use the memory
> directly
> > but use an identifier for it which can be
> reassigned
> > to other values for diff. PIC.
> >
> > John
> >
> > PS: Such function like A/D conversion may require
> you
> > to evaluate the machine code for the function in
> your
> > HLL that use it. The acqusition and conversion
> time
> > needs to be taken into account. HLL can do it well
> but
> > needs tender care :(
> >
> >
> >
> > >
> > > But still, if you use C for PIC programming, can
> you
> > > make a cross-PIC code
> > > that measures digital signals, A/D conversions,
> USB
> > > access so that you can
> > > compile / put that program to many different
> chips?
> > > I have never seen PIC
> > > independent program, but pretty much interested,
> if
> > > there is any articles
> > > and/or sources codes?
> > >
> > > Thanks,
> > >  Tamas
> > > --