Latest PICs - how to program them?

[Demon]

Not at all.

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.

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"

[tumbleweed]

How is SF with USB? I just got the latest HIDMaker. I'm wondering how we can use that code with SF.

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.
All of the SF libraries are in source code so you can modify pretty much everything.

[Ioannis]

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

[tumbleweed]

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.

[Ioannis]

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

[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

[tumbleweed]

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.