PBP 3.0 really needed?

[Darrel Taylor]

I hadn't seen those chips yet. But you're right, they have Vbat functions.
Still can't get microchip.com to show them or any other 18F's with a search for Vbat.

I asked about the J94's here, and the response was ...
The J94 series was scheduled to be added in the last update of PBP3, but some issues came up with the device that requires new library routines.
Hopefully, that will be completed by the next update of PBP3.

[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.