An interrupt-driven IR decoder and a Vishay 38kHz IR (38238) receiver provides all the buttons I need using only one input pin and a timer.
Bson.. seems an ideal solution , care to share some code pls....
Bson.. seems an ideal solution , care to share some code pls....
Sure! I've attached a decoder for the Adafruit $5 remote:
http://www.adafruit.com/products/389A suitable receiver is the Vishay TOPS38238, although I think most 38kHz active-low receivers will work.
as to the original question, I believe the pickit3 schematic is published by microchip but not whats in the fpga's inside it. so, yes chinese cloners can make clone pickit3, I dont know what happens regards to the firmware. and the firmware will try and update each time you debug or program with mplabx (maybe its a switch to turn it off I dont know).
as to the original question, I believe the pickit3 schematic is published by microchip but not whats in the fpga's inside it. so, yes chinese cloners can make clone pickit3, I dont know what happens regards to the firmware. and the firmware will try and update each time you debug or program with mplabx (maybe its a switch to turn it off I dont know).
The pickit3 uses a PIC24F and the .hex file is available from microchip in case you brick the pickit. The problem of buying even an exact clone of the pickit is lack of support and the quality. Just get the original.
I wanted to start with PIC32s some months ago and asked myself the same question. Reading endless discussions on forums like this, the consensus seems to be buy the original instead of a clone. I didn't buy the original but I bought OLIMEX's clone (through amazon, I used a 10€ coupon I got a few months back, so it was 26 € shipped). It works well. A china clone would cost me also 25 €. Like someone said a couple posts back, if you have to debug your debugger... you have the wrong debugger. All this still do not answer your question, I know. I also didn't find a definitive answer.
If you are serious about the PIC32, you may consider the ICD3. Why do I say that, debugging with the PICKIT3 is slow, dog slow, I assume that it is better with the ICD3. The PICKIT3 doesn't allow you to change/add/delete a breakpoint when you are debugging. You set/clear bkpts, compile, load and debug.
Another point, a bit more worrisome is the lack of optimization options on the compiler without paying Microchip for GCC!. I tried compiling MC's toolchain but it aborts on different places depending on the host. There are other precompiled toolchains available but do not play well with MPLABX... On this regard, the ARMs a bit better. No toolchain problems or programmer (for Cortex at least), but also no narrow 28 PIN version either
.
The PICKIT3 doesn't allow you to change/add/delete a breakpoint when you are debugging. You set/clear bkpts, compile, load and debug.
My kosher PICkit 3 does allow breakpoints to be amended while debugging.
Another point, a bit more worrisome is the lack of optimization options on the compiler without paying Microchip for GCC!. I tried compiling MC's toolchain but it aborts on different places depending on the host. There are other precompiled toolchains available but do not play well with MPLABX... On this regard, the ARMs a bit better. No toolchain problems or programmer (for Cortex at least), but also no narrow 28 PIN version either .
Agreed, Microchip really need to get back with the program on this, I do stuff on the full range of devices and now have a costly annual charge totalling about $600 (if I wish to use the latest devices) which I never used to have. I've had the old C18 and C30 compilers since 2005, and C32 since 2007 when it was a one off lifetime charge. Then XC8/16/32 was introduced, and C18/C30/C32 users were grandfathered in. Very generous you might think. Until last year when I updated one of the compilers and had a rude surprise that I had to shell out for an annual maintenance charge known as "HPA", or High Priority Access, $200 per compiler, so $600 total per annum for the PRO versions. If you're just coming into the game, each compiler is $1000, so $3000 total just to buy in. If you want XC32++, that's $1500, and luckily I don't have need for that.
As a comparison, the toolchains from TI and NXP are priced at ~$500 for fully unlocked versions of their Code Composer Studio and LPCXpresso respective toolchains but there is no hefty up front buy-in. The TI license is an annual subscription, but I am not sure about the NXP one. However you can do an awful lot with the free versions, there is no compiler crippling. For NXP, you are restricted to 256KB code size (that's a lot in an embedded system) and with TI you're restricted on the debuggers you can use.
good thing gcc is open source, and microchip follow the gpl license and make it available, so enabling all the optimisations is easy!
good thing gcc is open source, and microchip follow the gpl license and make it available, so enabling all the optimisations is easy!
I didn't know Microchip had a GCC-based compiler. I thought XC8 and the others were fully proprietary. And, if there are open source variants, why doesn't anybody start a parallel project for it, just like Red Hat Enterprise Linux and Centos or SUSE and openSUSE?
good thing gcc is open source, and microchip follow the gpl license and make it available, so enabling all the optimisations is easy!
I didn't know Microchip had a GCC-based compiler. I thought XC8 and the others were fully proprietary. And, if there are open source variants, why doesn't anybody start a parallel project for it, just like Red Hat Enterprise Linux and Centos or SUSE and openSUSE?
As I understand it, XC8 is based on the proprietary Hi-Tech C compiler, while XC16 and XC32 are gcc-based.
Microchip do their best to ensure that only their compilers will work with MPLAB X, and to defeat attempts to enable optimization.
I tried in 3 different evironments to compiles microchip's gcc: mingw, cygwin and centos 6 32 bit. it failed every time, on different packages. I found a post somewhere... that explained how to compile it (and also reported that it was broken) but never made it as far as cc1
.
http://jubatian.com/articles/turning-on-optimizations-in-microchips-xc32/on windows bombed on ppl or on cloog (cygwin/mingw). On centos bombs in binutils due to some sh*t microchip added to verify the license
.
Microchip do their best to ensure that only their compilers will work with MPLAB X, and to defeat attempts to enable optimization.
No they don't. You're just not trying hard enough.
brad@bklaptop:/opt/microchip/xc8/v1.30/bin$ wc -l xclm.c
76 xclm.c
Microchip do their best to ensure that only their compilers will work with MPLAB X, and to defeat attempts to enable optimization.
No they don't. You're just not trying hard enough.
brad@bklaptop:/opt/microchip/xc8/v1.30/bin$ wc -l xclm.c
76 xclm.c
Which proves what, exactly?
Microchip do their best to ensure that only their compilers will work with MPLAB X, and to defeat attempts to enable optimization.
No they don't. You're just not trying hard enough.
brad@bklaptop:/opt/microchip/xc8/v1.30/bin$ wc -l xclm.c
76 xclm.c
Which proves what, exactly?
It proves that Microchip are making *cursory* attempts to defeat enabling optimisation, not "doing their best". It is easy to defeat and they are making no attempt to make it harder.
Microchip do their best to ensure that only their compilers will work with MPLAB X, and to defeat attempts to enable optimization.
No they don't. You're just not trying hard enough.
brad@bklaptop:/opt/microchip/xc8/v1.30/bin$ wc -l xclm.c
76 xclm.c
Which proves what, exactly?
It proves that Microchip are making *cursory* attempts to defeat enabling optimisation, not "doing their best". It is easy to defeat and they are making no attempt to make it harder.
You've still lost me, I'm afraid. How does a line count on a source file not present in the current distribution prove all that?
rolycat@zen /opt/microchip/xc8/v1.34/bin $ wc -l xclm.c
wc: xclm.c: No such file or directory
Microchip do their best to ensure that only their compilers will work with MPLAB X, and to defeat attempts to enable optimization.
No they don't. You're just not trying hard enough.
brad@bklaptop:/opt/microchip/xc8/v1.30/bin$ wc -l xclm.c
76 xclm.c
Which proves what, exactly?
It proves that Microchip are making *cursory* attempts to defeat enabling optimisation, not "doing their best". It is easy to defeat and they are making no attempt to make it harder.
Microchip, as with many other vendors these days use Reprise for licence enforcement. The node locked licenses use a MAC address to validate against, and the software chooses one from your list of several when you install it, and it's pretty likely it may not be the one you want it to use.
Regrettably I've historically had a lot of difficulty with Reprise node locked licensing as a bona fide punter of a couple of products, including the Microchip compilers, Made with Marmalade cross platform mobile development tools and ShadowProtect backup software. It breaks too easily, and for no apparent reason it will use up your "lives" from the internet-based license database with duplicate entries. In some cases the database is queried frequently, and it will break the software if it doesn't get a response on demand. Some vendors also choose not to allow deregistering and re-registering, or make it very time consuming to fix or move licences to replacement machines, usually with a manual process. In the meantime you have no software.
When, as a legit punter, your software breaks and the vendor makes it difficult to resolve, for example having to wait for an human email exchange, it encourages you to look for other means to enable it. I have no qualms in investigating other options, and it may well be worthwhile me looking into xclm bodges in case it suddenly breaks on me again.
You've still lost me, I'm afraid. How does a line count on a source file not present in the current distribution prove all that?
Ah, sorry. You compile the file and use the resulting binary to replace the xclm binary in all your microchip compiler directories. My point in the line count is that it is a tiny file. For XC8 you need to use that file, for the others you can use a 2 line bash file if you like. Either way you now have access to all the "optimisation" levels.
and all xclm needs to do is 'return 2' as in 'int main(void) { return 2; }'...
replace xclm binary with that, then replace its sha256sum thats embedded as a string inside gcc/g++
... I still want to recompiles microchip sources... not defeat their weak on purpose so they have an excuse system...
@BardC: Nice to see you around
, I'm Ale from the propeller forums
and all xclm needs to do is 'return 2' as in 'int main(void) { return 2; }'...
replace xclm binary with that, then replace its sha256sum thats embedded as a string inside gcc/g++
Does this work with XC8 which isn't gcc? I couldn't find the sha256 in the files I looked at. It is present in xc16 and xc32 recent releases.
I only use it for xc32. xc8 is a different beast and is not open source.
Does this work with XC8 which isn't gcc? I couldn't find the sha256 in the files I looked at. It is present in xc16 and xc32 recent releases.
No, You need the xclm.c file I alluded to earlier. It has a simple hardcoded challenge response and requires more than just an exit code. I found it with a bit of google-fu. It's not hard.
... I still want to recompiles microchip sources... not defeat their weak on purpose so they have an excuse system...
@BardC: Nice to see you around , I'm Ale from the propeller forums
Hey Ale, thought it might have been you. Unfortunately the source for the XC8 compiler is not open, so you can't recompile it anyway.
Hei Brad !,
I'm after gcc.pic32 anyways.
. I don't use 8 bit pics or xc8
. For the time being I'm using another pre-compiled (it does't work from inside mplabx) gcc outside mplabx... and then linking the resulting object. for testing purposes works well.
