That's making me laugh. Sometimes we like to THINK we're that important. No, hobbyist sales are far too small and infrequent to be any significant source of income for Microchip. In fact we often just get all we need as free samples from Microchip.
Embedded controllers go into most consumer electronics, and Microchip is one of the biggest suppliers. You take apart a lithium battery and the built-in protection board probably has a PIC on it.
Hobbyists do however contribute quite a lot. They raise the popularity of the PIC products, provide education, tutorial web pages, code examples, find bugs, and may eventually become specialists in the industry. The industry that is Microchip's bread-and-butter relies on the knowledge base that is partially generated by hobbyists.
I'm surprise they use something as 'sophisticated' as a PIC for a paintball gun, the number of fireing modes and rate could easily be set using a few simple gates.
actually i would have expected that those oems would use dedicated ICs for the task they need, like in the computer mouse, which contain a single chip that does all the work (sensor signal amplification, counting, UART....)
I beleive PIC and ATMEL opened new doors for hobyist and enginners who where unable to build complex projects. and i beleive that's why they take the time to provide such a friendly support.
actually i would have expected that those oems would use dedicated ICs for the task they need, like in the computer mouse, which contain a single chip that does all the work (sensor signal amplification, counting, UART....)
It's a great deal cheaper to use a PIC than have a custom chip designed and manufactured - to do that you have to have a massive market, and 100% confidence in no bugs!.
It's actually fairly common in TV manufacture to see the main micro in early production with a 'piggy back' EPROM in a socket - so they can easily introduce any changes or bug fixes. Once the software is truely finalised it will be incorporated in mask programmed versions. In fact I've even seen piggy back board released later as updates, when there has been a previously unnoticed bug which was built-in the mask programming. Initial updates are on piggy back boards, with eventually mask programmed versions being supplied - obviously it's NOT a quick job getting mask programmed chips made, and you need to be sure not to have thousands more faulty ones made.
1) Where’s the best place for subroutines? Is it before main program or after main program?
2) When sudden power failures (like loosy power plug), PIC variables are changing or port pin status are changing. To solve this I have added some delay before main program and used a low voltage detecting reset IC to the reset pin. It solved many start up errors but not this.
Subroutines and the main loop can be placed anywhere after the interrupts section it doesn't matter, it's entirely up to the programmer. The best place is wherever you think it's best. Most people tend to put the main loop first an subroutines afterwards, but that's just convention as when they load their source code they want to be able to see the main code loop first.
Putting a large electrolytic or a supercap on the main VCC and GND pins can cover power failures. The PIC could execute entire shut down and save routines when a low voltage (say on a power supply sense line) was detected before the capacitors drained to the point where the PIC lost power. I've run a few LED blinking programs for over 30 seconds using a 5 volt 1F cap (think they cost about 5 dollars) Greatest thing since sliced bread if you ask me.
Most people tend to put the main loop first an subroutines afterwards, but that's just convention as when they load their source code they want to be able to see the main code loop first.
As do I, but interestingly in Pascal it's the other way round - the subroutines come first (in the order they are used), and the main program last. This is because Pascal can only call routines BEFORE the current code, unless you add a forward declaration. Again, Pascal is highly structured, which makes it easy to write and easy to read.
Don't forget the smaller PIC's use paging and limit location of tables to the top of the page. So tables may have to be placed before main programs and subroutines.
Don't forget the smaller PIC's use paging and limit location of tables to the top of the page. So tables may have to be placed before main programs and subroutines.
No, you can place tables in any page you want, by simply setting the page bits correctly when you call the table - or even use huge tables that cross page boundaries - you just need to be aware of the paging system (and it's reason for being).
Check my LED matrix tutorial, where I use a big table to store the ASCII font details.
However, I will agree if you're only using small tables, it's often easier to just stick them at the beginning - and I usually do.
I asked this for a reason.
My first PIC gadget is kind of a big one. It uses 2 pics. One for drive 4 SSDs. And I use RS232 to link them. It worked fine without any problem. So I added more functions to improve it. There are no errors in my newly added code but pic is not working properly. (EPROM read errors, some times it get stuck) First I thought PIC can’t handle the code so I change some codes to reduce the space. But none worked. When I use small NOP to some where some times PIC is completely dead.
At last I found the problem. I cut some subroutines form the top and placed them in the end of the file. I can’t believe it. But now every thing works fine.
You can say there must be some errors on my previous code. But both are same except the placing of some subroutines.
You need to give more details - like for a start, what type of PIC are you using, how much program memory are you using, and are you using any tables?.
You need to give more details - like for a start, what type of PIC are you using, how much program memory are you using, and are you using any tables?.
*) PIC16F84A
*) Program memory is up to 02B0 (now it doesn’t matter.)
*) I am using a small Table for EEPROM addresses.
You may think W > Table rows and it making errors. No it doesn’t.
MPLAB Simulator tells code is fine. YES there MUST be some wrong.
It's not about setting page bits, it's more like the year 2000 IT scare...
This is because the PIC only works with 8bits when it adds W to the program counter. So if the program counter is at 0x01FF and W = 1 and you do this:
addwf PCL,F
The PIC will jump to 0x0100 and NOT to 0x0200 as you would expect.
To make it a little clearer?, PCL itself is only 8 bits, so can't go higher than 0x1FF - the higher bits are stored seperately, and not affected by the ADDWF, although they are affected by the normal PCL incrementation.