Will PBP support the new chip like 18FxxK40 series?
Will PBP support the new chip like 18FxxK40 series?
I plan to add them in a few weeks. I haven't studied the data yet, so I can't make promises, but I don't think they'll be much different than the K22 parts. I also plan to add several new parts in the enhanced mid-range families.
I've become very dependent on the files that Microchip supplies in their MPLABX SDK. In the last release, they did some unexpected fun stuff with filenames and formats. My first attempt to harvest the K40 data didn't go well. I've made the required alterations in my database and parsing software (I think). Adding the new parts is next on my list after I clear the current project off my desk.
Although I have the "Instantly, using email" selected and the appropriate tick box checked, I never got an email notification of your reply.
I think the forum's ip address gets blacklisted. I'll have another go at fixing it, but I don't know when that will be.
It is now 20 hour since your reply and still no notification received.
Still no notifications are sent when new post is sent or Private message.
We're very close to having PBP and Programmer support for the K40 parts. I'll post links to beta versions here once we beat it into shape.
The parts have been a challenge for PBP. The current methods for automatically setting TRIS registers had to be rewritten. The chips have a very powerful method for locating peripheral ins and outs on a choice of 16 pins. You can even duplicate outputs from a single peripheral on multiple pins (at least for PWM output, haven't tested others).
I'll keep working through the weekend. I hope to have something for you in a few days.
I think I have working libraries in PBP and a working programming algorithm for meProg. We're waiting on a versioning fix for the PBP executable and a reply from Microchip to resolve a discrepancy in the programming spec concerning EEPROM addressing.
In the meantime, the notes for the K40 changes in PBP, as it stands currently, are below:
Code:The function of the 18FxxK40 devices differs somewhat from other PIC18 parts. Because of this, the following commands are configured a bit differently when executed on the 18FxxK40 devices. -------------------------------------------------------------------------------- HPWM Use the following PBP DEFINE statements to specify the output pins for HPWM. Check the Microchip datasheet (Peripheral Pin Select PPS) for the pins allowed on each CCP/PWM channel. The PPS peripheral will automatically be configured for the specified output pin upon execution of HPWM. When used on devices other than the 18FxxK40, these defines will only control the Data Direction SFRs (TRIS). These defines are intended for use when the HPWM output pin is static. If you wish to change the PWM output pin at runtime by changing PPS SFRs, you should not use the HPWM command, but rather set the appropriate SFRs manually. DEFINE CCP1_REG PORTC 'Channel-1 port DEFINE CCP1_BIT 2 'Channel-1 bit DEFINE CCP2_REG PORTC 'Channel-2 port DEFINE CCP2_BIT 1 'Channel-2 bit DEFINE CCP3_REG PORTC 'Channel-3 port DEFINE CCP3_BIT 3 'Channel-3 bit DEFINE CCP4_REG PORTG 'Channel-4 port DEFINE CCP4_BIT 3 'Channel-4 bit DEFINE CCP5_REG PORTG 'Channel-5 port DEFINE CCP5_BIT 4 'Channel-5 bit DEFINE CCP6_REG PORTE 'Channel-6 port DEFINE CCP6_BIT 6 'Channel-6 bit DEFINE CCP7_REG PORTE 'Channel-7 port DEFINE CCP7_BIT 7 'Channel-7 bit CCP and PWM peripherals are both supported by HPWM. Default output pins if no DEFINE is used: 2xK40 4xK40 6xK40 CCP1 RC2 RC2 RC2 CCP2 RC1 RC1 RC1 CCP3/PWM3 RC6* RD1 RC3 CCP4/PWM4 RA7 RA7 RG3 CCP5 RG4 PWM6 RE6 PWM7 RE7 * Note that default CCP3/PWM3 setting on 28-pin devices conflicts with the default TX1 setting described below. -------------------------------------------------------------------------------- HSEROUT/HSEROUT2 Use the following PBP DEFINE statements to specify the output pins for HSEROUT and HSEROUT2. Check the Microchip datasheet (Peripheral Pin Select PPS) for the pins allowed on each EUSART. The PPS peripheral will automatically be configured for the specified RX/TX pins only once after reset or power up. This allows the PPS SFRs to be changed at runtime to relocate the RX/TX pins as needed. These defines will have no effect when code is executed on devices other than the 18FxxK40. DEFINE HSER_RXREG PORTC DEFINE HSER_RXBIT 7 DEFINE HSER_TXREG PORTC DEFINE HSER_TXBIT 6 DEFINE HSER2_RXREG PORTB DEFINE HSER2_RXBIT 7 DEFINE HSER2_TXREG PORTB DEFINE HSER2_TXBIT 6 Default output pins if no DEFINE is used: 2xK40 4xK40 6xK40 RX1 RC7 RC7 RC7 TX1 RC6* RC6 RC6 RX2 RB6 RB6 RG2 TX2 RB7 RB7 RG1 * Note that default TX1 setting on 28-pin devices conflicts with the default CCP3/PWM3 setting described above. -------------------------------------------------------------------------------- I2CREAD/I2CWRITE The memory map of the 18F4xK40 forces PBP to reduce the I2CREAD/I2CWRITE clock frequency slightly to allow I2C operation on PORTE pins. If you aren't using I2CREAD/I2CWRITE on PORTE, you may use the following define to maximize the clock frequency on ports A, B, C and D. DEFINE I2C_ONLYABCD 1 This define has no effect on 18F2xK40 and 18F6xK40 devices.
We're still having some versioning issues with the PBP executable, so I've compiled a special build of 3.0.9 with the additional K40 support. This should be considered a beta version. If you find issues with the K40 parts, post reports here or email me directly at firstname.lastname@example.org.
Download the K40 build here:
New libraries have been created for the K40. I've tested briefly on the 47K40 and simulated some of the other K40 parts. When testing, pay close attention to the following commands, as the routines have been modified significantly:
HSERIN, HSEROUT, HSERIN2, HSEROUT2, I2CREAD, I2CWRITE, HPWM, OWIN, OWOUT, READ, WRITE, READCODE, WRITECODE
Verify that all commands that set TRIS registers automatically are doing so correctly.
I've published a new meProg beta 4.63:
Edit: this link deleted, see below for a newer one.
The K40 parts are supported by U2 firmware version 6.3. You must update the firmware for K40 support.
The K40 are only supported in the U2 at this time. Field Programmer firmware will be available after we test and get some feedback.
Microchip seems to have changed the addressing for EEPROM data space in their hex files. We don't have confirmation from them yet, so I decided that meProg and PBP should disregard the programming spec and mimic their tools. I've tested against MPLABX with a PICKit3 and 47K40. It appears to be consistent, allowing meProg to handle the files that MPLABX produces and MPLABX to handle the files that PBP produces.
Bump. I think I fixed the email notifications. There are beta updates for K40 parts here.
Wow..! Thanks for the work you did, in the middle of holidays!
Hopefully I will have in hand the new chips to test the libraries.
I did not check for a week or more this thread and did not see your posts. Unfortunately the notifications do not work.
Confirmed! Now they work fine.
I don't have any chips to test with but I just stumbled across a post on the EEVBlog forum talking about a silicon bug causing TBLRD to not return the correct data on the K40 series chips. The chip errata does mention it and there's also a suggested workaround. I suspect the PBP compiler uses TBLRD for all sorts of stuff(?) so if it's not allready taken care of in the new libraries it might be worth looking into.
I'm not inclined to implement the TBLRD workaround until testing proves that the currently-available chips exhibit the problem. The easiest commands to test are LOOKUP and LOOKUP2. If the commands misbehave and a preemptive setting of "NVMCON1.7 = 1" fixes the problem, let me know. Aside from the LOOKUP/LOOKDOWN commands, at first glance it looks like PBP uses TBLRD for SEROUT, DTMFOUT, and the trig operators SIN, COS and ATN. I only did a quick text search, so there may be more.
The errata shows that silicon rev A2 is the only one affected. In the past, when a second revision is released so soon, the number of first-revision chips has been relatively few. We don't usually implement workarounds in PBP when the bug has been fixed in current silicon.
If you find that newly-purchased chips need the setting, I can initialize NVMCON1 on program start and after READ/WRITE commands are executed.
Thanks for flagging this, Henrik.
I got some PIC18F27K40 yesterday. I'll test them this week-end.
FYI DT_INTS-18 doesn't work:
These new chips don't have INTCON2 & INTCON3 registers. Just a few defines to rework.Code:Symbol not previously defined (INTCON3)
To be continued...
Good to know. I will probably create an Include just for the K40s. Mine came in yesterday. Started playing today. Got an LED to blink, then decided to get the PICkit 3 hooked up for breadboard mounted programming (I normally use the MELabs U2). It didn't list the K40, so went to Microchip's site to download the latest version of software for the PICkit 3 and inadvertently fudged up my U2 software!
I want to play with the new ADC2 and verify PWM functions for Charles. Already have a project in the works to take advantage of the new cool stuff.
After 2+ hours of fighting getting the MELabs U2 Programmer working again (won't go into that fiasco), was able to get basic ADCIN working blinking an LED. Next I got basic HPWM working on the default CCP1 PORTC.2. Amazingly, by just calling CCP1 PORTC.3 in the DEFINE, it worked. I didn't even have to use the CCP1PPS SFR! Great work Charles!!! Now to play with more of the ADC2 features.
Stayed up all night working on the DT_INT-18 for K40. I reconfigured all the interrupt identifiers to match the SFRs & naming convention listed in the Data Sheet. This is for the 28 & 40 pin versions. I looked over the 64 pin versions and the registers are completely different. Let me know how it works for you.
As a side note, anything the 28 & 40 pin K40's don't have I removed; like USB, Parallel Port, Timer 7, CAN, and so forth. It can be grafted into the older DT_INT-18 with #INDEF qualifiers later. Just wanted to get it working on the new cool stuff for now.
I still have not received my K40.
As for the notifications, I am again not lucky...
@Charles: Looks like my PIC18F27K40 seems to be rev "A2"
LOOKUP/LOOKDOWN commands does misbehave but NVMCON1.7 = 1 fixes the problem.
Results with NVMCON1.7 = 1:Code:hserout2 [13,10,13,10, "PIC18F27K40 test board", 13,10] hserout2 ["Test Lookup: ["] for PtrB = 0 to 10 Lookup PtrB, ["Hello world"], TempB hserout2 [TempB] next PtrB hserout2 ["]", 13,10,13,10] hserout2 ["Test Lookup2: ["] for PtrB = 0 to 2 Lookup2 PtrB, [256,512,1024], TempW hserout2 [dec TempW, " "] next PtrB hserout2 ["]", 13,10,13,10] hserout2 ["Test LOOKDOWN: ["] for PtrB = 65 to 69 TempB = 255 LOOKDOWN PtrB, ["ABCDEF"], TempB hserout2 [dec TempB, " "] next PtrB hserout2 ["]", 13,10,13,10] hserout2 ["Test LOOKDOWN2: ["] for PtrB = 65 to 69 TempB = 255 LOOKDOWN2 PtrB, ["FEDCBA"], TempB hserout2 [dec TempB, " "] next PtrB hserout2 ["]", 13,10,13,10] hserout2 ["Test LOOKDOWN2 >: ["] for PtrB = 65 to 69 TempB = 255 LOOKDOWN2 PtrB, >["FEDCBA"], TempB hserout2 [dec TempB, " "] next PtrB hserout2 ["]", 13,10,13,10]
Results without NVMCON1.7 = 1:Code:PIC18F27K40 test board Test Lookup: [Hello world] Test Lookup2: [256 512 1024 ] Test LOOKDOWN: [0 1 2 3 4 ] Test LOOKDOWN2: [5 4 3 2 1 ] Test LOOKDOWN2 >: [255 5 4 3 2 ]
Code:PIC18F27K40 test board Test Lookup: [5 255 255 ] Test LOOKDOWN2 >: [0 0 0 0 0 ]
@mpgmike: thanks for DT_INT-18 for K40!
Ok, I'll fix it some more and publish a new beta. I have jury duty today, so it will be toward the end of the week.
Ioannis - I'm not sure why the forum isn't always sending you mail. It seems to only send a notice after you post - then it forgets about you until you post again. You could try changing your profile settings for the way you are notified.
In a 4-5 days I will have my K40 to report on the beta.
As for the notifications, now I received again.
Strange, I have not changed anything in the profile and last time I checked, seemed OK.
I've posted a new beta with the NVMCON1 workaround:
This installation only allows compilation for the new chips that need testing, so you shouldn't replace your existing PBP installation. Rather, install to a separate folder.
We're still chasing a pesky versioning bug in the new exe file, so this one will still identify as 3.0.9. You'll know it's the beta because the list of available devices will be short.
This also has fixes for READ/WRITE commands in the 16F183xx series.
Does this limitation (compiling new chips only) apply to the previous beta too?
No, I believe the previous beta supported the full list. I didn't do any testing beyond the K40 devices, though.
My intent is to differentiate the beta and discourage its long-term use. It bothers me that the beta is still identifying itself as 3.0.9. Technical support is difficult enough without having to guess as to the real version of software.
I had hoped to have the new exe and versioning system in place by now, but the software gods are angry for some reason. We've migrated the PBP project to a modern (Microsoft) development environment. I'm happy about that because it makes things much better going forward, but it introduced a few minor, annoying issues.
On the business side, we're considering whether to release this as PBP 3.1.0 and ask you, our current users, for a $50 fee to upgrade. I normally resist this when the improvements are limited to device support, but this last round of development cost a lot more than anyone anticipated.
I asked because I replaced on my office PC the installation with the beta one, not thinking that this is a temporary release.
Whatever you decide on the policy, I support you. Preferably, of course, is the free update. As you said adding new chips should be within the free support of compiler. But then I do understand its cost.
Looking at PIC trends, I'd say the K40 is probably typical of new products to come. They will introduce a K29 with many similar features and structure, then a K37 and so forth. I vote for the 3.1 since it is radically departing from previous architecture, yet will probably be used with more of the newer offerings here on out. I suppose those not wanting to pay the $50 upgrade fee can still program everything short of the K40s for now, but will inevitably have to suck it up as the current fleet ages.
Thanks again for all your efforts to remain the go-to company for PIC 8-bits. I did some work with the new K40s and can appreciate the massive undertaking involved.
Ship it with a document and the necessary files/plugins/tools/whatever showing how to properly set it up and work with in MPLABX and I'd be more than happy to pay $50 for it.
Up to this moment I was not able to test the beta version with my K40 chip. I have some programming issues with the ICD3 and Pickit3 along with the unbelievable IPE of the MPLABX package.