16F913
-
- Posts: 7
- Joined: Sat Mar 31, 2007 8:29 pm
-
- Posts: 714
- Joined: Wed Jan 31, 2007 12:41 pm
- Has thanked: 1 time
- Been thanked: 26 times
-
- Posts: 7
- Joined: Sat Mar 31, 2007 8:29 pm
sorry but the only pics supported by flowcode are these ones in the 16FXXX serie :
PIC16F627A, PIC16F627, PIC16F628A, PIC16F628,
PIC16F630, PIC16F648A, PIC16F676, PIC16F684,
PIC16F688, PIC16F636, PIC16F716, PIC16F72,
PIC16F737, PIC16F73, PIC16F747, PIC16F74,
PIC16F767, PIC16F76, PIC16F777, PIC16F77,
PIC16F818, PIC16F819, PIC16F83, PIC16F84A,
PIC16F84, PIC16F870, PIC16F871, PIC16F872,
PIC16F873A, PIC16F873, PIC16F874A, PIC16F874,
PIC16F876A, PIC16F876, PIC16F877A, PIC16F877,
PIC16F87, PIC16F88
sorry
PIC16F627A, PIC16F627, PIC16F628A, PIC16F628,
PIC16F630, PIC16F648A, PIC16F676, PIC16F684,
PIC16F688, PIC16F636, PIC16F716, PIC16F72,
PIC16F737, PIC16F73, PIC16F747, PIC16F74,
PIC16F767, PIC16F76, PIC16F777, PIC16F77,
PIC16F818, PIC16F819, PIC16F83, PIC16F84A,
PIC16F84, PIC16F870, PIC16F871, PIC16F872,
PIC16F873A, PIC16F873, PIC16F874A, PIC16F874,
PIC16F876A, PIC16F876, PIC16F877A, PIC16F877,
PIC16F87, PIC16F88
sorry
- Steve
- Matrix Staff
- Posts: 3433
- Joined: Tue Jan 03, 2006 3:59 pm
- Has thanked: 114 times
- Been thanked: 422 times
The next update of Flowcode will support this chip. We should release an update in the next few weeks, which will contain some bug fixes and the following new features:
Support for these chips:
- 12F609, 12F615, 16F610
- 16F913, 16F914, 16F916, 16F917
- 18F2423, 18F2523, 18F2682
- 18F4423, 18F4523, 18F4682
New components:
- PWM
- LIN Master and Slave
- I2C
New languages:
- Romanian
- Danish (hopefully)
The current release of Flowcode also supports the 16F88x family and a few others that are not listed in Camusensei's post.
Support for these chips:
- 12F609, 12F615, 16F610
- 16F913, 16F914, 16F916, 16F917
- 18F2423, 18F2523, 18F2682
- 18F4423, 18F4523, 18F4682
New components:
- PWM
- LIN Master and Slave
- I2C
New languages:
- Romanian
- Danish (hopefully)
The current release of Flowcode also supports the 16F88x family and a few others that are not listed in Camusensei's post.
- Steve
- Matrix Staff
- Posts: 3433
- Joined: Tue Jan 03, 2006 3:59 pm
- Has thanked: 114 times
- Been thanked: 422 times
My current plan is to release the next update once the I2C component has been completed.
I'm not sure whether it will be a hardware or software implementation of I2C, so it's too early to say if you'll be able to define your own pins. Would you prefer to have a software implementation that allowed you to choose the pins?
I'm not sure whether it will be a hardware or software implementation of I2C, so it's too early to say if you'll be able to define your own pins. Would you prefer to have a software implementation that allowed you to choose the pins?
-
- Posts: 209
- Joined: Thu Oct 19, 2006 11:46 am
- Location: Bakewell, UK
- Has thanked: 20 times
- Been thanked: 16 times
Hi Steve,
One consideration is the I2C bus speed. Historically with 400kHz or even 100kHz bus I2C software has plenty of time, however with the 1MHz devices (which will increasingly become the norm) then a 20MHz crystal giving a 20/4 instruction cycle time or even a 4MHz crystal giving a 4/4 = 1 us cycle time starts to make the coding time limiting. Add to this that an application may include an ADC acquistion and store then the opportunity to do any work with even audio signal waveforms starts to look difficult.
regards,
Mark
(ps there is a bug in the I2C write macro where I used FCV_SEND for sending the byte to write, when it should have been FCL_DATA for properly transportable code using the parameter brought in by the Macro)
One consideration is the I2C bus speed. Historically with 400kHz or even 100kHz bus I2C software has plenty of time, however with the 1MHz devices (which will increasingly become the norm) then a 20MHz crystal giving a 20/4 instruction cycle time or even a 4MHz crystal giving a 4/4 = 1 us cycle time starts to make the coding time limiting. Add to this that an application may include an ADC acquistion and store then the opportunity to do any work with even audio signal waveforms starts to look difficult.
regards,
Mark
(ps there is a bug in the I2C write macro where I used FCV_SEND for sending the byte to write, when it should have been FCL_DATA for properly transportable code using the parameter brought in by the Macro)
Go with the Flow.