Printable View
Hi there,
From time to time, I see new PICs showing up, PICs that would just do the thing I need at the moment.
I'm week-end hobbyist and MCS user and there is an apparently fixed list of devices from which some of the latest PICs are absent.
I questionned MECANIQUE how to add new devices but, unfortunately, didn't see any replay up to now.
Is there a way to add new devices to the MCS list or what is(are) the alternative(s) to get these latest devices programmed?
Even if you manage somehow to add the PIC you want in the list, compiler will not be aware of this new chip. Compiler needs more files related to that specific chip and also have an assembler that will support it.
So, the latest assembler supported is in the 5.35 MPLABX IDE.
I am afraid that there will be no answer from Mecanique and no update now on for any new PIC. Either you have to stay with what is available with PBP or look for other compiler, preferably in C.
Unfortunately PBP is dead and we have not accepted the fact yet... Well some did and moved on to C compilers or Positron Basic compiler.
Ioannis
... or if you really want the latest PICs then checkout Mecanique's Swordfish BASIC, but that only supports PIC18F family.
I think this is also at stall...
Ioannis
Not at all.Quote:
Originally Posted by Ioannis
Swordfish supports ALL the 18F family of devices, including the newer Q family... Q10, Q40, Q41, Q43, Q83, and Q84.
Support for the Q20, Q24, and Q71 devices will be released shortly.
Positron Basic has the same problem as PBP... no support for devices not included with MPASMX 5.87.Quote:
Well some did and moved on to C compilers or Positron Basic compiler.
That rules out a number of newer 18FxxQxx and 16F1xxxx parts.
Interesting. Gonna look at SW. I've been itching to use the Qs.
Quote:
Originally Posted by tumbleweed
How is SF with USB? I just got the latest HIDMaker. I'm wondering how we can use that code with SF.
https://www.tracesystemsinc.com/blog...rocessors.html
I suppose I could finally make the switch to C++ on the PIC side; I'm already doing that for the Windows side. The part that bugs me is losing all the utilities that have been developed by Darrell and others here. Is there as strong a community over with SF?
EDIT: Holy crap! "ConvertTemp - Convert temperatures in any direction between Fahrenheit, Celsius and Kelvin. Written by Darrel Taylor."
EDIT SOME MORE: Wow! "Supports all current 45 18F USB devices, including 18F2550, 18F4550, 18F2553, 18F4553, 18F2455, 18F4455, 18F2458, 18F4458, 18F2450, 18F4450,18F14K50, 18F13K50, 18F24K50, 18F25K50, 18F45K50, 18F24J50, 18F25J50, 18F26J50, 18F44J50, 18F45J50, 18F46J50, 18F65J50, 18F66J50, 18F67J50, 18F85J50, 18F86J50, 18F87J50, 18F26J53, 18F27J53, 18F46J53, 18F47J53, 18F66J55, 18F86J55, 18F65J94, 18F66J94, 18F67J94, 18F85J94, 18F86J94, 18F87J94, 18F95J94, 18F96J94, 18F97J94, 18F66J99, 18F86J99, 18F96J99"
No idea about that one... not familiar with HIDMaker, but if it produces code for PBP I would think its output could be massaged to work with SF.Quote:
How is SF with USB? I just got the latest HIDMaker. I'm wondering how we can use that code with SF.
All of the SF libraries are in source code so you can modify pretty much everything.
Using interrupts in SF is not as straightforward as in PBP (especially using DT-INTS).
Have a look here: https://www.sfcompiler.co.uk/phpBB3/...php?f=3&t=2210
Ioannis
A lot of it really depends on what your ISR is doing.
Just like PBP you can choose to save just the pic registers or also include the BASIC system library variables.
SF has the additional complication due to the shared frame variables, a powerful feature which can reduce RAM usage a LOT.
If saving the context is really complicated that's a good clue you should probably examine what your ISR is actually doing in the first place... most folks do WAY too much in the ISR.
In most cases it's not nearly as complicated as it sounds, but the nice thing with SF is that you can easily control what gets saved without having to resort to editing asm libraries, etc., and can be done on an individual case-by-case basis.
All things have two sides. Same with SF of course. This design of the compiler has great potentials but needs great care by the user/programmer.
I agree that produces more compact and faster code. Especially with the new tool that was offered.
Ioannis
Just checked the supported list of the MCUs supported by Positron Compiler. It is big and surprising...!
https://sites.google.com/view/rosetta-tech/home
Many dsPIC, 24F, 24H and Q series...!
Just see the amazing and cheap PIC18F57Q43.
Ioannis
Support for the 16-bit pic24/dspic33 parts is one of the nice things about Positron.
But, if you thought SF was a bit quirky Positron is possibly worse in that regard.
As you say, each have there own strengths and weaknesses.
As far as the 18F Q series goes, it only supports the same parts as PBP does (Q10, Q43).
That's an MPASMX 5.87 limitation, and neither PBP or Positron can do much about that.
In fact, I got a quick reply from MECANIQUE - unfortunately I didn't see their email because it landed in my spam folder (...)
Here is the info:
Quote:
Hi
If the device is supported in PBP, it should appear in the IDE. The IDE collects supported devices from the PBP install.
You do not need to upgrade MCS.
You might have to upgrade PBP.
regards
David Barker
What did I miss here? :eek:Quote:
Originally Posted by Ioannis
Can you give more details on this please?Quote:
Originally Posted by tumbleweed
PBP can use MPLABX 5.35 only.
Ioannis
As Ioannis pointed out, PBP updates for new devices is pretty much over.Quote:
Originally Posted by flotulopex
PBP uses the assembler (mpasmx v5.87) from MPLABX v5.35, and mchip has replaced mpasm with a new assembler PIC-AS, which is not compatible.
Positron interrupts work much like they do in SF. Also, it now has support for procedures and functions but the syntax for declaring parameters and "local" variables and how they actually work leaves a lot to be desired.Quote:
Originally Posted by Ioannis
So then,
Since PBP doesn't seem to go on for newer PICs,
Attachment 9647
...what are the options?
Is there any "new" BASIC compiler out there that will take over from PBP?
For 18F series only Mecanique's Swordfish BASIC https://www.sfcompiler.co.uk
For all chips (16F, 18F, 24F, dsPIC) Positron Compiler https://sites.google.com/view/rosetta-tech/home
Ioannis
Except that for the 8-bit chips Positron doesn't really support anything much newer that PBP does (see my previous posts).Quote:
Originally Posted by Ioannis
They've been promising an update "Real Soon Now" since 2022...
There's also Great Cow Basic (open-source, free).
All of these are much different than PBP so be prepared for some changes.
Thanks for the links :)