Supplies and future
Moderators: David Barker, Jerry Messina
Supplies and future
In the current situation re SF will there also be a looming problem re: parts?
I was just thinking that if my Dongle conked will spares be available and for how long?
Also, as SF ideally needs a few little tweaks (and it would be nice if extra PICs were added to it's 'supported' devices), are there any plans to hand over the development reins to someone else? Or is SF in it's 'final' version?
In this case No News is not necessarily Good News.
I was just thinking that if my Dongle conked will spares be available and for how long?
Also, as SF ideally needs a few little tweaks (and it would be nice if extra PICs were added to it's 'supported' devices), are there any plans to hand over the development reins to someone else? Or is SF in it's 'final' version?
In this case No News is not necessarily Good News.
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Thanks. But I guess his cousin's brother could have answered the email.
This is the worry, no news/updates/ from the man himself.
This won't stop me using it as it's 'open-ness' means the community can keep things going. But it looks like any supported definitions of other/newer PICs are unlikely. I wish him luck in whatever he's doing now as he did a great job here.
This is the worry, no news/updates/ from the man himself.
This won't stop me using it as it's 'open-ness' means the community can keep things going. But it looks like any supported definitions of other/newer PICs are unlikely. I wish him luck in whatever he's doing now as he did a great job here.
Hi Francis,Francis wrote: This won't stop me using it as it's 'open-ness' means the community can keep things going. But it looks like any supported definitions of other/newer PICs are unlikely.
Adding new PICs is really very easy to do. For most of them, it's a matter of translating *.dev files definitions from MPLab.
open-ness cannot help when it's about the compiler bugs. You may have support for more PICs, have more libs, but you can do nothing when you have bugs in the compiler core.
Hi Octal,
I really meant 'community' support for include type commands (I remember an error a while back in the ADC.bas).
Whilst many roll-their-own , these commands are handy (and a useful reference) when you've only just purchased SF.
SF 'Help' could do with a few additions too.
On the subject of creating SF definitions files from .dev , do I have to purchase the MPLab compiler or are they included with the Microchip free download?
If the latter I'll have to investigate.
I'm surprised a clever fellow hasn't written a small App to create SF def and inc files.
I remember recently the generous help I got from a kind soul when there were errors in the 18F26K20 defs. A conversion App would have saved my agony.
That would be a nice 'coming back' present for David
I really meant 'community' support for include type commands (I remember an error a while back in the ADC.bas).
Whilst many roll-their-own , these commands are handy (and a useful reference) when you've only just purchased SF.
SF 'Help' could do with a few additions too.
On the subject of creating SF definitions files from .dev , do I have to purchase the MPLab compiler or are they included with the Microchip free download?
If the latter I'll have to investigate.
I'm surprised a clever fellow hasn't written a small App to create SF def and inc files.
I remember recently the generous help I got from a kind soul when there were errors in the 18F26K20 defs. A conversion App would have saved my agony.
That would be a nice 'coming back' present for David
Hi Francis,
SF is a very nice and very well designed compiler, this is a fact. The open source libs are a very motivating way for the community to help, debug and add more libs. BUT compiler bugs cannot be fixed, and when you use the compiler for commercial purpose, it's not really very motivating to know that the core compiler will never be enhanced or debugged.
Dev files are installed with MPLab cause these definition files are used by the assemblers and by the Microchip various software and hardware simulators/emulators.
this said, you can still check actual files included with SF and their counter parts in MPLab, this way you can easily deduce the conversion algo.
I think that a comeback from David would be really very helpful, even if it was for simple little bug corrections.
SF is a very nice and very well designed compiler, this is a fact. The open source libs are a very motivating way for the community to help, debug and add more libs. BUT compiler bugs cannot be fixed, and when you use the compiler for commercial purpose, it's not really very motivating to know that the core compiler will never be enhanced or debugged.
*.DEV files are provided with MPLab. There is no commercial version of MPLab, MPLab is freeware and all assemblers from Microchip (MPASM, MPASM30, ...) are free.do I have to purchase the MPLab compiler or are they included with the Microchip free download?
Dev files are installed with MPLab cause these definition files are used by the assemblers and by the Microchip various software and hardware simulators/emulators.
It's easy to understand. David already wrote a converter (as does Les for Proton Basic, and as is the case for all compilers writers). So why bother writing a converter for a compiler when we know that the compiler author has already a working converter for that?I'm surprised a clever fellow hasn't written a small App to create SF def and inc files.
this said, you can still check actual files included with SF and their counter parts in MPLab, this way you can easily deduce the conversion algo.
I think that a comeback from David would be really very helpful, even if it was for simple little bug corrections.
Hi Octal,
Many thanks. I'm grateful.
I had assumed David etc. had , but didn't know it was available for the rest of us.
You guys are very lucky knowing the 'inside' information.
There's nothing in SF Help or on the Wiki and I couldn't find anything on the Forum - bad spectacles maybe.
And there are no clues on the "Supported Devices" page - which would be the ideal and obvious place to put a link.
Where can I get a copy of the converter?
I'm sure people who have recently purchased SF would like to know too.
Does it work well?
I remember the 26K20 ones in the Wiki weren't correct.
Though that maybe down to Mircochip changing their minds I suppose.
I'll download MPLab now.
If the converter isn't publicly available I'll do it manually - I freely confess I am being lazy.
Francis.
Many thanks. I'm grateful.
- I realise about compiler bugs and absolutely agree with your opinion.BUT compiler bugs cannot be fixed, and when you use the compiler for commercial purpose, it's not really very motivating to know that the core compiler will never be enhanced or debugged.
- It looks like everyone except me knew that .David already wrote a converter. So why bother writing a converter for a compiler when we know that the compiler author has already a working converter for that?
I had assumed David etc. had , but didn't know it was available for the rest of us.
You guys are very lucky knowing the 'inside' information.
There's nothing in SF Help or on the Wiki and I couldn't find anything on the Forum - bad spectacles maybe.
And there are no clues on the "Supported Devices" page - which would be the ideal and obvious place to put a link.
Where can I get a copy of the converter?
I'm sure people who have recently purchased SF would like to know too.
Does it work well?
I remember the 26K20 ones in the Wiki weren't correct.
Though that maybe down to Mircochip changing their minds I suppose.
I'll download MPLab now.
If the converter isn't publicly available I'll do it manually - I freely confess I am being lazy.
Francis.
Hi Francis,
the converter is not publicly available
Each time we asked David about support for new chips, he said that he generated them automatically but didnt tested them on silicon hardware.
From this we guess that he has an auto converter.
The pb is that now we dont have any answer from Mecanique at all !!!
the converter is not publicly available
Each time we asked David about support for new chips, he said that he generated them automatically but didnt tested them on silicon hardware.
From this we guess that he has an auto converter.
The pb is that now we dont have any answer from Mecanique at all !!!
Hi Octal,
Oh dear. That's a pity.
I think can answer your question now:
"So why bother writing a converter for a compiler when we know that the compiler author has already a working converter for that? "
- because it isn't available
No answer from Mecanique? This doesn't sound good does it.
I'd better order a spare dongle now before they finally close shop.
Francis.
Oh dear. That's a pity.
I think can answer your question now:
"So why bother writing a converter for a compiler when we know that the compiler author has already a working converter for that? "
- because it isn't available
No answer from Mecanique? This doesn't sound good does it.
I'd better order a spare dongle now before they finally close shop.
Francis.
If you dont got answer from them, let me know, maybe I'll sell my dongle as I dont use SF for my devs (I'm mainly on ARM/CortexM3 chips).Francis wrote: ...
No answer from Mecanique? This doesn't sound good does it.
I'd better order a spare dongle now before they finally close shop.
Francis.
Last edited by octal on Tue May 04, 2010 1:39 pm, edited 1 time in total.
Oh, please don't throw it away or stick it on FleaBay. I might be in touch soon. Keep it safe. My superglue repair is still OK.
It's a pity really, with a few tweaks and some decent marketng and support SF could have been a real winner.
I'm sure it still could be.
I wonder how successful it would have been if sold through big distributors who have real catalogues like Farnell and Digi-Key.
It's a pity really, with a few tweaks and some decent marketng and support SF could have been a real winner.
I'm sure it still could be.
I wonder how successful it would have been if sold through big distributors who have real catalogues like Farnell and Digi-Key.
I wont throw it Francis,
I have a dual license, so I have two keys.
As for SF, I agree that it's a very big and aweful piece of code. Some tweaks and better marketing would have promoted it. It"s strange that it has been aboundouned this way.
I hope David will be back, or at least give any details about the future of this compiler.
I have a dual license, so I have two keys.
As for SF, I agree that it's a very big and aweful piece of code. Some tweaks and better marketing would have promoted it. It"s strange that it has been aboundouned this way.
I hope David will be back, or at least give any details about the future of this compiler.