Latest PICs - how to program them?

[Ioannis]

I think this is also at stall...

Ioannis

[tumbleweed]

I think this is also at stall...

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.

[tumbleweed]

Well some did and moved on to C compilers or Positron Basic compiler.

Positron Basic has the same problem as PBP... no support for devices not included with MPASMX 5.87.
That rules out a number of newer 18FxxQxx and 16F1xxxx parts.

[Demon]

Interesting. Gonna look at SW. I've been itching to use the Qs.

[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