Hi everybody.
Just to let you know, we have now begun work on the next version of FlowCode. The main set of new features are:
* improved UI
* 18F compatability
* 16-bit support
* string support
* better underlying C compiler
* ability to see generated C code
* entry of numbers in decimal, hex or binary
There are lots of other improvements on the cards. If you have any specific requests that are missing from the above, please let me know and I'll see if we can add them to the list.
It's too early to say when we'll finish this next version, but I'm hopful for the end of Spring.
Watch this space!
FlowCode v3
-
jimhumphries
- Posts: 112
- Joined: Wed Oct 12, 2005 6:29 pm
- Location: USA
- Been thanked: 1 time
- Contact:
Steve:
Here is what I was hoping for in v3:
1) Two-byte math option for at least the +, -, * and / operators.
It sounds like v3 will support 16 bit math. It even sounds like you're planning to provide floating point. Is that the true? You guys seem so flat-out against it in the v2 tutorials.
2) Ability to run the A/D flat-out.
The 18Fxxx series data sheets say 100K sample/sec capability. Will we be able to get even close to that performance with v3?
3) 4 line by 20 character LCD support and a fix for the LCD pin-out problem.
Ian's post with the patch takes care of the fix. Any hope for the expanded 4 X 20 support?
4) Expanded error messaging - a little more descriptive detail about what went wrong when (on the rare occasion) it does go wrong.
But, of course, nothing will go wrong with v3
5) Ability to attach Flowcode programs to Forum messages and/or the ability to share snippets of code via the Forum.
This really isn't in the v3 realm but it would be a nice feature for the Forum when there's something neat to share.
I can't wait - plug me in!
Jim
Here is what I was hoping for in v3:
1) Two-byte math option for at least the +, -, * and / operators.
It sounds like v3 will support 16 bit math. It even sounds like you're planning to provide floating point. Is that the true? You guys seem so flat-out against it in the v2 tutorials.
2) Ability to run the A/D flat-out.
The 18Fxxx series data sheets say 100K sample/sec capability. Will we be able to get even close to that performance with v3?
3) 4 line by 20 character LCD support and a fix for the LCD pin-out problem.
Ian's post with the patch takes care of the fix. Any hope for the expanded 4 X 20 support?
4) Expanded error messaging - a little more descriptive detail about what went wrong when (on the rare occasion) it does go wrong.
But, of course, nothing will go wrong with v3
5) Ability to attach Flowcode programs to Forum messages and/or the ability to share snippets of code via the Forum.
This really isn't in the v3 realm but it would be a nice feature for the Forum when there's something neat to share.
I can't wait - plug me in!
Jim
Flowcode v3
Please add the following to V3
Watch dog timer ON / OFF function.
Clock speeds down to 32 KHZ. (Low power mode)
EEprom code for each PIC type.
The ability to store comments for each flow box, that will be in the .ASM file,
(this is to help with debuging software)
The ability to label the switches and LED’s
Keep the C code and ASM support.
Remove bugs that cause the simulator to crash.
Watch dog timer ON / OFF function.
Clock speeds down to 32 KHZ. (Low power mode)
EEprom code for each PIC type.
The ability to store comments for each flow box, that will be in the .ASM file,
(this is to help with debuging software)
The ability to label the switches and LED’s
Keep the C code and ASM support.
Remove bugs that cause the simulator to crash.
-
Steve
- Matrix Staff
- Posts: 3424
- Joined: Tue Jan 03, 2006 3:59 pm
- Has thanked: 114 times
- Been thanked: 422 times
- Contact:
Thanks for the feedback, everyone. Here's a quick response to some of the specifics:
* 16-bit math - yes
* floating point - probably not
* a/d - this can be achieved already using embedded C / Asm code. We'll look into the possibility of customising the a/d conversions from within FlowCode itself.
* LCD pinout bug fix - done
* 4 by 20 LCD support - I was planning to do this, but someone ran off with my LCD (seriously!). We'll hopefully do this one.
* error messaging - any errors tend to be generated by the underlying C compiler, and all these messages will be available in v3. I currently use a trick to do this involving a batch file - I'll post something separately for this.
* watchdog timer support - probably not (has too many implications for delay routines and component macros - sorry)
* 32kHz clock speed - it does already (type it in directly, rather than selecting the value in the drop-down)
* EEPROM code for each PIC type - not 100% sure what you mean here
* Store comments in the ASM - you can partially do this already by using the "-SRC" switch in the C-compiler entry in the "compiler options" dialog. But yes, we will improve this area in general.
* labels for switches and LEDs - good idea, I'll look into this.
* Simulator crashes - please get in touch with our tech support team (support@matrixmultimedia.co.uk) and tell them the specific problems.
* Passing variables to macros - yes, I'd like to see this one. We'll try!
* 16-bit math - yes
* floating point - probably not
* a/d - this can be achieved already using embedded C / Asm code. We'll look into the possibility of customising the a/d conversions from within FlowCode itself.
* LCD pinout bug fix - done
* 4 by 20 LCD support - I was planning to do this, but someone ran off with my LCD (seriously!). We'll hopefully do this one.
* error messaging - any errors tend to be generated by the underlying C compiler, and all these messages will be available in v3. I currently use a trick to do this involving a batch file - I'll post something separately for this.
* watchdog timer support - probably not (has too many implications for delay routines and component macros - sorry)
* 32kHz clock speed - it does already (type it in directly, rather than selecting the value in the drop-down)
* EEPROM code for each PIC type - not 100% sure what you mean here
* Store comments in the ASM - you can partially do this already by using the "-SRC" switch in the C-compiler entry in the "compiler options" dialog. But yes, we will improve this area in general.
* labels for switches and LEDs - good idea, I'll look into this.
* Simulator crashes - please get in touch with our tech support team (support@matrixmultimedia.co.uk) and tell them the specific problems.
* Passing variables to macros - yes, I'd like to see this one. We'll try!
-
jimhumphries
- Posts: 112
- Joined: Wed Oct 12, 2005 6:29 pm
- Location: USA
- Been thanked: 1 time
- Contact:
Steve:
I don't know how I got the impression that you were going to add floating point. I think I halucinated on the bit about entering numbers in decimal, hex or binary to read "you can put the decimal point anywhere you want". Anyway, FP would be nice but 16 bit math will be a great improvement.
On the A/D macro - please don't give up on adding rate control to the component setup. It is truly a pain to have to edit the .ASM file every time you compile (or re-compile) some Flowcode to change the acquisition delay values for up to eight A/D channels. It's also problematic not to be able to utilize the full acquisition rate capability of the A/D. It puts many potential applications (i.e., stereo audio) out-of-reach.
Jim
I don't know how I got the impression that you were going to add floating point. I think I halucinated on the bit about entering numbers in decimal, hex or binary to read "you can put the decimal point anywhere you want". Anyway, FP would be nice but 16 bit math will be a great improvement.
On the A/D macro - please don't give up on adding rate control to the component setup. It is truly a pain to have to edit the .ASM file every time you compile (or re-compile) some Flowcode to change the acquisition delay values for up to eight A/D channels. It's also problematic not to be able to utilize the full acquisition rate capability of the A/D. It puts many potential applications (i.e., stereo audio) out-of-reach.
Jim
-
Steve
- Matrix Staff
- Posts: 3424
- Joined: Tue Jan 03, 2006 3:59 pm
- Has thanked: 114 times
- Been thanked: 422 times
- Contact:
Hi Jim,
Yes - I'll have a look, but the one thing I do not want to do with this next interation of FlowCode is overcomplicate things. One of FlowCode's biggest strengths is that it allows people with practically no knowlegde of programming or of PICs to get relatively complex programs up and running quickly.
Your best bet may be to create your own mini ADC macro (in assembly or C) that is optimised for your own acquisition needs. Email me an example of how you are editing the ASM code and I'll see what I can do.
Yes - I'll have a look, but the one thing I do not want to do with this next interation of FlowCode is overcomplicate things. One of FlowCode's biggest strengths is that it allows people with practically no knowlegde of programming or of PICs to get relatively complex programs up and running quickly.
Your best bet may be to create your own mini ADC macro (in assembly or C) that is optimised for your own acquisition needs. Email me an example of how you are editing the ASM code and I'll see what I can do.
-
jimhumphries
- Posts: 112
- Joined: Wed Oct 12, 2005 6:29 pm
- Location: USA
- Been thanked: 1 time
- Contact:
Thanks Steve. That is appreciated and I can continue to edit the .ASM files if need be.
Perhaps a User-adjustable parameter like the RS232 receive "timeout" value. I don't know what that does so I just leave it at the 0 default value.
Something similar in the sampleADC properties dialog would be great. You even have an opening for it under "Parameters:". This parameter could just default to your 220 value.
Jim
Perhaps a User-adjustable parameter like the RS232 receive "timeout" value. I don't know what that does so I just leave it at the 0 default value.
Something similar in the sampleADC properties dialog would be great. You even have an opening for it under "Parameters:". This parameter could just default to your 220 value.
Jim
-
jimhumphries
- Posts: 112
- Joined: Wed Oct 12, 2005 6:29 pm
- Location: USA
- Been thanked: 1 time
- Contact:
Steve:
Another thought on this -
You guys must know that beyond being a terrific teaching tool Flowcode is a fantastic rapid prototyping tool. I can now do things with PICs using Flowcode that I never thought I could do without having to make a career out of programming.
From that perspective, wouldn't it make sense to allow Users to access the Flowcode component and macrocode to customize and then save as a new component without getting too involved with C2C and Visual Basic?
If Users could do that they could create their our own custom libraries of components including, for example, a FAST_THERMOMETER (or, better yet, a FAST_SIGNAL_IN component) with a short setup time that would, otherwise, retain the same look, feel and behavior of the existing THERMOMETER.
These "custom" components and related macrocode could be posted and shared. Users who are facile with Visual Basic (I am not) could even create new I/O objects. I think you already offer a way to do this outside of Flowcode with SDK but that seems very complicated to me.
Jim
Another thought on this -
You guys must know that beyond being a terrific teaching tool Flowcode is a fantastic rapid prototyping tool. I can now do things with PICs using Flowcode that I never thought I could do without having to make a career out of programming.
From that perspective, wouldn't it make sense to allow Users to access the Flowcode component and macrocode to customize and then save as a new component without getting too involved with C2C and Visual Basic?
If Users could do that they could create their our own custom libraries of components including, for example, a FAST_THERMOMETER (or, better yet, a FAST_SIGNAL_IN component) with a short setup time that would, otherwise, retain the same look, feel and behavior of the existing THERMOMETER.
These "custom" components and related macrocode could be posted and shared. Users who are facile with Visual Basic (I am not) could even create new I/O objects. I think you already offer a way to do this outside of Flowcode with SDK but that seems very complicated to me.
Jim
I agree with Jim above. Flow Code is great for begginers
but is also excellent for advanced users. Try write a function generator application in 1/2 hour or less in asm.
My ideas for V3 are:
Flow chart managment (move the blocks to where I want).
Color option for each block type.
PWM output tool
bigger text box in decission block ( If_to small)
external memory (CF)
Zigbee tool
Fix file name size limit (maybe its a mpasm issue)
It would be nice if you had the option to use dials instead of the slide pot.
High pin count chip support.
I cant wait for V3. Chet
but is also excellent for advanced users. Try write a function generator application in 1/2 hour or less in asm.
My ideas for V3 are:
Flow chart managment (move the blocks to where I want).
Color option for each block type.
PWM output tool
bigger text box in decission block ( If_to small)
external memory (CF)
Zigbee tool
Fix file name size limit (maybe its a mpasm issue)
It would be nice if you had the option to use dials instead of the slide pot.
High pin count chip support.
I cant wait for V3. Chet
Watchdog idea
Watchdog
I have a solution that would allow watchdog use with minimal changes, and no complicated changes to Flowcode use.
When you insert a Flowcode delay, (in the ASM code) to make the timing corrections in the delay loop you use NOP. You could just replace one or all of them with WDTCLR.
This would clear the watchdog in all delay routines, If you need a to insert a WDTCLR in the flow chart, just add a 1 millisecond delay. (That would suffice for most software, but if it messes up your timing, you can still add it to the ASM later.
Printing.
A way to compact the printing, when zooming in and out it should print smaller. This would allow more of the Flowcode chart on one page.
Cruzxia
I have a solution that would allow watchdog use with minimal changes, and no complicated changes to Flowcode use.
When you insert a Flowcode delay, (in the ASM code) to make the timing corrections in the delay loop you use NOP. You could just replace one or all of them with WDTCLR.
This would clear the watchdog in all delay routines, If you need a to insert a WDTCLR in the flow chart, just add a 1 millisecond delay. (That would suffice for most software, but if it messes up your timing, you can still add it to the ASM later.
Printing.
A way to compact the printing, when zooming in and out it should print smaller. This would allow more of the Flowcode chart on one page.
Cruzxia
-
Steve
- Matrix Staff
- Posts: 3424
- Joined: Tue Jan 03, 2006 3:59 pm
- Has thanked: 114 times
- Been thanked: 422 times
- Contact:
Wow - all of this feedback is fantastic and we'll try our best to accommodate it.
Jim - I think you've convinced me on the ADC option thing. And you are correct - the SDK is far too complicated. We have started to externalise the code for the more advanced components as a way of speeding up our own developments.
This has got me thinking about the ADC issue and I've just realised that you already do have access to the ADC routines if you want. These are actually contained in the FCD files for the appropriate chip. I'll put up a separate post on this in a minute.
Chet - thanks for the suggestions. I can comment on a few of them now:
* CF - we have made an MMC E-Block and will be writing a FlowCode component for this soon. I know this is not CF, but it's a similar kind of thing. I think we avoided CF because it either needs a load more pins, or because it is more complicated.
* Zigbee - I'm personally itching to do some Zigbee work, but I've got a lot on my plate at the moment. Hopefully I'll get around to this in the summer.
* High pin-count chip support - good idea.
* File name size limit - this is an inherent problem with the COD files generated by MPASM (I think), so it's out of our hands.
Cruzxia: at the moment, the delay routines are generated by the C2C compiler, so are out of our control. As we are moving to BoostC, I will check its features and see if it gives us WDT support. Having said this, it may still be a bit too tricky because all of the current components are not written with WDT support in mind.
And yes - the printing support is poor at the moment. We are definitely going to do something about this.
Jim - I think you've convinced me on the ADC option thing. And you are correct - the SDK is far too complicated. We have started to externalise the code for the more advanced components as a way of speeding up our own developments.
This has got me thinking about the ADC issue and I've just realised that you already do have access to the ADC routines if you want. These are actually contained in the FCD files for the appropriate chip. I'll put up a separate post on this in a minute.
Chet - thanks for the suggestions. I can comment on a few of them now:
* CF - we have made an MMC E-Block and will be writing a FlowCode component for this soon. I know this is not CF, but it's a similar kind of thing. I think we avoided CF because it either needs a load more pins, or because it is more complicated.
* Zigbee - I'm personally itching to do some Zigbee work, but I've got a lot on my plate at the moment. Hopefully I'll get around to this in the summer.
* High pin-count chip support - good idea.
* File name size limit - this is an inherent problem with the COD files generated by MPASM (I think), so it's out of our hands.
Cruzxia: at the moment, the delay routines are generated by the C2C compiler, so are out of our control. As we are moving to BoostC, I will check its features and see if it gives us WDT support. Having said this, it may still be a bit too tricky because all of the current components are not written with WDT support in mind.
And yes - the printing support is poor at the moment. We are definitely going to do something about this.
-
jimhumphries
- Posts: 112
- Joined: Wed Oct 12, 2005 6:29 pm
- Location: USA
- Been thanked: 1 time
- Contact:
Steve:
Fantastic. I too can use a PWM macro. One that utilizes the PIC PWM peripheral is probably best for me but I would be happy to have either and I can appreciate the versatility of a "peripheral independent" version (my application would utilize this to implement D to A converters).
I am very happy to hear that A/D acquisition time/rate will be selectable. In the mean time I can and will use your suggestion to edit the A/D routine for the 16F876. I believe that the only limitation with that approach is that I will be constrained to use one value for the delay throughout my code for any single application (or, it's back to editing that value in the .ASM file for each channel requiring a different delay or making a go of Ian's suggestion to do this using different A/d snippets in code boxes). This, of course, is solved if the delay is selectable as a parameter in the macro call for each "thermometer" component.
Had you come to any conclusion yet regarding an I2C component for v3? This too would be very useful, as other members have already pointed out.
Jim
Fantastic. I too can use a PWM macro. One that utilizes the PIC PWM peripheral is probably best for me but I would be happy to have either and I can appreciate the versatility of a "peripheral independent" version (my application would utilize this to implement D to A converters).
I am very happy to hear that A/D acquisition time/rate will be selectable. In the mean time I can and will use your suggestion to edit the A/D routine for the 16F876. I believe that the only limitation with that approach is that I will be constrained to use one value for the delay throughout my code for any single application (or, it's back to editing that value in the .ASM file for each channel requiring a different delay or making a go of Ian's suggestion to do this using different A/d snippets in code boxes). This, of course, is solved if the delay is selectable as a parameter in the macro call for each "thermometer" component.
Had you come to any conclusion yet regarding an I2C component for v3? This too would be very useful, as other members have already pointed out.
Jim
Suggestions For V3...
Hello Steve,
How about some ir remote control stuff to work with the eblocks ir board. I know there a mass of different systems out there but the common ones eg RC5/RC6/Sony could easily be included.
A macro to transmit, TxIR-RC5, TxIR-RC6, TxIR-Sony etc in the properties would be really useful and make Flowcode more "real world" if you get what I mean.
I have the C and Pic Basic source to perform the above but calling the routines from Flowcode is beyond me!
Best regards,
James
How about some ir remote control stuff to work with the eblocks ir board. I know there a mass of different systems out there but the common ones eg RC5/RC6/Sony could easily be included.
A macro to transmit, TxIR-RC5, TxIR-RC6, TxIR-Sony etc in the properties would be really useful and make Flowcode more "real world" if you get what I mean.
I have the C and Pic Basic source to perform the above but calling the routines from Flowcode is beyond me!
Best regards,
James
-
Steve
- Matrix Staff
- Posts: 3424
- Joined: Tue Jan 03, 2006 3:59 pm
- Has thanked: 114 times
- Been thanked: 422 times
- Contact:
Hi James,
We are always interested in new ideas for components and we do develop new components from time to time. It is a question of finding the time to do them.
Please email the code to me and I will have a quick look at it with a view to driving it from FlowCode. If it looks easy to incorporate, I'll see what I can do. If not, I'll try to give you some pointers to enable you to get started on this. Either way, we could end up with some kind of remote-control component for FlowCode, which will benefit all of our users and (as you say) be more "real-world".
As an aside, our IrDA E-Block is good for IrDA work and you can use it for more simple Ir communications. But it is a bit overpriced if all it is used for is Ir (because it has 2 chips dedicated to IrDA communication that will be essentially redundant). We do intend to make a new Ir-only E-Block in the next few months - but again, this depends on finding the time...
We are always interested in new ideas for components and we do develop new components from time to time. It is a question of finding the time to do them.
Please email the code to me and I will have a quick look at it with a view to driving it from FlowCode. If it looks easy to incorporate, I'll see what I can do. If not, I'll try to give you some pointers to enable you to get started on this. Either way, we could end up with some kind of remote-control component for FlowCode, which will benefit all of our users and (as you say) be more "real-world".
As an aside, our IrDA E-Block is good for IrDA work and you can use it for more simple Ir communications. But it is a bit overpriced if all it is used for is Ir (because it has 2 chips dedicated to IrDA communication that will be essentially redundant). We do intend to make a new Ir-only E-Block in the next few months - but again, this depends on finding the time...
Find word search
Hi Steve
Please add Find & Find Next, to the edit menu, This would allow you to find a variable, macro and text quickly with out having to go through pages of Flowcode charts to find where you used them. This would be useful on long complicated routines, especially if you have to modify it six months later.
javascript:emoticon(':idea:')
Idea
Please add Find & Find Next, to the edit menu, This would allow you to find a variable, macro and text quickly with out having to go through pages of Flowcode charts to find where you used them. This would be useful on long complicated routines, especially if you have to modify it six months later.
javascript:emoticon(':idea:')
Idea
Steve
PWM peripheral would work for me, what would be important is high resolution (16 bits).
Other things coming to mind for V3:
Please "tighten up" the general macro function, I rarely use it beacuse
I seem to get more compiler complaints when I do. On the other hand
it would be nice to see a large program stuffed into several macros
to keep it neat and simple.
option to hide components from tool bar
PWM peripheral would work for me, what would be important is high resolution (16 bits).
Other things coming to mind for V3:
Please "tighten up" the general macro function, I rarely use it beacuse
I seem to get more compiler complaints when I do. On the other hand
it would be nice to see a large program stuffed into several macros
to keep it neat and simple.
option to hide components from tool bar
-
Dan81
- Valued Contributor
- Posts: 268
- Joined: Sun Jan 15, 2006 4:07 pm
- Location: Albi France
- Been thanked: 60 times
- Contact:
A very interesting topic
A little suggestion for RB0-interrupt :
Choosing the edge activy (like choosing the prescale value for timer) would be great.
a PWM macro would be welcome.
I use Flowcode v2 with my students (6 and 7 level), they like to see if their program will work at once (or not).
Daniel
A little suggestion for RB0-interrupt :
Choosing the edge activy (like choosing the prescale value for timer) would be great.
a PWM macro would be welcome.
I use Flowcode v2 with my students (6 and 7 level), they like to see if their program will work at once (or not).
Daniel
-
Steve
- Matrix Staff
- Posts: 3424
- Joined: Tue Jan 03, 2006 3:59 pm
- Has thanked: 114 times
- Been thanked: 422 times
- Contact:
Wow - the feedback this topic is generating is fantastic. Thanks to all who are writing, and keep it coming in.
I'm not going to spend any time saying yes or no to specific items yet, but I will refer heavily to this thread during the product's development.
I will answer a specific point here. Chet wrote:
Please get in touch with our technical support with specific examples of problems you've been encountering and we'll see if we can solve them.
I'm not going to spend any time saying yes or no to specific items yet, but I will refer heavily to this thread during the product's development.
I will answer a specific point here. Chet wrote:
Chet, I find that macros generally work fine (I know of one bug that is a priority to fix, but other than that, macros seem to be ok). In fact - I see it as an essential feature of any programming language.Please "tighten up" the general macro function, I rarely use it beacuse I seem to get more compiler complaints when I do.
Please get in touch with our technical support with specific examples of problems you've been encountering and we'll see if we can solve them.