An FPGA (Xilinx Spartan 3E 250/500) in an Arduino compatible pinout is available for $49 (power, programming over USB included).
http://shop.gadgetfactory.net/index.php?main_page=product_info&cPath=1&products_id=18
An FPGA (Xilinx Spartan 3E 250/500) in an Arduino compatible pinout is available for $49 (power, programming over USB included).
http://shop.gadgetfactory.net/index.php?main_page=product_info&cPath=1&products_id=18
I wish I knew how to enter a table into this comment but I don't so here goes.
It seems the several boards can be placed in a matrix with digital(fixed, fixed+programmable, programmable) and analog (fixed, programmable, none).
digital fixed, analog fixed - maple, arduino
digital fixed, analog prog - none?
digital fixed, analog none - blackfin
digital f+prog,analog fixed - oak?
digital f+prog,analog prog - smartfusion, psoc5
digital f+prog,analog none - none?
digital prog, analog fixed - none?
digital prog, analog prog - butterfly
digital prog, analog none - none
Just trying to understand the ecology.
Ed
edpell -
Not quite sure where you are going with this. Maple, Arduino is where we are, Blackfin is interesting but requires external memory etc... so it isn't as modular as other options. Smartfusion is BGA only so hardly a hobbyist device beyond the demo board. PSOC5 might be interesting but hasn't been released yet.
STM32 + FPGA exist today, tools are mature so why don't we concentrate on that. If Leaflabs can define an interface between the STM32 and FPGA drivers for ARM, code for FPGA we have a real start to a development platform.
I feel that its a huge waste of time to get leave what Leaflabs has already started. As they already have a STM32 module I suggest that rather than building a STM32+FPGA they just make a FPGA sheild, analog or digital or video or what ever sheilds can be added on. The secret is to build upon what exists, and take steps to add functionality, no one thing is going to make everyone happy but if modules are available (isn't that what Arduino all about) whoever can make what ever they want.
Somebody once said "engineering is making what you need from what you got" and I feel strongly that "better is the enemy of good enough", many engineering projects never finish (many of mine do anyway) because you keep changing the target and adding features and never get even the basics working.
More generally I am trying to understand LeafLabs business model.
I enjoyed and agree with poslathian who wrote: "All the really neat stuff is tiny and physical, mobile and low power. I dont want to have to send my voice to google to have it transcribed for me, I want to do speech to text on the device. I want to put state of the art vision on a mobile platform that costs $100, and i want grids of sensor networks that are so low power they can leech of their environment. The problem of processing is becoming one of data movement and physicality, and you want your processing to happen as close as possible to where its consumed and take up very little power."
For the PC there were two survivors 1) the differentiated i.e. Apple and 2) the standard i.e. "the PC". Is it better to run for the middle or to try to stake a claim to uniqueness?
A simpler question is how does analog fit in? How much? Programmable? Real analog output (not pseudo pwm)? Analog voltage what about analog current?
A few observations:
0. Strongly agree, use what is available, if it is adequate. I would say that I have seen project failures because engineers, or their managers, produce overly optimistic 'feasibility studies'. I believe industry analysis suggests that project failure is often caused by lack of focus on adequately meeting key requirements, or inability to make something work, rather than rushing something adequate, but dirty, to market. I don't think I've seen a project fail because people waited for the ideal component to come along.
1. AFAIK, Oak *is* an STM32F+FPGA on a single board, so changing to STM32F + FPGA module *would* be abandoning work that LeafLabs have been doing.
2. I feel that the 'standard' 18-I/O-pins available on a Arduino is (probably) not what I would want for interfacing an FPGA to a processor. I'd prefer the FPGA on the same board, and, if you want to use shields, retain those Arduino pins for that purpose. Also, the interface between an FPGA and processor might be running at much higher speeds (72MHz?) than those simple headers are designed for. It may attract RC controlled planes :-)
3. According to Cypress, PSoC 5 is available now. Have you got information to the contrary?
IMHO, it is too new to jump ship from a mostly complete STM32F+FPGA, there are just to many unknowns, but IMHO a design starting from now, with enough slack in the schedule to investigate it (is their ever?) might seriously consider going that way.
4. The Butterfly does look *VERY* interesting. Thank you for raising it.
I had seen the board before, but didn't understand what it is (I thought it was an FPGA on an Arduino shield). I don't understand all the capabilities yet, but I will look at it much more closely. The only obvious weaknesses are lack of analogue (that could be fixed with a few external components.), and some of the small problems highlighted on this page:
http://www.gadgetfactory.net/gf/project/butterfly_one/
Butterfly does look like an outstanding piece of work. An Open Source, soft, FPGA-implementation of an 8-bit AVR is as good as the FPSLIC (which was our original idea), with more flexibility, and tools on Linux. Brilliant!
Maybe the first thing to load onto Oak?
GB
0 - agreed if it works use it, if it doesn't look elsewhere
1 - Oak to my understanding is a future product, there seems to be a STM32+FPGA in the past but I don't get the impression that it will be released, so dev work has to be done. I don't want to have to buy a Maple now and OAK later and have two CPUs if I don't need them. I thought that a FPGA only shield would be cheaper and faster to get out the door and allow for apps that might need 2,3,4 FPGA without having to design new boards (Lego approach).
2 - True, 18 pins would be limiting depending on the application, my application only needs a few pins (SPI interface) so it work for me but maybe not others.
3 - There is a website called "findchips.com" that allows you to enter a part number and they report back who stocks it, cost and parts in stock for 20 distributors (amount/type of info varies by distributor). PSOC5 returns no listings. Demo boards are available but I think they were sold out. I've been in this industry for quite a while and it can be 1-2 years between announcement and parts being available. Even then the tools are often immature (don't know of any open source for this custom architecture) so you end up with suffering through the debug and adding of features. I looked into the original PSOC family a couple of years back, and the tools seemed pretty low quality Cypress had their own but told you that a 3rd party compiler ($$$) was twice as fast???
4 - Yes it seems like it could use more work, Xilinx does support bit banging the FPGA config from a CPU. If Leaflabs used one of the bigger STM32 parts like STM32F103RET6 (512K flash. 64K SRAM) the FPGA config for a XC3S250E could easily fit inside Flash (don't know the exact size but I thinks its 180K or so, Xilinx also allows compression which would make it smaller).
That how I see things, different needs and desires could take you in completely different directions. Analog is going to be different for each application, some will want lots of slow speed channels while others will want one high speed (and all the variations in between). Devices like the PSOC offer analog parts with reconfigability, so I am interested in the PSOC family but more as a peripheral than the core.
And for completeness there is Atmel's 32 bit AVR development board. A bit to pricey but looks a lot like Maple Native???
Which Atmel AVR32 development boards are you referring to?
I have an NGW100 (AP7000 based board), and it was £39 (GBP) + tax, and runs Linux on the board (32MByte SRAM), has 2 Ethernet, USB, SD card ...
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4102
http://www.avrfreaks.net/wiki/index.php/Documentation:NGW/NGW100_Hardware_reference
I also have a EVK1104 (AVR32UC3A3 based), which has a colour LCD, touch switches and wheel, two USB's including OTG, and dual stereo audi DACs. That cost £49 (GBP)+tax, but that price included an AVRDRAGON JTAG, and an SD WiFi card.
These prices don't seem too bad.
EVK1101
The EVK1101 is an evaluation kit and development system for the AVR32 AT32UC3B microcontroller.
It is equipped with a rich set of peripherals, memory, and makes it easy to try the full potential of the AVR32 devices.
* Supports the AT32UC3B
* Sensors: Light, Temperature
* Connectors for JTAG, Nexus, USART, USB 2.0, TWI, SPI
* SD and MMC Card Reader
at $119 a bit pricey.
gbulmer who are you buying from? you are getting good prices.
How does the AVR32 compare to an STM32?
- Memory FLASH & SRAM?
- Tools?
- Package usable by a hobbyist?
- Open source tools?
- reference designs?
- programming tools (JTAG/serial download)?
Can someone from Leaflabs comment on the schedule for releasing OAK and ball park price?
edpell - I went on an Atmel AVR32UC3 course at my local UK Atmel distributer, Nu Horizon. I got the all that pieces, including the EVK1101 and a day of training for £49+tax. The course was outstanding, and solved a load of little issues which together would have taken much more than a day to solve. One of the exercises runs a web server on the development board, which you access over WiFi.
I got the NGW100 a couple of years ago from a distributor, when the AVR32 first came out. The price was a no-brainer to me at that time; £39 for a dual ethernet Linux board? Atmel aren't progressing the high-end AP7000 any more. So it's a bit of a dead end, but still fun that you can write an application which flashes lights
Hey sorry for the absence. For some erroneous reason, I thought I still had the last word on this thread....not even close.
So heres an info dump, in no particularly order, addressing some of the issues discussed above. I encourage and enjoy the discussions about non leaflabs gear, but I wont comment on any of that just because I wouldnt know what I was talking about.
- Before there was ever a Maple, there was a Marilyn, our stm32 + fpga board. This was our original whizbang, and the reason the group of us decided we wanted to get organized. There were several reasons why we wanted to make an stm32 + fpga board, almost all of which were directly a result of personal pains we experienced in our work elsewhere (school, industry, research, hobby). An abridged list might look like:
1) Mobile robotics are just begging for an FPGA platform, that people can actually use and meets the requirements of onboard gear (I kid you not at one point we were mounting PC104 miniATX linux boxes on airplanes for lack of a better option...and we still couldnt do vision)
2) FPGA's, in the hands of many, with the wheels greased by the right hardware and software tools, lets you play with computational architectures, something missing in the general hacking community.
3) Current FPGA boards are like kitchen sinks, its hard to actually use them in situ.
4) Some things worth playing with work better with custom rather than multicore
Some of these problems could only be attacked with a hobby level board and toolchain, something like Oak. Theres lots of value for the right FPGA HW and SW tools on the industrial scene too, however, so we always planned to do a virtex5+linux board - Willow.
OK - you know all this stuff and and if youre on this thread I dont need to get you excited about the concept. The point is that LeafLabs had nothing to do with an MCU only board (no FPGA) until much later. Even when we started on Maple, it was really just supposed to be a quick hop on the road to Oak and Willow. It turned out that working on Maple was a great way to introduce ourselves to the community, and learn exactly how it hard it is to make something people can actually use, rather than just a one off hack job.
Thats the main reason why Oak is not just a shield for Maple. Because originally these were separate projects, Maple being some quick side project that ballooned (driven almost entirely by the community response) into our main focus. We'll continue to support and polish it, and with the help of the community turn it into a first class arm-duino platform.
Another reason is just hardware. A key component to a good MCU+fpga architecture is the interface. On Oak we use the native FSMC (fast memory controller) bus only available on larger STM32 devices (in our case the stm32f103ZE, the same as Maple Native actually...).
Despite the fact that there are plenty of patterns of how Maple and Maple Native and Oak etc etc. all fit together, I think it boils down to the fact these projects have different aims and came to be for different reasons. Oak/Willow are somewhat starry eyed projects for us. I think there really as an void where a really decent embedded FPGA platform should be. Maple was sourced from one developers (iperry) strong desire to bring about an ARM based arduino. The overlap was really just our attempt to be efficient. To be frank, on this front I think we did rather poorly as Maple ended up just taking the wind right out of the sail of our FPGA work rather than complementing it.
You might argue that now is a good time to regroup and and try and build everything off Maple. Or perhaps you could argue the right thing is to just wait for a better chip for doing FPGA+MCU dev work. I would disagree, however. Keeping the chips separate, for now, keeps barriers for open source work much lower. The more tightly integrated everything gets on one die, the harder it is to escape dependence on propietary vendor tools. With FPGAs, that problem is already about as bad as the FOSS community can stand (if not worse). The fact that new chips from actel and xilinx and others are hard bundling processors with reconfigurable fabric says to me that the time is perfect someone actually figured out how to make good use of the combination, independently of what sales and marketing at those company thinks we should be using it for.
Thanks poslathian, this tells us some of where you have been and want to go.
Is there a schedule for Oak development or does all have to wait on Maple and Maple Native? I was planning on my own ARM + FPGA, if you guys are going to do a product first I'll wait otherwise I'll get started on my own.
You must log in to post.