Future PBP

[skimask]

Nothing?

https://goo.gl/maps/Jnksb

This is it?
3 years of practically nothing new?

Yep.

Done and done...

Over and/or Out...

[Acetronics2]

Nothing?

https://goo.gl/maps/Jnksb

This is it?
3 years of practically nothing new?

Yep.

Done and done...

Over and/or Out...

Hi, Skimask

Don't tell me it's because of the shop on the left side ....

Seriously ... it's obvious everyone of us need more and more calculating power - even for blinking the little LED - ( humour ... )

but one day, we MUST reach 8 bits limitations ..., so, What to do ???

I must admit THAT helps : http://www.mikroe.com/mini/pic32/ ( "thru hole" usable !!! )

Best regards

Alain

[skimask]

Nope, not the "8-bit limitations" at all. Sure, I'd like to use PBP with the new 80 & 100 pin TQFP's. But that's not the point. There's also plenty of <28 pin PICs with newer features.

3 years. No updates. Really?

[rmteo]

Nope, not the "8-bit limitations" at all. Sure, I'd like to use PBP with the new 80 & 100 pin TQFP's. But that's not the point. There's also plenty of <28 pin PICs with newer features.

3 years. No updates. Really?

As you said "when an STM32F415 costs the same as a PIC18Fxxxx" why even bother.

[Archangel]

You know, I have an old Phillips screwdriver that I really like. I have some newer and more expensive ones, but I go to this one first. I just like it, wouldn't trade it for a new one like it. Seems PBP is like that too. My projects do not depend on the newest fancy featured PICs so PBP is here to stay for me. NOW WHEN they upgrade it to program 16 & 32 bit PICS, I will buy the upgrade. "C" is really only as good as your libraries and I HATE the syntax, I E Punctuation hassels, but then I don't write code in notepad either

[skimask]

As you said "when an STM32F415 costs the same as a PIC18Fxxxx" why even bother.

Somedays I couldn't agree more, but at the moment, abstraction and familiarity. I'm sure in a few years, that'll likely change completely. Familiar with PICs, know them inside and out, and I'm satisfied with the level of abstraction that PBP provides (basically the lack of the real need to know the guts), and yet can dig deep into the PICs guts when needed. Also at the moment, not very familiar with ARM, specifically the STM32F4 series, and with that, the IDEs available for the ARMs (Arduino styles/knockoffs not included) don't provide the abstraction wanted to easily kick something up quickly. Not to mention, there aren't a lot of ARMs in DIP packages. Yes, they're out there, just not a lot.

Main point being...3 years and no updates? WTF?

Double-dog dare anybody to find any one useful thread regarding 'updates' or a 'next version' with any meaningful information other than vapor ware.

As for me, I'm modifying PBP to include a couple of newer choice smaller PICs as well as couple of the larger ones.

[rmteo]

As long as you are doing simple hobby stuff (and DIP packages are pretty much irrelevant outside of the hobby and experimental arenas), sure, stay with PBP and PICs. If you must have a high level of abstraction in order to deal with sophisticated hardware, there are things such as STM32CubeMX.

[Ioannis]

there are things such as STM32CubeMX.

that goes with C and as Dave said earlier, some really hate that syntax. At least frustrating for me. PBP fits perfectly to my taste, the speed I test my prototypes is remarkable comparing to C and the IDE I use (Microcode Studio) is really great in its simplicity.

Many people, many preferences, but cannot deny that there are limitations that some day are too much. For example, I made an remote receiver using keeloq decoder in firmware and in PBP is on the limit. With C the same hardware performes much better using same resources (timers, interrupts etc).

Charles, are you listening? People are waiting (long enough) for the good news.

Ioannis