PBP 3.0 really needed?

[Normnet]

... Still can't get microchip.com to show them or any other 18F's with a search for Vbat...

Darrel

A quick search for Vbat turns up:
PIC18F97J94 family is Microchip’s first to offer integrated LCD control, RTCC with Vbat, and USB on a single 8-bit PIC microcontroller
and:
PIC18F97J94 FAMILY.


Norm

[Mugelpower]

4 years are gone and I bought PBP3 Gold. I have the tendence of purchasing an excavator for planting a pansy.

[Demon]

Yeah, I sorta overengineer stuff as well.

[Ioannis]

Better be safe, right? But on the other hand an evolution is needed. And I can't see it...

Ioannis

[mpgmike]

Some thoughts I had was to integrate new commands based on new Special Functions, like NCO, PPS, etc. That would expand the PBP capability beyond the 20 year old SFs. The PIC16F HEF versus traditional EEPROM poses challenges as well. I agree, PBP is due for a major suspension redesign.

[HenrikOlsson]

This comes up now and then and although I agree that the development of PBP is kind of slow I fail to see how a PBP command to handle something like PPS would even work. I mean setting the output of the MSSP module to RB0 would then require a line of PBP code - exactly the amount of PBP code it takes without a specific command for it. (Not counting the lock/unlock sequence). I personally don't see the benefit of having a dedidated PBP command when all that command would do is set a single register to a specific value.

As far as the NCO goes, that might have some merit but like HPWM a PBP command to run it would likely impose limits/restrictions. That doesn't mean it wouldn't/couldn't be useful though.

It may sound as if I don't want PBP to evelove, I most certainly do, but I'd rather see the apparently limited development resources available spent on keeping up with the current devices instead of adding commands that a couple of lines of PBP code (ie setting a register or two) already does.

What I'd like to see is something like DT-Ints built into PBP but an even clever version that analyses the code in the ISR and determines what system variables it NEEDS to save based on what library routines the compiler acutally used to generate the code in the ISR.

New 8-bit devices are coming out with vectored interrups and DMA, I'd like to see support for th.

With that said, I'm not holding my breath...

/Henrik.

[mpgmike]

I've used DT_INTS for several years and fell madly in love with it. Lately, I'm forcing myself to get a grip on the ASM Interrupts as outlined in the "Advanced" section of the PBP Manual. Got it working on a PIC12F1501 and PIC16F18313. I intend to tackle the Vectored Interrupts with the newer offerings soon. It doesn't seem to be much more difficult than DT-INTS. Plus, I discovered you do an ASM Interrupt, part way through the ISR jump out of ASM, add some PBP, then jump back into ASM to RETFIE. I tried to alter the DT_INTS-18 for the new K42 and someone pointed out that it would require far more than just changing the SFRs to match the MCU, due to memory banks & other registers.

I'm with you, Henrik, I'm chomping at the bit to get playing with the new K42's, even ordered 2 PIC18F26K42s in anticipation.