Tech support gone

Started by Trampas July 15, 2004

What is up with all of Microchip’s tech support shutting down for a week? I guess it is a bad week to be a Microchip customer, especially when you are like me and have problems…

 

Regards,

Trampas





Many semiconductor companies have an annual cost saving shutdown.
By making it exactly one week, nobody can draw unemployment becuase
the time they lost was all in the same pay period. If they did the
closing beginning on Friday of one week and continued into the next
week, unemployment benefits would be available for the time lost in
the second week.

Not to worry though, you will still have the problem when they get
back. Unless, of course, you want to post the question here. --- In , "Trampas" <tstern@n...> wrote:
> What is up with all of Microchip's tech support shutting down for
a week? I
> guess it is a bad week to be a Microchip customer, especially when
you are
> like me and have problems. >
> Regards,
>
> Trampas




On Thu, 15 Jul 2004 09:05:37 -0400, Trampas wrote:
>What is up with all of Microchips tech support shutting down for a
>week? I guess it is a bad week to be a Microchip customer, especially
>when you are like me and have problems&

Microchip Masters Conference starts this next week and they are all
teaching classes and running the show there... It pretty much eats up
their entire week.

I've been to a couple of the Masters conferences and they are great.
You get to actually meet and talk to the guys that develop the tools
and design the chips.

Matt Pobursky
Maximum Performance Systems



Well if you all want to hear some of my problems I will list some. I will
say that Microchip has improved on the MPLAB. Last year I was begging for a
command line programmer for the ICD2 as I could not get MPLAB to run long
enough to program a chip. Now they have it more stable, plus now they have
figure out how to determine how long the program is and only flash the
length of the program.

When I change the ICD2 to debug mode then try to program the dsPIC in debug
mode MPLAB crashes with memory at 0x0xxxx tried to access memory location
0x000000. Every once in awhile I can get past this error long enough to get
the program loaded onto the chip. So then I run the program and it says it
is running, however it never reaches any breakpoints. I then hit halt and I
can not find any method to figure out where in the code the debugger is
located.

When I try to use the DSP library for the dsPIC especially the
FFTComplexIP() function, it will sometimes reset the processor with out
calling a trap instruction. I can not debug further as that I can no access
the debugger. I have noticed that the problem seems to occur more often when
the chip is warm.

When I do get the FFTComplexIP() function to run and send it constant data,
each time it runs I get different output.

When I call the FFTComplex() function the data is repeatable, 99% of the
time. I think the problem here may be interrupts. However I have not figured
out using their C compiler to know what resources are being used in the ISR.
That is I have not figured out how to get the disassembly. This also brings
up another philosophical question in that how much assembly should you have
to know to use C? That is does Microchip expect their users/programmers to
compile in C then look at the disassembly to make sure the C compiler did
what it should? For example I would expect that the C compiler with out the
"fast interrupt" would save all resources which the routine used, like the
accumulators, etc.

I also have several issues with their documentation, for example I read the
family datasheet and the chip datasheet for the dsPIC and could not find the
bit mappings for the control registers. On the CD sent with the dsPIC
development board I could find no reference to these bit mappings. Only by
chance did I find a document on their website that had the bit mappings
documented.

When I try to use their VDI with MPLAB it will crash MPLAB if I close the
VDI window. If I leave the VDI window open it will crash MPLAB with some INI
file access problems. The only way to remove VDI from your project is to
uninstall VDI.

When trying to use the editor, I am use to most editors in the world where
you double click on a word and it will highlight the word. MPLAB's editor
sets the break points by double clicking, even if you have the debugger
turned off. MPLAB's editor's context sensitive coloring scheme is whacked
out, sometimes it thinks all the code is in one big comment, sometimes it
gets confused on strings and thinks the next line of code is a string. Regards,
Trampas
-----Original Message-----
From: Matt Pobursky [mailto:]
Sent: Saturday, July 17, 2004 12:12 AM
To:
Subject: Re: [piclist] Tech support gone

On Thu, 15 Jul 2004 09:05:37 -0400, Trampas wrote:
>What is up with all of Microchips tech support shutting down for a
>week? I guess it is a bad week to be a Microchip customer, especially
>when you are like me and have problems&

Microchip Masters Conference starts this next week and they are all
teaching classes and running the show there... It pretty much eats up
their entire week.

I've been to a couple of the Masters conferences and they are great.
You get to actually meet and talk to the guys that develop the tools
and design the chips.

Matt Pobursky
Maximum Performance Systems

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions

Yahoo! Groups Links




Well, the only part I can address is the issue of C and assembly.
It is my opinion that, when working at this level of hardware
detail, a deep knowledge of the machine hardware and instruction set
are required. The first representation of the instruction set is
assembly language and I don't see any way to get around knowing
every detail of the language.

I look at C as a way to abstract assembly language and C does
contain very low level constructs. Still, I find myself spending
more time trying to figure out why C programs don't work than I
spend writing them in assembly language. Many years ago when I
spent a lot of time with the 8080, Z80 and 8085 (still one my
favorites) I would put together a bunch of macros to implement
control structures like if-the-else-endif, while-wend, repeat-until
and by using the macros I could get a level of abstraction while
still being very intimate with the code generated. I still tend to
do this with the PIC.

Now, I sure wouldn't want to write a FFT in assembly language. I
would expect a C compiler to generate proper code for something like
this - strictly numerical grunt work. Where I have problems with C
is in dealing with the bits of hardware and in interrupt handlers.
I want to know exactly which bits are being twiddled and interrupt
handlers should be quick.

Library code from almost any source is suspect. How could a program
possibly get two different answers? Without knowing what effect the
interrupt handler has on the data set, I would tend to dismiss
that. In fact, I would write a test case that didn't use anything
except the constant data set and the FFT. If I still got different
answers, I would be looking for references to uninitialized data. I
haven't seen C compilers catching this type of error. In fact, C
sometimes initializes variables to 0 when memory is allocated and
perhaps this was anticipated by the original programmer. Perhaps a
different compiler doesn't initialize to 0.

Good luck!




Personally I tend to like faster processors and programming in C. I know that I have used a TI DSP which runs at 150MHZ and never had to look at assembly, even for ISR routines.

 

For as the FFT I did put in constant data and output does change, I also initialized all variables. Therefore I figure I would end up having to write my own FFT in assembly or give up on the PIC.

 

Regards,

Trampas

 

 

-----Original Message-----
From: rtstofer [mailto:r...@pacbell.net]
Sent:
Saturday, July 17, 2004 10:33 AM
To: p...@yahoogroups.com
Subject: [piclist] Re: Tech support gone

 


Well, the only part I can address is the issue of C and assembly. 
It is my opinion that, when working at this level of hardware
detail, a deep knowledge of the machine hardware and instruction set
are required.  The first representation of the instruction set is
assembly language and I don't see any way to get around knowing
every detail of the language.

I look at C as a way to abstract assembly language and C does
contain very low level constructs.  Still, I find myself spending
more time trying to figure out why C programs don't work than I
spend writing them in assembly language.  Many years ago when I
spent a lot of time with the 8080, Z80 and 8085 (still one my
favorites) I would put together a bunch of macros to implement
control structures like if-the-else-endif, while-wend, repeat-until
and by using the macros I could get a level of abstraction while
still being very intimate with the code generated.  I still tend to
do this with the PIC.

Now, I sure wouldn't want to write a FFT in assembly language.  I
would expect a C compiler to generate proper code for something like
this - strictly numerical grunt work.  Where I have problems with C
is in dealing with the bits of hardware and in interrupt handlers. 
I want to know exactly which bits are being twiddled and interrupt
handlers should be quick.

Library code from almost any source is suspect.  How could a program
possibly get two different answers?  Without knowing what effect the
interrupt handler has on the data set, I would tend to dismiss
that.  In fact, I would write a test case that didn't use anything
except the constant data set and the FFT.  If I still got different
answers, I would be looking for references to uninitialized data.  I
haven't seen C compilers catching this type of error.  In fact, C
sometimes initializes variables to 0 when memory is allocated and
perhaps this was anticipated by the original programmer.  Perhaps a
different compiler doesn't initialize to 0.

Good luck!


to unsubscribe, go to http://www.yahoogroups.com and follow the instructions