There are probably very few people on this forum who even know what a PIC compiler is. Are you sure that those who actually do at least understand what you are trying to accomplish?
Maybe you could elaborate on this?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Are you talking about programmable interrupt controllers? If so, I don't understand how you can link another compiler with a linker for a totally different compiler - or why you would want to, to begin with for that matter.
Kip
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just want to use an external compiler , who recognize
microchip commands (pic family) cos i can't compile my
c code with this prog. Is there a way to use an external compiler..?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
He is talking about PIC microcontrollers. I have experience with them myself. There is a great free compiler for this device callled JAL. There are also a few IDE's for this compiler. Do a google search on JAL.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2005-01-19
Dev-C++ supports GNU compilers. There is no GNU port for PIC. There is however a GNU port for Atmel AVR microcontrollers.
Generating the HEX file output would probably require makefile customisation by adding a "after-all" rule, since this is usually a separate step after linking.
One possible kludge would be to write a wrapper application that has a GNU like interface, but translates the parameters and passes them to the real compiler.
You might also use a custom makefile. This has the effect of making Dev-C++ little more than a text editor rather than an IDE, since the project tool is not used. There are probably better editors available.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just found this old thread, and I think it answers my question:
Dev C++ does not support using an external compiler.
I love DevC++ (it's lean and mean) and I too wish I could use it with my Microchip PIC (microcontroller - uC) or Ateml uC or any other uC I 'm currently using.
Since CCS has a cheap command line compiler, I would have loved using it as the compiler from DevC++... but alas I can't
all in all, I would love to use DevC++ for most of my projects, hopefully someday this feature will be supported
Thanks
Gary
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2006-02-27
Nothing in this thread says that!
It does support external compilers - in fact that is all it supports, the one it comes with by default is external. The problem is that these compilers must have a GCC interface. Dev-C++ even supports multiple alternate compiler sets.
There is a free PIC C compiler (SDCC) which I believe does support GCC command line parameters, so should be possible to make work as an alternate compiler set. You will still need ot use custom rules as described earlier. http://sdcc.sourceforge.net/
It is probably possible to kludge it for a non GCC-compiler by using a batch file or wrapper to make the toolchain look like GNU, or by using the command line override feature in combination with custom rules, or just use a custome makefile - but then Dev-C++ is little more than an editor, and there are plenty of them (Crimson Editor for example).
Ultimately however PICs are nasty cumbersome devices. Atmel AVR, and Zilog Z8s are much better. The problem with PICs is thier poor scalability, the PIC12, 16, an 18 series are not even compatible with eachother - requiring different development tools for each. Migration between AVR variants is much more consistent. The architectire of the PIC is also evidently not intended ot provide support for C code, the subsequent contortions that most C compilers have ot to go through make it a generally unpleasant experience.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry Clifford,
> Dev-C++ supports GNU compilers. There is no GNU port for PIC
I must have miss interpreted the intended meaning of the above sentence. - no harm I hope
I am aware of the SDCC compiler, but I'm unaware of it's pic maturaty. For instance, their news area on the SDCC site mentions the pic in 2001 but I havn't looked further... anyway... did I mention I all ready have the CCS compiler (and kind of have to use it)?
>It is probably possible to kludge it for a non GCC-compiler
I think I read that in your earlier post, which is a fix yes, but at that point there are other viable ide's
>Ultimately however PICs are nasty cumbersome devices.
this post wasn't intended to spawn any pic/avr battles... there are many many many threads on who's is bigger.
-but in this case, I have to agree that the AVR is better, but I have a proven FPGA pic core that I have to use... eventually I might be able to switch the core, but only highly unlikely... people fear change.
-but isn't the PIC18 series intended for C (not that I'm using the 18, but I have and the seem fine)
thanks
Gary
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2006-02-27
Nothing in this thread says that!
It does support external compilers - in fact that is all it supports, the one it comes with by default is external. The problem is that these compilers must have a GCC interface. Dev-C++ even supports multiple alternate compiler sets.
There is a free PIC C compiler (SDCC) which I believe does support GCC command line parameters, so should be possible to make work as an alternate compiler set. You will still need ot use custom rules as described earlier. http://sdcc.sourceforge.net/
It is probably possible to kludge it for a non GCC-compiler by using a batch file or wrapper to make the toolchain look like GNU, or by using the command line override feature in combination with custom rules, or just use a custome makefile - but then Dev-C++ is little more than an editor, and there are plenty of them (Crimson Editor for example).
Ultimately however PICs are nasty cumbersome devices. Atmel AVR, and Zilog Z8s are much better. The problem with PICs is thier poor scalability, the PIC12, 16, an 18 series are not even compatible with eachother - requiring different development tools for each. Migration between AVR variants is much more consistent. The architectire of the PIC is also evidently not intended ot provide support for C code, the subsequent contortions that most C compilers have to go through make it a generally unpleasant experience.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2006-02-28
Code::Blocks is probably also flexible enough to support CCS also.
Microchop's own MPLAB IDE is free and integrates with third-party C compilers. I reckon that this is your best bet since MPLAB in includes a PIC assembler, simulator, and debugger. CCS even have a MPLAB plug-in download for free. I can't think why you would not be using that?!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2006-02-28
Microchop was a typo, not a derogatory statement!
w.r.t PIC18 I have used them with Microchip's C compiler and it is still painful.
What FPGA are you using? I have been involved in FPGA development using Celoxica DK/Handle C - a C-like language to program the logic directly - expensive, but the performance potential is astounding since operations may occur in parallel with pipelining. Many C applications are easily ported to Handel-C.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's just too bad that the MPLAB IDE is a pain to work with (in my opinion anyway). There are all kinds of GUI issues with it. You can't dock the file view / 'project explorer' (nor any other windows for that matter). This also makes it pretty useless to maximize a code window, because then all windows get maximized (proper MDI behaviour, but annoying nonetheless).
When I was working on a PIC project the past half year, I had to work with MPLAB IDE anyway, because it seemed to be the only one supporting the MPLAB ICD2 (in-circuit debugger).
I would love to find an alternative though...
Paul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>I can't think why you would not be using that?!
did I say I wasn't? now were getting back to similar bad assumtions that I made earlier
I am using MPLAB... it's fine, but I like the feel of Dev C++ (tabs, better search, etc) (and basically everything Paul mentioned) but it does have a simulator built in which Dev C++ doesn't, so it seems I would still have to use mplab for some features.
--also CCS has a really nice IDE with their pcw version ($500ish vs $100ish).
check it out: http://www.ccsinfo.com/demo.shtml
FPGA - for development we are using an Altera APEX 20K, but we ultimatly we will be switching to a RadHard Aeroflex
I'll do some reading on Handle-C, but I'm unsure how efficient it will be at be with regard to realestate and performance.
I did get code::blocks working under the external tools areas because the compile just needs a file name, but linking to the correct include directory is problematic.
Thanks
Gary
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2006-02-28
If you are worried about "$500ish vs $100ish", then Handle-C is not for you! ($60,000ish). It is pretty efficient, likel any hardware description language you can screw it up, but it is mushc easier than VHDL and will execute algorithms much faster that an embedded core. Instructions can be made to execute in parallel, allowing single cycle operation or any number of independent operations and pipelining for operations that are not independent. There are many hand and automated optimization techniques, it runs as a front end to the FPGA vendors tools (ISE in the case of Xilinx), so the chip vendors optimisations and rooting are applied using Celoxica's already optimized netlist. Our experience is that it is pretty efficient, but our primary reason for its use is the complexity and performance requirements of our application, as well as the ease with which we can get software developers building hardware.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
again, did I say I was worried, just stating a fact for readers might be care.
I'm not spending my money, just government money... so morally, I would love it if I could use as much open source stuff as I could.. save some tax $ and even give back to the open source community
>as well as the ease with which we can get software developers building hardware.
one of my colleagues drew this out for me once, I laughed (because I'm an EE) but I don't know your background so you might not
hardware dev ----|>---- sofware dev
think of it like a diode, you can teach a hardware guy to program, but the software guy (or girl) can't flow the other direction (and yes I know that in reality, the current is actually flowing the opposite direction of our conventional notion)
--yes I'm sure there are some exceptions
ask a hardware person when they are describing a circuit with VHDL if the programming is going well, and they just might get mad (I personally don't care)
but there is some truth to the above, there is a lot of timing constraints, optimal io layout, highspeed signal paths (not just in the fpga)...fields... etc.
also, don't get the wrong idea about me, I am enjoying this thread...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
man, I love it when I hit submit just as I see an error... I guess if I would just log in I could change it.... oh well
ust stating a fact for readers might be care.
~should have been~
just stating a fact for all the readers that might care
Gary
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2006-02-28
Even logged in you can't edit posts. Typo is my middle name - witness 'rooting' earlier - no doubt any Austrailian readers are sniggering into thier keyboards right now!
Handle-C does allow you to apply timing constraints and supports automated 'retiming' to meet them. Also unlike a software compiler, the execution time of code elements are easily predicted - for example an assignment always takes exactly one clock cycle - regardless of teh assignment expression, that is dealt with by more logic rather than more time - splitting expressions and piplining them can reduce the logic if necessary while still producing one result per cycle (just delayed by the number of pipeline stages). Pipelining can also be used specifically to get one result per-cycle from algorithims that intrinsically require more than one cycle.
You cannot of course simply apply software semantics to the hardware, you get the best out of the product by having a deeper understanding of what is really happening (that what the training is for). Im my experience, Software guys have to paradigm shift toward the hardware - true concurrency, pipelining etc, while the H/W guys have to deal with the higher level of abstraction. They meet in the middle, and in our case at least work more closely as a result.
On the other hand, I am not sure I have ever seen a real-time ray-tracing algorithm implemented in VHDL or schematic logic, whereas I have seen in it in Handel-C. Algorithms to do such things are widely available in high level code and translating them to Handle-C is relatively straightforward. Other popular demos include real-time 3d rendering of a 'fly-over' landscape, A mandrelbrot set drawn in about a second on a 50MHz part, and Space Invaders. Actually Space Invaders should be easy, since the original 70's classic was implemented in discreet logic in any case, but I don't think the guys that wrote the demo knew that.
You might say that Handel-C is to VHDL what C is to assembler' although even that is rather a simplification, since Handel-C also supports mechanisms that require an operating system in C - such as concurrency, and interprocess communication.
The assumption about price sensitivity was from a combination of the suggested tool cost, and the fact that you have chosen to use a PIC, normally chosen for high volume low cost (although no doubt its implementation on an FPGA presumably has more to do with available IP and device capacity). You could place an ARM core on an FPGA (or MicroBlaze or NIOSII), but perhaps not in the space on your part?
I did originally train as an EE, but I would not say I had a flair for it (not analogue stuff at least!), I was programming long before I did that, and when I started my first job they offered me a choice of a software or hardware post, so I took the software (but did a little hardware on occasions). I am now of the opinion that while an EE can program (and most study it at college), that does not make him (or her) a software engineer, they tend to posess 'craft' skills in programming rather than 'engineering' skills. Of course it works both ways, I can read and understand a schematic and data sheets, and even suggest solutions (sometimes better ones), but I would have little idea how to design for EMC regulations (they didn't have those when I trained!), or take a high density SMT board to manufacture.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a demo of Impulse C sitting on my desk http://www.impulsec.com/ not sure how it compares to Handle-C. but I just might give it a quick spin and see how it compares to something I do in vhdl.
A while back I heard some people talking about using C to impliment some vision systems in an fpga... but I didn't give it much thought because I was swamped with my own project and I was thinking they would need a huge fpga to do it, but I must admit I don't know the c->fpga tools. I should touch base with them and find out how it's going.
>I was programming long before I did that, and when I started my first job they offered me a choice of a software or hardware post, so I took the software (but did a little hardware on occasions).
wow, me too, but I chose the EE title, but find myself doing a lot of coding (which I like to do) and a lot of embedded hardware (which I love to do)
>They meet in the middle, and in our case at least work more closely as a result.
--this is probabbly one of the best reasons to use it.
around here it's been hard getting the software guys more involved in the hardware, that's why my s/w experience comes in handy... I can better translate our needs... or just do it myself ;)
>EE can program (and most study it at college), that does not make him (or her) a software engineer
ya I agree... they study the basics of programming not advanced data structures and program organization...
but they could do it if they had to. and I guess that could be said for anyone doing anything now a days... all they need is the net/library card and willing to put in some time
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2006-03-01
The size of FPGA required would depend on what you are trying to achieive ('vision' covers a wide spectrum). We're using a Xilinx Spartan 3 - of course I cannot tell you what for!
How can i 'link' my pic compiler in this prog ?
i need when compiled an Hex output file..
There are probably very few people on this forum who even know what a PIC compiler is. Are you sure that those who actually do at least understand what you are trying to accomplish?
Maybe you could elaborate on this?
Are you talking about programmable interrupt controllers? If so, I don't understand how you can link another compiler with a linker for a totally different compiler - or why you would want to, to begin with for that matter.
Kip
I just want to use an external compiler , who recognize
microchip commands (pic family) cos i can't compile my
c code with this prog. Is there a way to use an external compiler..?
He is talking about PIC microcontrollers. I have experience with them myself. There is a great free compiler for this device callled JAL. There are also a few IDE's for this compiler. Do a google search on JAL.
Dev-C++ supports GNU compilers. There is no GNU port for PIC. There is however a GNU port for Atmel AVR microcontrollers.
Generating the HEX file output would probably require makefile customisation by adding a "after-all" rule, since this is usually a separate step after linking.
One possible kludge would be to write a wrapper application that has a GNU like interface, but translates the parameters and passes them to the real compiler.
You might also use a custom makefile. This has the effect of making Dev-C++ little more than a text editor rather than an IDE, since the project tool is not used. There are probably better editors available.
Clifford
Just found this old thread, and I think it answers my question:
Dev C++ does not support using an external compiler.
I love DevC++ (it's lean and mean) and I too wish I could use it with my Microchip PIC (microcontroller - uC) or Ateml uC or any other uC I 'm currently using.
Since CCS has a cheap command line compiler, I would have loved using it as the compiler from DevC++... but alas I can't
all in all, I would love to use DevC++ for most of my projects, hopefully someday this feature will be supported
Thanks
Gary
Nothing in this thread says that!
It does support external compilers - in fact that is all it supports, the one it comes with by default is external. The problem is that these compilers must have a GCC interface. Dev-C++ even supports multiple alternate compiler sets.
There is a free PIC C compiler (SDCC) which I believe does support GCC command line parameters, so should be possible to make work as an alternate compiler set. You will still need ot use custom rules as described earlier. http://sdcc.sourceforge.net/
It is probably possible to kludge it for a non GCC-compiler by using a batch file or wrapper to make the toolchain look like GNU, or by using the command line override feature in combination with custom rules, or just use a custome makefile - but then Dev-C++ is little more than an editor, and there are plenty of them (Crimson Editor for example).
Ultimately however PICs are nasty cumbersome devices. Atmel AVR, and Zilog Z8s are much better. The problem with PICs is thier poor scalability, the PIC12, 16, an 18 series are not even compatible with eachother - requiring different development tools for each. Migration between AVR variants is much more consistent. The architectire of the PIC is also evidently not intended ot provide support for C code, the subsequent contortions that most C compilers have ot to go through make it a generally unpleasant experience.
Clifford
Sorry Clifford,
> Dev-C++ supports GNU compilers. There is no GNU port for PIC
I must have miss interpreted the intended meaning of the above sentence. - no harm I hope
I am aware of the SDCC compiler, but I'm unaware of it's pic maturaty. For instance, their news area on the SDCC site mentions the pic in 2001 but I havn't looked further... anyway... did I mention I all ready have the CCS compiler (and kind of have to use it)?
>It is probably possible to kludge it for a non GCC-compiler
I think I read that in your earlier post, which is a fix yes, but at that point there are other viable ide's
>Ultimately however PICs are nasty cumbersome devices.
this post wasn't intended to spawn any pic/avr battles... there are many many many threads on who's is bigger.
-but in this case, I have to agree that the AVR is better, but I have a proven FPGA pic core that I have to use... eventually I might be able to switch the core, but only highly unlikely... people fear change.
-but isn't the PIC18 series intended for C (not that I'm using the 18, but I have and the seem fine)
thanks
Gary
Nothing in this thread says that!
It does support external compilers - in fact that is all it supports, the one it comes with by default is external. The problem is that these compilers must have a GCC interface. Dev-C++ even supports multiple alternate compiler sets.
There is a free PIC C compiler (SDCC) which I believe does support GCC command line parameters, so should be possible to make work as an alternate compiler set. You will still need ot use custom rules as described earlier. http://sdcc.sourceforge.net/
It is probably possible to kludge it for a non GCC-compiler by using a batch file or wrapper to make the toolchain look like GNU, or by using the command line override feature in combination with custom rules, or just use a custome makefile - but then Dev-C++ is little more than an editor, and there are plenty of them (Crimson Editor for example).
Ultimately however PICs are nasty cumbersome devices. Atmel AVR, and Zilog Z8s are much better. The problem with PICs is thier poor scalability, the PIC12, 16, an 18 series are not even compatible with eachother - requiring different development tools for each. Migration between AVR variants is much more consistent. The architectire of the PIC is also evidently not intended ot provide support for C code, the subsequent contortions that most C compilers have to go through make it a generally unpleasant experience.
Clifford
Code::Blocks supports SDCC.
http://www.codeblocks.org/
Code::Blocks is probably also flexible enough to support CCS also.
Microchop's own MPLAB IDE is free and integrates with third-party C compilers. I reckon that this is your best bet since MPLAB in includes a PIC assembler, simulator, and debugger. CCS even have a MPLAB plug-in download for free. I can't think why you would not be using that?!
MPLAB: http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469
The CCS Plugin: http://www.ccsinfo.com/download.shtml
Clifford
Microchop was a typo, not a derogatory statement!
w.r.t PIC18 I have used them with Microchip's C compiler and it is still painful.
What FPGA are you using? I have been involved in FPGA development using Celoxica DK/Handle C - a C-like language to program the logic directly - expensive, but the performance potential is astounding since operations may occur in parallel with pipelining. Many C applications are easily ported to Handel-C.
Clifford
It's just too bad that the MPLAB IDE is a pain to work with (in my opinion anyway). There are all kinds of GUI issues with it. You can't dock the file view / 'project explorer' (nor any other windows for that matter). This also makes it pretty useless to maximize a code window, because then all windows get maximized (proper MDI behaviour, but annoying nonetheless).
When I was working on a PIC project the past half year, I had to work with MPLAB IDE anyway, because it seemed to be the only one supporting the MPLAB ICD2 (in-circuit debugger).
I would love to find an alternative though...
Paul
thanks for the link, it looks nice, I'll have to give it a spin
Gary
>I can't think why you would not be using that?!
did I say I wasn't? now were getting back to similar bad assumtions that I made earlier
I am using MPLAB... it's fine, but I like the feel of Dev C++ (tabs, better search, etc) (and basically everything Paul mentioned) but it does have a simulator built in which Dev C++ doesn't, so it seems I would still have to use mplab for some features.
--also CCS has a really nice IDE with their pcw version ($500ish vs $100ish).
check it out:
http://www.ccsinfo.com/demo.shtml
FPGA - for development we are using an Altera APEX 20K, but we ultimatly we will be switching to a RadHard Aeroflex
I'll do some reading on Handle-C, but I'm unsure how efficient it will be at be with regard to realestate and performance.
I did get code::blocks working under the external tools areas because the compile just needs a file name, but linking to the correct include directory is problematic.
Thanks
Gary
If you are worried about "$500ish vs $100ish", then Handle-C is not for you! ($60,000ish). It is pretty efficient, likel any hardware description language you can screw it up, but it is mushc easier than VHDL and will execute algorithms much faster that an embedded core. Instructions can be made to execute in parallel, allowing single cycle operation or any number of independent operations and pipelining for operations that are not independent. There are many hand and automated optimization techniques, it runs as a front end to the FPGA vendors tools (ISE in the case of Xilinx), so the chip vendors optimisations and rooting are applied using Celoxica's already optimized netlist. Our experience is that it is pretty efficient, but our primary reason for its use is the complexity and performance requirements of our application, as well as the ease with which we can get software developers building hardware.
Clifford
>If you are worried about "$500ish vs $100ish"
again, did I say I was worried, just stating a fact for readers might be care.
I'm not spending my money, just government money... so morally, I would love it if I could use as much open source stuff as I could.. save some tax $ and even give back to the open source community
>as well as the ease with which we can get software developers building hardware.
one of my colleagues drew this out for me once, I laughed (because I'm an EE) but I don't know your background so you might not
hardware dev ----|>---- sofware dev
think of it like a diode, you can teach a hardware guy to program, but the software guy (or girl) can't flow the other direction (and yes I know that in reality, the current is actually flowing the opposite direction of our conventional notion)
--yes I'm sure there are some exceptions
ask a hardware person when they are describing a circuit with VHDL if the programming is going well, and they just might get mad (I personally don't care)
but there is some truth to the above, there is a lot of timing constraints, optimal io layout, highspeed signal paths (not just in the fpga)...fields... etc.
also, don't get the wrong idea about me, I am enjoying this thread...
man, I love it when I hit submit just as I see an error... I guess if I would just log in I could change it.... oh well
ust stating a fact for readers might be care.
~should have been~
just stating a fact for all the readers that might care
Gary
Even logged in you can't edit posts. Typo is my middle name - witness 'rooting' earlier - no doubt any Austrailian readers are sniggering into thier keyboards right now!
Handle-C does allow you to apply timing constraints and supports automated 'retiming' to meet them. Also unlike a software compiler, the execution time of code elements are easily predicted - for example an assignment always takes exactly one clock cycle - regardless of teh assignment expression, that is dealt with by more logic rather than more time - splitting expressions and piplining them can reduce the logic if necessary while still producing one result per cycle (just delayed by the number of pipeline stages). Pipelining can also be used specifically to get one result per-cycle from algorithims that intrinsically require more than one cycle.
You cannot of course simply apply software semantics to the hardware, you get the best out of the product by having a deeper understanding of what is really happening (that what the training is for). Im my experience, Software guys have to paradigm shift toward the hardware - true concurrency, pipelining etc, while the H/W guys have to deal with the higher level of abstraction. They meet in the middle, and in our case at least work more closely as a result.
On the other hand, I am not sure I have ever seen a real-time ray-tracing algorithm implemented in VHDL or schematic logic, whereas I have seen in it in Handel-C. Algorithms to do such things are widely available in high level code and translating them to Handle-C is relatively straightforward. Other popular demos include real-time 3d rendering of a 'fly-over' landscape, A mandrelbrot set drawn in about a second on a 50MHz part, and Space Invaders. Actually Space Invaders should be easy, since the original 70's classic was implemented in discreet logic in any case, but I don't think the guys that wrote the demo knew that.
You might say that Handel-C is to VHDL what C is to assembler' although even that is rather a simplification, since Handel-C also supports mechanisms that require an operating system in C - such as concurrency, and interprocess communication.
The assumption about price sensitivity was from a combination of the suggested tool cost, and the fact that you have chosen to use a PIC, normally chosen for high volume low cost (although no doubt its implementation on an FPGA presumably has more to do with available IP and device capacity). You could place an ARM core on an FPGA (or MicroBlaze or NIOSII), but perhaps not in the space on your part?
I did originally train as an EE, but I would not say I had a flair for it (not analogue stuff at least!), I was programming long before I did that, and when I started my first job they offered me a choice of a software or hardware post, so I took the software (but did a little hardware on occasions). I am now of the opinion that while an EE can program (and most study it at college), that does not make him (or her) a software engineer, they tend to posess 'craft' skills in programming rather than 'engineering' skills. Of course it works both ways, I can read and understand a schematic and data sheets, and even suggest solutions (sometimes better ones), but I would have little idea how to design for EMC regulations (they didn't have those when I trained!), or take a high density SMT board to manufacture.
Clifford
You do make Handle-C sound appealing.
I have a demo of Impulse C sitting on my desk http://www.impulsec.com/ not sure how it compares to Handle-C. but I just might give it a quick spin and see how it compares to something I do in vhdl.
A while back I heard some people talking about using C to impliment some vision systems in an fpga... but I didn't give it much thought because I was swamped with my own project and I was thinking they would need a huge fpga to do it, but I must admit I don't know the c->fpga tools. I should touch base with them and find out how it's going.
>I was programming long before I did that, and when I started my first job they offered me a choice of a software or hardware post, so I took the software (but did a little hardware on occasions).
wow, me too, but I chose the EE title, but find myself doing a lot of coding (which I like to do) and a lot of embedded hardware (which I love to do)
>They meet in the middle, and in our case at least work more closely as a result.
--this is probabbly one of the best reasons to use it.
around here it's been hard getting the software guys more involved in the hardware, that's why my s/w experience comes in handy... I can better translate our needs... or just do it myself ;)
>EE can program (and most study it at college), that does not make him (or her) a software engineer
ya I agree... they study the basics of programming not advanced data structures and program organization...
but they could do it if they had to. and I guess that could be said for anyone doing anything now a days... all they need is the net/library card and willing to put in some time
The size of FPGA required would depend on what you are trying to achieive ('vision' covers a wide spectrum). We're using a Xilinx Spartan 3 - of course I cannot tell you what for!
Handel-C is the core of the Celoxica-DK toolchain: http://www.celoxica.com/products/dk/default.asp
PS: I don't work for Celoxica BTW ;)
Clifford