PC Pete
Reged: Oct 15 2005
Posts: 23
Loc: Melbourne, Victoria
|
|
I stepped right from the 16F84 to the 16F877A, and I've developed around 8 working projects using that part.
This year, I moved into the 18F range due to the significant issues with the 14-bit core (both the awful limited space and addressing issues and the limited availability down under), and currently I'm developing 4 projects using the 18F4620, since they're a good pin-for-pin and function-for-function replacement of the '877a.
I've designed and built a couple of power supplies and SLA battery chargers using the 16F88A, but they were dedicated projects using someone else's code.
All my current development is around a '4620-based studio controller (measuring temperatures and controlling air and coolant flow in response) that should be flexible enough to work in another project for our cars (trip computer, fuel usage, that kind of thing).
It's a 20MHz crystal-clocked part with onboard 2A AC/DC power supply and regulator, with 5 analogue inputs and I2C, SPI, RS-232 with level shifters, 8-bit I/O, plus a couple of 2- and 3-bit digital I/O ports on a 3" x 4" single sided PCB. I'm using bit-banging routines to bypass the horrible I2C module, but the SPI module doesn't seem to have all the problems the I2C module does, so that's a hardware controlled header.
Schematics, PCB layouts, and photos are all available if anyone's interested. PM me for details.
-PCPete
--------------------
Data is not information. Information is not knowledge. Knowledge is not wisdom.
|
yahoolarry
stranger
Reged: Apr 17 2009
Posts: 1
|
|
I became interested in PICs in when I went to college a few years ago (non-traditional student. middle aged, not teenager). I would like to continue to program PICs for use at home, amateur, not professional.
I am familiar with the PIC 16F88 and would like to start with that, till I'm familiar with the C++ compiler.
But I'm not sure if I have the right one. I downloaded the C PRO for the PIC10-12-16 MCU Family V9.60PL5. And I'm using Microchip MPLAB IDE.
In school I used the Borland compiler. When I ran it, I had to have the PIC type in the C++ header. Now that doesn't seem true with the compiler I have.
the question is, am I using the right compiler?????
Projects I would like to program are:
1. Christmas LEDs that do stuff, instead of just stay on.
2. game controller that keeps track of who hits a button first, like Jepardy.
3. instrument that keeps track of voltage and current to automobile light bulbs, to find blown bulbs.
yahoolarry
|
RouseA
Reged: Dec 10 2003
Posts: 27
Loc: Berkshire, England
|
|
When we started our current generation of products (about 10 years ago) we needed some products with low power consumption and others with higher levels of functionality. We couldn't achieve both with the same technology, so used 12-bit PIC's for low power products and a Motorola 68HC11 (with 64KB bank-switched ROM and 32KB RAM) for the higher-functionality applications.
Since then we have upgraded the PIC products to use PIC18xxx in some cases.
We are now looking at the next generation of products, and would like to adopt the same processor type across the board. No PIC architecture will give us the RAM capacity we need for the high performance products, so I have looked further afield. We have decided to switch to the ST Electronics STM32 processor range. They are 32-bit ARM Cortex processors with up to 48KB on-chip RAM and 512KB of ROM. There are more on-chip peripherals than any PIC, and the current consumption in low power mode matches that of PICs.
They are slightly more expensive, but the cost difference is insignificant in the overall cost of the product, and the savings in software maintenance will offset it. Furthermore, the development tools are free! We are using the gcc compiler and Eclipse IDE.
Sorry if this is bad news for Hi-Tech, but it is progress!
--------------------
Regards
Alan Rouse
|
kcress
Reged: Feb 22 2005
Posts: 42
|
|
Quote:
What in most applications do 18's give you that justifies the price?
1) NOT having to add an EEPROM just to remember a few setup values.
2) NOT having to add yet another voltage regulator.
I often wish Microchip could correct these two omissions. Last design I reached for a 24 and fell back to an 18 largely on these two details.
Back to the survey:
A PIC24FJ128GA010 as the controller of a 240W fire system, Intelligent Battery Charger for the stationary diesel engine pumps.
Top view:
Bottom:
This week a PIC18F819 for a current controller. 12-24VDC, 1-20A.
|
dacosa
Tester
Reged: Jun 29 2007
Posts: 54
|
|
The EEPROM simulation using code space FLASH on the PIC24's works great, so separate EEPROM is not needed. Unfortunately many application need NV storage with speeds in excess of EEPROM and that emulated using code FLASH. On board FRAM would be nice!
The added voltage regulator is still an issue, but it need not be but a zener, cap and resistor or change all needed logic to 3v3.
|
vin2403
stranger
Reged: May 28 2009
Posts: 14
|
|
PC PETE ,i have interesting wat u have done , can i get the source code , and other related information ?
|
John Payson
Reged: Oct 16 2003
Posts: 1135
|
|
I've migrated from the 16Fx parts to the 18Fx parts, largely for the extended code and data space as the project has evolved and grown. In some ways I like the 18x parts, but there are definitely some aspects I find annoying.
As I've posted before, one of my major wish-list items for the compiler would be a mode in which all data memory that was not otherwise qualified would be assumed to be in one 256-byte page, and functions could be marked as assuming that page to be selected on startup and leaving that page selected on exit. This would thus allow up to ~384 bytes to be accessed with almost no MOVLB instructions (interrupts would still need to save/restore/load the bank register).
Since Microchip and HiTech have joined, I may as well also offer a wish-list item for the processor: a version of "enhanced" mode in which 96 bytes of the common area work as follows:
Code:
$00-$5F -- Normal shared area
$60 --- -- ADJFSR0
$61-$67 -- IND0_1 through IND0_7
$68 --- -- ADJFSR1
$69-$6F -- IND1_1 through IND1_7
$70 --- -- ADJFSR2
$71-$7F -- IND2_1 through IND2_F
INDn_m would access the register at location at (INDn+m). ADJFSRn would always read a constant value which would yield twelve different results when written with CLRF, BTF, COMF, INCF, or DECF. Those twelve different values would do things like add/subtract W to/from the FSR, add/subtract 2, 4, or 8 from the FSR, add W to FSR2 and store the result in FSR0/FSR1, etc. I'm not sure of the optimal coding from a hardware perspective, but such operations would allow for very efficient stack-based code even with stack frames larger than 16 (or even 96) bytes.
|
John Dill
stranger
Reged: Nov 19 2009
Posts: 12
|
|
I work on a project that consists of taking temperature and RH measurements of a Sensirion SHT1X sensor array for data acquisition and research. The PIC model used is a PIC18F4610, and the project has several pieces consisting of serial communication, SHT1X sensor communication, LCD display (using SSD1305 and graphics library from RAMTEX), push button debouncing, Atmel DataFlash memory storage, battery monitoring, and hopefully no more stuff (I'm out of pins anyways  ). Using a 1ms interval timer to maintain a clock tick to schedule periodic events to communicate with the various modules.
Been programming on a MPLAB ICD 2 environment with HiTech PICC-18 v9.50 since June '09. Still learning more and more each day.
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
