headers
Bob Axtell | 1 Sep 01:51
Picon

Re: [PIC] C Compiler

"So, David, my advice is stick with assembly.  If you have to learn
something, let it be something that can expand on what you
already know and practice.  However, the ultimate decision is up to you."

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

I own a copy of Mikro Pascal and an ancient copy of CCS C.

I am embarassed to say that in over 30+ years of development, not even
ONCE was the commercial firmware written in a HLL. That does NOT mean
I didn't try. I just didn't feel that the commercial HLL was "stable
enough".

As hard as assembler is to write, HLL is rarely better or faster
overall, but you can "whip up" something in short order. But I always
want to know, CLEARLY, how each routine actually worked. Sometimes it
seemed pretty odd how the result was derived.

Just because you are using an HLL does NOT mean that you are magically
doing everything right. You may have misunderstood the firmware specs
and already have a mess, regardless of the language. Or, maybe you
have still installed a small bug somewhere; it STILL has to be rooted
out aqnd killed.

If I were starting over, I'd do the same thing: learn the hardware in
assembly, then, later, move to C.

--Bob
--

-- 
http://www.piclist.com PIC/SX FAQ & list archive
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vitaliy | 1 Sep 02:13

Re: [PIC] C Compiler

Bob Axtell wrote:
> "So, David, my advice is stick with assembly.  If you have to learn
> something, let it be something that can expand on what you
> already know and practice.  However, the ultimate decision is up to you."
>
> -------------
>
> I own a copy of Mikro Pascal and an ancient copy of CCS C.
>
> I am embarassed to say that in over 30+ years of development, not even
> ONCE was the commercial firmware written in a HLL. That does NOT mean
> I didn't try. I just didn't feel that the commercial HLL was "stable
> enough".
>
> As hard as assembler is to write, HLL is rarely better or faster
> overall, but you can "whip up" something in short order. But I always
> want to know, CLEARLY, how each routine actually worked. Sometimes it
> seemed pretty odd how the result was derived.
>
> Just because you are using an HLL does NOT mean that you are magically
> doing everything right. You may have misunderstood the firmware specs
> and already have a mess, regardless of the language. Or, maybe you
> have still installed a small bug somewhere; it STILL has to be rooted
> out aqnd killed.
>
> If I were starting over, I'd do the same thing: learn the hardware in
> assembly, then, later, move to C.

FWIW, all of our production code for the PIC was written in C. I have never 
really written anything worth mentioning in assembly.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vitaliy | 1 Sep 02:24

Re: [PIC] C Compiler

Olin Lathrop wrote:
> Isaac Marino Bavaresco wrote:
>> For some very critical cases the assembly language may be better, but
>> if
>> the object code fits in the program memory, it doesn't matter if it
>> takes 50%, 70% or even 80% of the memory.
>
> It does if it's a high volume project and a cheaper processor could have
> been used.

Olin -- out of curiosity, what was the highest volume project you've ever 
worked on? 100k, 1M, 10M, 100M?

Vitaliy 

--

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Permalink | Reply | 1 comment |
headers
Tony Vandiver | 1 Sep 02:36

Re: [PIC] ZeroG

no, waiting on  mine too...

Vitaliy wrote:
> Tony Vandiver wrote:
>   
>> Has anyone played with the ZeroG wireless development kit with the
>> explorer16 yet?
>>     
>
> I'll have to check to see if we received the order yet. Have *you* had a 
> chance to play with it? :-)
>
> Vitaliy 
>
>   
--

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Permalink | Reply | 0 comments |
headers
William "Chops" Westfield | 1 Sep 06:05
Picon

Re: [PIC] C Compiler

> It does if it's a high volume project and a cheaper processor could  
> have been used.

I dunno.  Judging by high volume consumer gear, the price of chips  
doesn't have a lot to do with the product price.  If you have THAT  
high a volume, apparently you start negotiating with manufacturers for  
lower prices on the chips.  Thus a high-volume consumer digital camera  
costs less than a microcontroller "evaluation board" even though the  
former has chips that dwarf the complexity of the latter, and wouldn't  
even be purchasable in low volumes...

In this case (FAT filesystem on a flash card) using a high level  
language has an advantage I haven't seen explicitly stated yet.  Since  
most of the "complexity" of the problem is external to the PIC itself,  
the advantages of dealing directly in assembler are lessened AND the  
PORTABILITY of the code is VERY MUCH IMPROVED by being in C.  (In many  
cases, portability is not important, because the application is so  
inherently chip-specific anyway.  But this isn't one of them.)  You  
could write some carefully portable C code (an art in itself, alas)  
that would work on your initial selection of a 16F628 chip, and be  
nearly-instantly installed on an 18F chip when you discover you need a  
lot more program space, or on a 24F chip when you discover you need  
more speed, or on a freescale chip if Microchip pisses you off and you  
decide to switch vendors (although usually it seems to go the other  
direction :-)

That said, a FAT file system isn't THAT complex, and an implementation  
written in assembler should be pretty doable by someone with  
experience.  And I would think that there would be a lot of people  
interested in seeing the resulting code, especially if it turns out to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marechiare | 1 Sep 08:38
Picon

Re: [EE] Ultrasound at .0001 inches was: Measuring analog pulsesdownto 8 nano-seconds.

>> He didn't say the frequency is constant.
>
> Actually he started by asking about measuring individual
> pulses.  I am really skeptical that is going to work.

Yes, a single pulse will produce an oscillating pattern in air.

>> Thus he could vary the
>> frequency of the sine during the mesarument, get the analog
>> difference signal, digitize it, and then using math, based on
>> many points, calculate the frequency of ZERO PHASE SHIFT.
>
> It's a little unclear what you are saying, but using multiple frequencies
> and measuring the phase delay of each relative to some reference is probably
> the best way to measure distance via sound.

I meant continuosly varying the frequency with the step 0.1% and
catching (calculating) the moment when the received signal will be of
the same phase as the reference signal (sent signal). This would mean
that the the time to propagate the parth is the whole number of
periods for the found frequency plus some constant latency..

The analog difference between the two signals will produce zero signal
(teoretically). This moment is much easier to be caught than just
trying to figure out the real phase shift at that level of precision .

>> ... generated by 100 mHz DAC.
>
> Huh?  100 millihertz is way way too low for the tiny systems the OP was
> describing.  Think of the size of the transducers you'd need to get any
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sean Breheny | 1 Sep 16:42
Picon
Favicon

Re: [EE] Ultrasound at .0001 inches was: Measuring analog pulsesdownto 8 nano-seconds.

I think perhaps instead of DAC (Digital to Analog Converter) you mean
DDS (Direct Digital Synthesizer). I say this because varying the clock
of a DAC does not necessarily vary the frequency of the signal it
outputs.

Sean

On Tue, Sep 1, 2009 at 2:38 AM, Marechiare<marechiare <at> gmail.com> wrote:
>>> ... generated by 100 mHz DAC.
>>
>> Huh?  100 millihertz is way way too low for the tiny systems the OP was
>> describing.  Think of the size of the transducers you'd need to get any
>> meaningful amount of air to move when one cycle takes 10 seconds.
>
> That was a typo, sorry. I meant that the DAC would be clocked at 100
> megahertz. And its output at, say, 1000 steps would be 100 kilohertz
> sine wave. At the sound path equal to 10 wave lengths the 10% change
> in the DAC frequency (and also in wave lengh) would produce full
> period phase shift on the received signal in regard to the reference
> signal.
>
> The change in the distance to the object of 0.1 wavelength would cause
> the phase shift 0.2 period. To get the phase shift back to full period
> he would change the number of clocks per DAC period by 20%, that is
> 200 steps. Thus the 1 step change in number of DAC clocks per period
> would correspond to 0.1 * 3mm / 200 = 0.0015mm change in distance.
>
> Also he can fix the number of DAC steps per period and vary the DAC
> clock frequency. What's better depends on the app specs.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
AGSCalabrese | 1 Sep 17:17
Picon

Re: [EE] Optical Interferometry was: Ultrasound at .0001 inches was: Measuring analog pulses down to 8 nano-seconds.

>
>
> Seriously, anyone doing this kind of contactless distance  
> measurement is
> using optical interferometry. A laser diode, a beam splitter, a corner
> reflector and a pair of phototransistors with a quadrature decoder  
> to count
> fringes.
>
> Now, the OP did say "resolution" and not "accuracy", so maybe there  
> isn't
> a requirement for measuring the total span accurately, just changes in
> distance.
>
> -- Dave Tweed

Dave
Could you tell me more about practical optical interferometry ?  Have  
you built such a device ?  Are there parts or kits to do this that  
cost less than $100 / $200 / $500 / ??? to do this ?  Are there any  
diagrams showing this setup ?
Best
Gus
--

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Permalink | Reply | 1 comment |
headers
Dave Tweed | 1 Sep 17:56

Re: [EE] Optical Interferometry

AGSCalabrese wrote:
> Dave wrote:
> > Seriously, anyone doing this kind of contactless distance measurement
> > is using optical interferometry. A laser diode, a beam splitter, a
> > corner reflector and a pair of phototransistors with a quadrature
> > decoder to count fringes.
> >
> > Now, the OP did say "resolution" and not "accuracy", so maybe there  
> > isn't a requirement for measuring the total span accurately, just
> > changes in distance.
> 
> Could you tell me more about practical optical interferometry ?  Have  
> you built such a device ?  Are there parts or kits to do this that  
> cost less than $100 / $200 / $500 / ??? to do this ?  Are there any  
> diagrams showing this setup ?

No, I've never done one. I just know they're used in systems like the
photoplotters used to produce PCBs. They have 0.0001" accuracy in 2D
over several feet in both directions.

The basic concept is illustrated here:

http://en.wikipedia.org/wiki/Michelson_interferometer

and further information here:

http://en.wikipedia.org/wiki/Optical_interferometry

It looks like Agilent might be a good place to start:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marechiare | 1 Sep 19:25
Picon

Re: [EE] Ultrasound at .0001 inches was: Measuring analog pulsesdownto 8 nano-seconds.

> I think perhaps instead of DAC (Digital to Analog
> Converter) you mean DDS (Direct Digital Synthesizer).
> I say this because varying the clock of a DAC does not
> necessarily vary the frequency of the signal it outputs.

Yes.
--

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Permalink | Reply | 0 comments |

Gmane