headers
William "Chops" Westfield | 1 Aug 2005 02:51
Picon

Re: [PIC]:Still problems with ICD2 installation

On Jul 31, 2005, at 3:50 PM, Robert Rolf wrote:

> Seconding John's experience, the only thing that worked
> on my failed MPLab 7.2 ICD2 install was to clean out
> the registry of ALL mplab references, and then reboot.

I also recently took advantage of MC's "free shipping + discount" and
bought a genuine ICD2.  I too had difficulties getting the install to
work as per microchip's instructions; no matter what I did, it seemed
W2K always got to the USB "new device" before the microchip installer
detected it.  Eventually, I think I gave up and did a "windows style"
install - figured out where the microchip drivers were and pointed the
windows HW wizard there, which seems to have made things happy - the
laptop and MPIDE seem to talk ok to the ICD2 (what more could I ask
for) (although I haven't used it extensively yet.)

I'll be installing it "soon" on a WXP system, and I'll try to keep
track of what I need to do there (assuming I even get it to work...)

BillW
--

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Permalink | Reply | 3 comments |
headers
Gerhard Fiedler | 1 Aug 2005 03:00

Re: [PIC] Free C Compiler Suggestions/Download for SourceBoost(C2C)

Hopkins wrote:

> Great news Vic - but can you explain the steps to follow in order to
> program a chip from a hex file.

- You need an MPLAB compatible programmer, like an ICD2. 
- You activate the programmer in MPLAB (Programmer | Select Programmer |
ICD2) and make sure MPLAB talks to it (check the tabs in Programmer |
Settings).
- Set the chip type (Configure | Select Device). This is stored in a
workspace file, and you can create a workspace file with your chip already
pre-configured when you re-load it.
- Make sure the chip is connected to the programmer and that MPLAB can talk
to the chip, like read the memory contents (Programmer | Read) or erase it.
- Import your program into MPLAB (File | Import).
- If your hex file does not set the configuration bits (that depends on the
compiler and whether you instructed the compiler to add configuration data
to its output), you need to do that manually in MPLAB (Configure |
Configuration Bits). I'm not sure where this gets stored (could be in the
workspace file, too, then you can save that also in a workspace file like
the chip type).
- Program the chip (Programmer | Program).

Gerhard
--

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
(Continue reading)

Permalink | Reply | 1 comment |
headers
Robert Rolf | 1 Aug 2005 03:16
Picon
Picon
Favicon

Re: [OT]:HP 6000 scopes with crippleware....

James Newton, Host wrote:

>>Ok, I'll bite.  I agree.  If you signed an agreement with the 
>>bike lessee that you accepted the brakes as is, and that if 
>>you wanted to go faster you'd purchase a brake fix upgrade.
>>
>>How is this different from cracking serial numbers for 
>>software licenses?  
> 
> There are two different arguments going on here and I think people are
> getting the two separate issues confused:
> 
> 1. Should a mfgr sell a device with crippled hardware and upgrade via jumper
> / license / etc... or should they sell only the hardware that is actually
> used and upgrade via a full hardware install?
> 
> 2. Should a consumer who has purchased a crippled device UN-cripple the
> device without paying for the upgrade?
> 
> I think a lot of people (not all) object to #1 as being just... Inelegant?
> Misleading? Wasteful?
> 
> Most people (not all) also object to #2 and would pay the upgrade fee as
> required. A few will attempt to hack it and if they succeed, will publish
> the details which then makes #1 even stupider.
> 
> I personally can see the advantages of doing #1 as it makes the hardware
> upgrade much easier and less likely to result in a service call. The thing I
> don't understand is why HP charges so much for an upgrade that obviously
> didn't cost them (HP) much at all; if it had cost that much, they would
(Continue reading)

Permalink | Reply | 2 comments |
headers
Nino Benci | 1 Aug 2005 03:23
Picon
Picon

Re: [PIC] Problems with Warp-13 software

No, it's not Warp13. The fault lies with one of the MFC dll's. I had the 
exact same issue some months ago. I used a program called "Depends" to 
sort out the issue. The fault occured after I installed some shareware 
utilities. The utility overwrote a critical dll. The one in question for 
me was MFC42.DLL.

All I can say is good luck...

Nino.

shb7@... wrote:
> Hi Tom,
> 
> Thanks for your help. I tried an earlier version of MPLAB and it produced an identically-sized HEX file (I
didn't actually compare them byte by byte but I bet they are the same, as we'd expect). The HEX file from the
older version also produced the problem. 
> 
> I bet that there is something software-wise messed up on my system that would be best dealt with by
reinstalling the OS. I've had a couple of other weird problems with other pieces of software lately. I'm
reluctant to do this reinstall right now, though. I also plan on getting a new computer in a week or two so the
problem will definitely be solved soon.
> 
> The strangest part of this is that it will load and program the HEX file fine if I take out a couple of
instructions in the source code. It seems as though it is just fragile in a really strange way. I don't think
the problem really lies with a bug in the Warp13 software.
> 
> Thanks again,
> 
> Sean
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jim Robertson | 1 Aug 2005 05:28

Re: [PIC] Problems with Warp-13 software


>No, it's not Warp13. The fault lies with one of the MFC dll's. I had the 
>exact same issue some months ago. I used a program called "Depends" to 
>sort out the issue. The fault occured after I installed some shareware 
>utilities. The utility overwrote a critical dll. The one in question for 
>me was MFC42.DLL.
>
>All I can say is good luck...
>
>Nino.

Thanks for offering your insights Nino. I really hope they help Sean.

I have replied privately to Sean, not that I was such a great help. This 
really is a one-off issue that is beyond my rather limited knowledge of the 
internal workings of Windows. I am sure that there is no systemic bug with 
the WARP-13 software and I'm not getting feedback to make me think 
differently.

It is oddball, one-off problems like this that really sap your spirits. I 
would like everyone to have a trouble free WARP-13, not it is just not 
possible sorry to say.

Regards,

Jim Robertson
NEWFOUND ELECTRONICS

--

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

Permalink | Reply | 0 comments |
headers
GM | 1 Aug 2005 06:00
Picon
Favicon

[PIC] Misc. ASM questions


Hello,

PIC newbie here. I have a couple of questions that have come up over the
past month or so. Neither one is a burning issue, I'd just like to know
the answers, or at least collect a few opinions.

First, refer to the documentation for the RRF and RLF instructions in
MicroChip's Mid-Range MCU manual. I have a question about the contents
of the W register after either of these instructions are executed. The
examples (pages 29-36 and 29-37) show that the contents of W are not
defined prior to executing the instruction, but then they show that W
contains 0x17 after execution. The W reg is not the destination for the
instruction, which is given as RRF INDF,1. The bit-shifted value ends up
in the register whose pointer is in FSR, just as I expect. What I do not
expect or understand is why W would contain a value that doesn't have
any obvious relationship to the contents of the destination register.

I understand the rest of the "Example 2" code just fine - the contents
of the target register and the carry bit are just what I expect. How
does W get set to 0x17? Or does it? I wonder if that is just an
arbitrary example. If so, it is confusing. 

Second, I'm wondering just how much use most programmers make of the
assembler directives. There are a LOT of directives available, yet when
I look at other folk's source code it seems that only a very few
directives ever actually show up in the code. The #include, EQU, and a
few others are very common, as is using $ to refer to the PC. That seems
about it. For example, I'd expect to see more use of DA, DT, BANKISEL,
and BANKSEL. Are there non-obvious drawbacks to using the MPASM
(Continue reading)

Permalink | Reply | 7 comments |
headers
Spehro Pefhany | 1 Aug 2005 06:35
Picon

Re: [PIC] Misc. ASM questions

At 09:00 PM 7/31/2005 -0700, you wrote:
><snip>

>  What I do not
>expect or understand is why W would contain a value that doesn't have
>any obvious relationship to the contents of the destination register.

Looks like a simple mistake. The value of W should not be affected in
example 2, so if it has some arbitrary value prior to the RRF with
file destination, it will have the same value afterward.

>I understand the rest of the "Example 2" code just fine - the contents
>of the target register and the carry bit are just what I expect. How
>does W get set to 0x17? Or does it? I wonder if that is just an
>arbitrary example. If so, it is confusing.

There are lots of mistakes in data sheets and manuals. Not just Microchip.
So, if you find something confusing or if there is a conflict between
different bits of info, either you don't understand fully or there is
a mistake. ;-)

>Second, I'm wondering just how much use most programmers make of the
>assembler directives. There are a LOT of directives available, yet when
>I look at other folk's source code it seems that only a very few
>directives ever actually show up in the code. The #include, EQU, and a
>few others are very common, as is using $ to refer to the PC. That seems
>about it. For example, I'd expect to see more use of DA, DT, BANKISEL,
>and BANKSEL. Are there non-obvious drawbacks to using the MPASM
>directives?
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vitaliy | 1 Aug 2005 08:37

Re: [OT] USB serial ports

> I plan on buying a new laptop soon and I've noticed that they almost never 
> have RS-232 serial ports anymore (it does not surprise me). I know the 
> topic of USB-based RS-232 ports has been discussed here quite some time 
> ago. I am mainly interested in using one to run my Warp 13 programmer. 
> Anyone have any idea how well that would work? It would probably be with 
> Win XP. Alternatively, if anyone can recommend a USB-based PIC programmer, 
> that might be a better option.
>
> Thanks,
>
> Sean

Sean,

I have some experience using USB-Serial converters, although I haven't used 
one with a Warp 13. They have two issues:

1. Some converter designers cut corners and do not include an RS232 level 
shifter. As a result, their voltage swing is only 0-5V instead of the 
usual -10/+10V.
2. AFAIK, all virtual ports have a significant (measured in milliseconds) 
and somewhat random delay associated with them.

Our company sells a USB-Serial converter that doesn't have the problem 
described in #1:

http://www.scantool.net/products/usb_serial.htm

The reason I mention it is because our main product line requires full 
compliance with RS232, and we found that for example most Belkin converters
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jim Robertson | 1 Aug 2005 09:02

[OT] USB serial ports


>
>
>Hi all,
>
>I plan on buying a new laptop soon and I've noticed that they almost never 
>have RS-232 serial ports anymore (it does not surprise me). I know the 
>topic of USB-based RS-232 ports has been discussed here quite some time 
>ago. I am mainly interested in using one to run my Warp 13 programmer. 
>Anyone have any idea how well that would work? It would probably be with 
>Win XP. Alternatively, if anyone can recommend a USB-based PIC programmer, 
>that might be a better option.
>
>Thanks,
>
>Sean

For ~$25 get an I/O gear convertor. By all reports (and my testing) these 
work well with the WARP-13. These are based on the prolific chip set and 
are a better option than the less efficient FTDI chip. Still, the FTDI chip 
does work ok  with the WARP-13 but some of the bugs in the VCP driver can 
be very annoying.

Regards,

Jim Robertson
NEWFOUND ELECTRONICS

--

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

Permalink | Reply | 0 comments |
headers
Alan B. Pearce | 1 Aug 2005 10:03
Picon
Picon

Re: [PIC] Misc. ASM questions

>Second, I'm wondering just how much use most programmers make of the
>assembler directives. There are a LOT of directives available, yet when
>I look at other folk's source code it seems that only a very few
>directives ever actually show up in the code. The #include, EQU, and a
>few others are very common, as is using $ to refer to the PC. That seems
>about it. For example, I'd expect to see more use of DA, DT, BANKISEL,
>and BANKSEL. Are there non-obvious drawbacks to using the MPASM
>directives?

Possibly because the directives they give are not too much use because they
are not making best use of the directive names (e.g. the skip macros are as
hard to understand as the skip instructions themselves), and the banksel
ones can put in much unneeded code. Dmitriy has already pointed you at Olins
website where he ahs an environment that you can download, which contains
many useful macros which are more user friendly than the Microchip ones -
the skip ones have more easily understood names and the bank selection ones
put in instructions only where they are needed.

Another problem with macros lies in how MPLab steps through them with the
debugger and simulator. This may discourage people from using macros as they
may find it just as easy to code the assembler straight off so they can see
what happens when debugging.

--

-- 
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