Swordfish Update...

[David Barker]

Swordfish has been available for a number of years now and I think it could do with a bit of an update. For example, updating of library files and updating of device files. I'm not looking for comments with respect to changes to the IDE or compiler language features at this point. What I would like to do is start a discussion on what you think should be updated. For example, Jerry has a very stable bit of USB code on the wiki which I have used for a long time now - should we use this? What about device files, what should be added? Are there any other modules from the wiki that people would be OK with me installing? This assumes users could give some feedback on usefulness and / or robustness. I have to consider support. For example, if I included a library that a thirdparty has created then I would be unable to support it. Would this be unfair to people just buying the compiler? Should I put any additional files in a "thirdparty" folder during install, with a support caveat? What about additional sample files? Or has anyone got a module or sample code they might like to share?

Anyway, let me have your thoughts...

[Jerry Messina]

An update for the libs would be nice. Here's some feedback on the ones that pop into mind...

SPI module
I've seen a number of fixes bounced about, but the basic issue is that SPI is always an exchange of data from the master to the slave... whenever you write a byte you receive a byte also.
SPI.WriteByte() doesn't account for this, and that's the source of a lot of the problems people have. Once you get a WCOL or SSPOV things can quit working properly.

Here's what I typically use in place of WriteByte/ReadByte:

Code: Select all

public function spi_transfer(b as byte=0) as byte
    // clear write collison (just in case it was set) 
    SSPCON1.bits(WCOL) = 0
    // transmit the byte
    SSPBUF = b
    // wait for byte to be sent (and a new one received)
    repeat
    	nop()
	until (SSPSTAT.bits(BF) = 1)
    // read SSPBUF to get the byte that was just transfered in
    // this also clears BF buffer full flag
    result = SSPBUF
end function

USART module
There's an issue when using 16-bit BRG mode on some devices. It assumes that the BRG/BRGH regs are contiguous in memory,
and on some chips they're not...

current:

Code: Select all

dim SPBRGRegister As SPBRG.AsWord		// <<< assumes contiguous locations
Public Sub SetBaudrate(pSPBRG As SPBRGRegister = br19200)

suggested:

Code: Select all

dim
   SPBRG_Reg as SPBRG,
   SPBRGH_reg as SPBRGH

public sub SetBaudrate(pSPBRG as word = br19200)
   SPBRG_Reg = pSPBRG.byte0
   SPBRGH_Reg = pSPBRG.byte1

ADC module
I've thrown in the towel there. There's just too many different hardware implementations, and always seem to keep changing.
I don't have any good suggestions for making that easier, and I know it's an issue for someone new.

device files
One thing that's caused me issues is the way the WDT usage changes with some devices... for some it's config WDT, others it's WDTEN, and the basic functionality even seems to change, esp if it can be enabled/disabled in code.
It's not as simple as ON and OFF anymore. It'd be nice if there was some unified method, at least at the source code level. I've had to resort to "#if device this/#if device that" and a set of macros for controlling it, which is all very confusing. I think on the last chip I used I actually had to turn it OFF in order to be able to use it! Now THAT made a lot of sense.

As far as installing more libraries/third party code I don't have a lot of opinion one way or the other since it's hard for me to judge what a new user might be looking for.
I know setting up/controlling the oscillator/PLL is always a source of confusion so maybe that's something to look at.

PS-
I'm updating the USB files right now to handle some of the new chips, and finally adding support for the 'protected' region feature you added a while back for reserving ram. It sure cleans up all of the memory allocation stuff, and for most chips you get back normal usage of a bunch of ram!

[David Barker]

Thanks for the feedback Jerry. So we have

(1) Update SPI WriteByte()
(2) Update USART baud setting
(3) ADC - I agree, the module is impossible to maintain - perhaps remove completely?
(4) WDT - as you point out, there seems little consistency. However, Swordifsh does allow you to correctly sets the fuses. I assume you are talking about ClearWDT()?

Do you think any changes are required to device files - you mentioned PRODL as WORD in a previous correspondence? Or is everyone happy with the device file format?

> I'm updating the USB files right now to handle some of the new chips, and finally adding support for the
> 'protected' region feature you added a while back for reserving ram. It sure cleans up all of the memory
> allocation stuff, and for most chips you get back normal usage of a bunch of ram

That's sounds awesome - I use your USB libraries a lot. I'm assuming the "interface" would be backwards compatible with previous code? Would you mind the libraries being included in an official release?

Please keep the comments coming in...

[Jerry Messina]

(3) ADC - I agree, the module is impossible to maintain - perhaps remove completely?

I'd hate to see that. I'm going to look a little more at the device files. I'm sure you've been through this already, but perhaps there's some more info there somewhere that could help. It'd be a real pain to have a module based solely on the device type itself, what with some 240+ odd devices.

(4) WDT - as you point out, there seems little consistency. However, Swordfish does allow you to correctly sets the fuses. I assume you are talking about ClearWDT()?

I think the issue is more with using the #option WDT and the proper config setting. Thinking out loud here, but maybe change the #option to be the config setting itself instead of just true/false? Something like "#option WDT = SWON" ? That might not work... I'd have to look. The config itself could probably be handled by adding an alias to the device file so that "config WDT" and "config WDTEN" set the same fuse info.

Do you think any changes are required to device files - you mentioned PRODL as WORD in a previous correspondence?

I can't think of anything else off the top of my head. There is a fix needed for the 100-pin variants of the J99 family that I'm looking at right now, but that's not really anything new per say.

I'm assuming the "interface" would be backwards compatible with previous code?

I sure hope so. I'm adding a few new modules but that's more just to make it easier for the user to customize w/out having to change the base files (ie setting up clock/PLL, custom HID reports, etc). I'm trying to keep any external changes to a minimum. You're welcome to do whatever you like w/it.

[SHughes_Fusion]

Just thinking off the top of my head, would it be viable to provide two layers of library? I'm thinking generic libraries and device-optimised ones. It would be great if you could 'tag' a library with the processors it supports for example, and the compiler would automatically include the appropriate version for that processor, or the generic version if an optimised one wasn't available.

Regarding the ADC library (and I guess this also extends to device files) it would be handy if newer features such as the FVR were checkable. I was looking for a way to read the FVR to track battery voltage and I ended up having to write my own routine as the ADC library doesn't support sufficient channel select bits and as there is no way to check if a device has an FVR (or what type is has) there was no 'clean' way to modify the ADC library.

The topic of variation between devices has been raised here. Is there scope for type-generic libraries? i.e. a library for the K22 series, one for the J whatever series etc? While there are a lot of individual PIC18s they seem to be split in to a few fairly similar types, at least the more recent ones do...