Hi David,
I think that for (myself and) custumers who would like to base their business on Microchip PICs it is important/vital to know a little much more about what and where they are going to put their money.
SFWBasic is great, well structured, and generate very reliable code. But as professionnal developper, I think that we need more transparency about the history and future of SFBasic.
How:
1- i think that it would be nice to have a section in SFBasic (WebPage or Forum, it's up to you to choose) with the HISTORY of the versions : Additions, Bugs Corrections ....
The list of known bugs can be very helpfull, because it can let us decide wether to recall to factory chips (or circuits) already sold or not ... depending on wether buggy features where used or not. Commercially it's vital in our business.
2- I think that it would be nice to have a list of users WISHES and/or the features validated and in development state ... or at least on planned features ... Because this can let professionnal users to make business decisions on weather to skip their actual dev tools or not.
3- It would also be nice if, from time to time, you male POLLS on the forum to know the degree of importance users gives to features in SFBasic. This can says if people are interrested in more modules, or more intergrated features, or ...
For example, I personnaly think that adding ICD or any kind of debug system, even if it's like PBP one (in MicroCodeStudio Plus) is more important than more modules, ... because if ICD is working this will let US and YOU to debug more quickly, and thus produce MORE MODULES and MORE Software quickly ... and most importantly MORE RELIABLE software!!!
Best regards
Octal
SFWBasic future ?
Moderators: David Barker, Jerry Messina
Some thoughts
Think about it, any command will work or it will not work, I do not know any command that will fail in use that you could not spot as part of normal testing. I may be wrong, do you have and example?
I think a list of wishes is not a bad thing and I know David has talked about producing a Under Development list. He would though be one of the first to do so.
Re ICD I agree that one would be very handy, but having produced an ICD for another compiler I can say that for SF it would not be easy as its not a flat language so managing shared variables will so you only see your variable change when its active requires a complex Debug file generation system. Not something that get knocked up over night.
You can debug your code in ISIS as it stands. I do it all the time.
I find that really a strange thing to say, how can you release code with out testing it? I see this from Pbro users saying some other compiler is unsafe to use, when in my opinion its all rubbish.because it can let us decide wether to recall to factory chips (or circuits) already sold or not ... depending on whether buggy features where used or not
Think about it, any command will work or it will not work, I do not know any command that will fail in use that you could not spot as part of normal testing. I may be wrong, do you have and example?
I think a list of wishes is not a bad thing and I know David has talked about producing a Under Development list. He would though be one of the first to do so.
Re ICD I agree that one would be very handy, but having produced an ICD for another compiler I can say that for SF it would not be easy as its not a flat language so managing shared variables will so you only see your variable change when its active requires a complex Debug file generation system. Not something that get knocked up over night.
You can debug your code in ISIS as it stands. I do it all the time.
I can't talk for David but, as far i remind, an ICD is on the to-do list. The PBP ICD have been made by Mecanique, not Melabs as some still think... So it was a David 'creation'
I'm not a ICD fan, so to me modules, new feature are, by far, much important. You can still use a simple serial communication, a LCD or simply your brain to debug your program.
Most professional, beginner (or else level) already heard or know about Mecanique. They're on the market since awhile with at least 2 version of MicroCodeStudio ( + ICD, + Bootloader, + Serial Communicator ), Easy HID, Proton IDE.
As i don't feel that Swordfish is a beginner, green, newbie dedicated compiler, potential new user should already know and trust Mecanique. If they don't already, they will shortly.
There's No need to be afraid of ANYTHING. It's certainly not like dealing with a new-kid-on-the-block. Once i knew Swordfish was a David's product, i knew it was going to be a nice tool even if pretty new on the market.
If it was made by another company, i would wait, at very least, few years before buying it... i got few bad experiences in the past.
Sure you can still decide to wait but, trust me and look how fast those few bugs reported in the past have been corrected. Usually the same day or the next day.
About polls... being on many forum since few years now and never felt they were really useful... but it's my own opinion.
EDIT: Tim, sorry but i can't understand the time saving using ISIS. Maybe i miss something or i try to make it much complicated as it should be... anyways. How many different way to skin a cat
I'm not a ICD fan, so to me modules, new feature are, by far, much important. You can still use a simple serial communication, a LCD or simply your brain to debug your program.
Most professional, beginner (or else level) already heard or know about Mecanique. They're on the market since awhile with at least 2 version of MicroCodeStudio ( + ICD, + Bootloader, + Serial Communicator ), Easy HID, Proton IDE.
As i don't feel that Swordfish is a beginner, green, newbie dedicated compiler, potential new user should already know and trust Mecanique. If they don't already, they will shortly.
There's No need to be afraid of ANYTHING. It's certainly not like dealing with a new-kid-on-the-block. Once i knew Swordfish was a David's product, i knew it was going to be a nice tool even if pretty new on the market.
If it was made by another company, i would wait, at very least, few years before buying it... i got few bad experiences in the past.
Sure you can still decide to wait but, trust me and look how fast those few bugs reported in the past have been corrected. Usually the same day or the next day.
About polls... being on many forum since few years now and never felt they were really useful... but it's my own opinion.
EDIT: Tim, sorry but i can't understand the time saving using ISIS. Maybe i miss something or i try to make it much complicated as it should be... anyways. How many different way to skin a cat
No code is released without intensive tests. But saying that a command will work or will not work is not correct. YES a command may work in some cases and fail in some other cases ... for three reasons :TimB wrote: I find that really a strange thing to say, how can you release code with out testing it? I see this from Pbro users saying some other compiler is unsafe to use, when in my opinion its all rubbish.
Think about it, any command will work or it will not work, I do not know any command that will fail in use that you could not spot as part of normal testing. I may be wrong, do you have and example?
1- Between versions, some commands implementation (asm code generated) may change.
2- the command may relay on some SFR registers set in a special way. I remember when, one year past, I worked for a company using HITEC C. Every people was saying that it's the best C compiler for PIC. The generated code was very versy compact and safe ... until you use more than 80% of a PIC16F877 RAM. In this special condition, the compiler was unable to manage BANK SWITCHING correctly !!!!!!
3- Any command will work or it will not work ! Binary is a wonderfull world ... but it's not the case for OPTIMIZING Compilers ... it may be true for compilers like PBP witch uses a simple template macro model, but not for an optimizing compiler !!! an optimizing compiler (like HITEC C) rework generated ASM code using different strategies to let you save time (optimizing for Speed) or space on your MCU. These optimisation depends on used and on the order in witch items appears in your code. Since some generate code will be collapsed, and other kept as it is, the result is not the same, and the results may be very imprevisible.
What I can say is that HITEC C bug with Bank switching hes obliged the company where I was working to recall about 2000 card to reflash them.
It's reality in industry world. When you deal with 200 line codes, you may
fully qualify to test your program 100%. But when you develop 400.000 lines programs, you can never say that you have produced BUG FREE software especially when your system is not "fully deterministic" (if I can use the term deterministic) witch is systematically the case when you use Real Time Operating Systems.
Even if all the modules you developed where 100% bug free, the combination of functionnalities may generate wrong functionning.
I have nothing against David or SwFBasic. I already said in other posts that I think that SwFBasic is one of the best compilers I have seen for PIC and I congratulate all the dev team.I think a list of wishes is not a bad thing and I know David has talked about producing a Under Development list. He would though be one of the first to do so.
I have already developed two compilers for other processors series than Microchip ones. I know that adding debug is not easy and will not be knocked up over night. I only says that it may be given more importance. More debug tools you will have and more speed and reliability you will have in developed modules.Re ICD I agree that one would be very handy, but having produced an ICD for another compiler I can say that for SF it would not be easy as its not a flat language so managing shared variables will so you only see your variable change when its active requires a complex Debug file generation system. Not something that get knocked up over night.
ISIS is fine but if you debug using only generated ASM is not an options for some programs. It's usable (even Microchip MPSIM ca be used) but it's not an option for very long programs. Stop thinking that people use a compiler to produce a 100 line basic programs, and about Big Memory PICS to store BITMAPS and Text Fonts. I have already worked for a company that used a PIC18F8722 to control a textile producing machine. The PIC was used to control about 60 motors and 37 captors (yes 60... there is no mistake in digits ....). I can certify that the firmware was (written in HITEC C) more that 700.000 line and that the PIC flash was about 95% filled with CODE only ...no bitmap not fonts was stored in flash. Do you think it's a serious option to debug such firmware using ISIS at ASM level and a serial line ? a Source code level debugging is very important .... perhaps the most important tool when you develop huge industrial programs.You can debug your code in ISIS as it stands. I do it all the time.
Your are free to think about SFWBasic as a hobbist tool, but I personaly think that it's so much well structured, that adding serious development tools arround it's compiler will make it a trully industrial production tool. In industry world, no (serious) one will integrate a compiler without debug feature in his development tool chain.
Best regards
Ok All noted, good points. Not that I see any of those issues every coming into play with any of my products.
Glad you see SF as such a serious product. Dave takes reliability as a No 1 priority.
I do most of my coding at the moment in another compiler and that has full ISIS support. ISIS is superb and I know Dave aims to tie in with it.
In fact I cannot commend it enough.....
The optermiser is always an issue and should never be used without proving it works with out it on first then test it carefully with when you do evoke it. IN SF its on by default.
Glad you see SF as such a serious product. Dave takes reliability as a No 1 priority.
I do most of my coding at the moment in another compiler and that has full ISIS support. ISIS is superb and I know Dave aims to tie in with it.
In fact I cannot commend it enough.....
The optermiser is always an issue and should never be used without proving it works with out it on first then test it carefully with when you do evoke it. IN SF its on by default.
I also think that a SOFTWARE simulator is (perhaps) more important that an ICD... but hardware emulators of any kind (and thus ICD) are mandatory when you are to debug circuits where analogic interfaces are used and where electrical properties of REAL PICS are needed in order to fine tune the circuit (for example for tunning filters). try to simulate ANALOG capture pins with mpsim or proteusxor wrote:While I think ICD to be a useful tool under some conditions, I still consider it more of a sluggish nuisance for stepping through code, whether source-code or asm. It is my personal opinion that a good software debugger/simulator is the most useful tool to a programmer.
Anyway what I meant from my post is that what is mandatory in SFWBasic in order to use it professionnaly is to add ANY KIND of debugging solution ... either by implementing a full COF file generation so we can use MPLAB and MPSIM and even PROTEUS VSM, or to add at least an ICD like the (ugly but very useful) one included in MicroCodeStudio Plus with PBP.
Best regards