zwabbit Posted October 1, 2012 Report Share Posted October 1, 2012 This is just a general question, but assuming you loaded the AVR8 soft core, why exactly did the Arduino IDE need modification in order to upload sketches to it? Is it to get the bootloader on there as well? Link to comment Share on other sites More sharing options...
Jack Gassett Posted October 1, 2012 Report Share Posted October 1, 2012 Hello zwabbit,The modifications that were done are the following (bear with me, this was done some time ago):An option to call a makefile for Papilio board types was added.When you select a Papilio board all the parameters are passed to the makefile and the makefile does all the heavy liftingThe arduino IDE works normally up to the point where the hex file is generated by avr-gcc.At this point, instead of calling an arduino programmer the Papilio makefile is called instead.Then, the hex file is converted into a mem file,the mem file is merged into the AVR8 bit file,the merged bit file is loaded to the Papilio, all of which is handled by the makefile.Jack. Link to comment Share on other sites More sharing options...
zwabbit Posted October 3, 2012 Author Report Share Posted October 3, 2012 Ah, so the softcore does not quite duplicate the Arduino UNO configuration.I noticed in another thread that someone else asked about using Arduino shields with the Papilio One. Assuming one was prepared to do the wiring due to the differing shapes and fill in whatever was missing in the AVR8 softcore, are there any electrical considerations that make the Papilio One incompatible with the shields? Ie, differing voltages in the pins and whatnot. Link to comment Share on other sites More sharing options...
neslekkim Posted October 3, 2012 Report Share Posted October 3, 2012 It's only 3.3 volt on the papilio.. I bought an bufferwing that I hope can help with that. Link to comment Share on other sites More sharing options...
Jack Gassett Posted October 3, 2012 Report Share Posted October 3, 2012 Ah, so the softcore does not quite duplicate the Arduino UNO configuration.I noticed in another thread that someone else asked about using Arduino shields with the Papilio One. Assuming one was prepared to do the wiring due to the differing shapes and fill in whatever was missing in the AVR8 softcore, are there any electrical considerations that make the Papilio One incompatible with the shields? Ie, differing voltages in the pins and whatnot.The softcore is based on an atmega103 so there are some differences with some peripherals, most noticeably the UART. It usually just requires a couple lines of code to be changed, but it is a nuisance. There are two approaches to solve this problem.1) Add C macros for the registers that are missing for the atmega103. Filling in the blanks like you say.2) RuslanL gave me a copy of vhdl code that implements an atmega128, If I got the time to replace the atmega103 (AVR8) core with this one then we would have complete arduino compatibility. (This is the preferred approach)It's funny that you mention using Arduino Shields, I actually put together a first cut at a dual Arduino Shield MegaWing this weekend. Like neslekkim says, the Papilio is 3.3V so a good Arduino shield solution will need to be 5V tolerant. There are two ways to accomplish 5V tolerance:1) Use current limiting resistors - The Spartan chips have clamping diodes that allow the I/O pins to handle 5V inputs if a current limiting resistor is used. The downside of this approach is that the clamping diode's will produce reverse current on the 2.5V voltage regulator whenever there is overvoltage, the amount of reverse current depends on how many pins are overvoltage. Using the current limiting resistor approach is inexpensive and works well, but I worry that if we use it for 28+ pins we will potentially be generating a LOT of reverse current. The RPAR resistor is a current shunt in the Papilio One design that is meant to dissipate the reverse current before it reaches the voltage regulator. I worry that with so many pins we will be wasting a lot of energy and heating that resistor up quite a bit...2) Bus Switch - For this application I think the safe bet is to go with a couple bus switches. They can be configured as bi-directional level translators that will not generate any reverse current.In both cases we are providing 5V tolerance but not full 5V level translation. Meaning, we can apply 3.3V-7V voltages to the Papilio without damaging it, but the output of the Papilio pins is still going to be 3.3V. 99% of the time this is going to be fine because 3.3V is still considered a 'High' in 5V logic.Jack. Link to comment Share on other sites More sharing options...
neslekkim Posted October 3, 2012 Report Share Posted October 3, 2012 5 tolerance, how will this compare to these methods? https://www.adafruit.com/products/395 and https://www.adafruit.com/products/757It seems to be some issues with the first one, for i2c usage, but using bss138 works better.On the other hand, I found an thread discussing the usage of bss138 (but i lost the url), that it was not an good choice due to similar reasons as your point 1, wasting energy etc.the io buffer wing, is that using an bus switch? Link to comment Share on other sites More sharing options...
zwabbit Posted October 3, 2012 Author Report Share Posted October 3, 2012 What would replacing the atmega103 with the, wait, 128 or 168, in the arduino core entail? Link to comment Share on other sites More sharing options...
Jack Gassett Posted October 3, 2012 Report Share Posted October 3, 2012 5 tolerance, how will this compare to these methods? https://www.adafruit.com/products/395 and https://www.adafruit.com/products/757It seems to be some issues with the first one, for i2c usage, but using bss138 works better.On the other hand, I found an thread discussing the usage of bss138 (but i lost the url), that it was not an good choice due to similar reasons as your point 1, wasting energy etc.the io buffer wing, is that using an bus switch?The first option would work and would provide a 5V output on the other end. I've usually avoided a chip like that because of cost and speed. It looks like the cost of the chip used in the first option is comparable to a 3.3V bus switch, like the one used in the buffer Wing. However, if a 5V bus switch is used and an external diode is used to set the desired max voltage then the bus switch solution is much cheaper. Speedwise the TXB0108 can only go up to 20Mbps which would work for most arduino solutions but is not very good... The I2C restriction is a big problem...The second option is a FET solution as are bus switches. I'd rather go with a bus switch which looks a lot easier to implement...Overall, I think the bus switch solution is cheaper and much faster, bus switches can operate up to 2Ghz if I recall correctly... Compared to the 20Mhz of the level converter it is no competition. The only benefit of the TXB0108 is that the output is a true 5V output. I think the majority of cases will not matter if the logic is driven by 3.3V instead of 5V since it is still compatible. Overall, my opinion is that the bus switches are a better option..Jack. Link to comment Share on other sites More sharing options...
Jack Gassett Posted October 3, 2012 Report Share Posted October 3, 2012 What would replacing the atmega103 with the, wait, 128 or 168, in the arduino core entail?It would take a couple weeks worth of effort I'm guessing. What needs to be done:As the existing code stands it needs an ICE debugger connected to external pins to program the code in. This would need to be disabled and replaced with either a data2mem solution like the one used in the AVR8 or with a bscan solution like is used to program SPI Flash by the papilio prog app. The first option would be quicker, but if I'm going to put the time into doing this I would prefer to do the second option. The benefit is that we would no longer need the closed xilinx data2mem tool, meaning we could run the Papilio-Arduino IDE under a raspberry PI if desired. The other major benefit is it would allow us to run multiple Arduino cores at once. I'm making a dual Arduino Shield MegaWing because someone might find it useful to run two arduino cores, each connected to it's own shield. The existing data2mem solution would be difficult to manage for this since the entire bit file is overwritten when new code is loaded, it would be a hassle to load two code spaces without wiping out the other. Personally, I would prefer to use a more powerful processor like the ZPUino instead of two Arduino cores, two cores just adds more complexity in my opinion. Why add more complexity, such as figuring out how to make the two cores communicate with each other, instead of just using a more powerful processor...Once the VHDL is figured out then the entire Papilio-Arduino IDE needs to be upgraded to the newest version and changed to support the new atmega128 core.The core is an atmega128 rather then an atmega168, from what I remember they are pretty much the same except for memory space...Jack. Link to comment Share on other sites More sharing options...
neslekkim Posted October 3, 2012 Report Share Posted October 3, 2012 Great overview, thanks! Link to comment Share on other sites More sharing options...
neslekkim Posted October 3, 2012 Report Share Posted October 3, 2012 Parallax have done an good job of multicore I guess?Btw, have you seen this http://cloudx.cc/ looks very interresting.. Link to comment Share on other sites More sharing options...
Jack Gassett Posted October 3, 2012 Report Share Posted October 3, 2012 To compare the price between the TXB0108 and a 5V bus switch:http://www.digikey.com/product-detail/en/TXB0108PWR/296-21527-1-ND/1305700http://www.digikey.com/product-detail/en/SN74CBT3345CPWR/296-19220-1-ND/864451The bus switch needs an external diode which is just a couple cents more. Overall the bus switch cost is about half the cost of a TXB0108, that is pretty significant when you are talking about using 3 of those chips...TXB0108 - 3 x $2.3@1 = $6.9SN74CBT - 3 x $.82@1 = $2.46TXB0108 - 3 x $.97@100 = $2.91SN74CBT - 3 x $.55@100 = $1.65Jack. Link to comment Share on other sites More sharing options...
Jack Gassett Posted October 3, 2012 Report Share Posted October 3, 2012 Parallax have done an good job of multicore I guess?Btw, have you seen this http://cloudx.cc/ looks very interresting..Yes, I've had extensive conversations with Tobias about his CloudX solution. He uses Serial SRAM in order to achieve his hyperpipelining, we talked about using serial SRAM in the Papilio Plus but I decided to go with SDRAM instead... It's a very interesting concept, he is working on his own line of hardware to take advantage of hyperpipelining. I would keep an eye on his site, he has crazy FPGA skills and I can't wait to see what he puts out.Jack. Link to comment Share on other sites More sharing options...
neslekkim Posted October 3, 2012 Report Share Posted October 3, 2012 To compare the price between the TXB0108 and a 5V bus switch:http://www.digikey.c...27-1-ND/1305700http://www.digikey.c...220-1-ND/864451The bus switch needs an external diode which is just a couple cents more. Overall the bus switch cost is about half the cost of a TXB0108, that is pretty significant when you are talking about using 3 of those chips...TXB0108 - 3 x $2.3@1 = $6.9SN74CBT - 3 x $.82@1 = $2.46TXB0108 - 3 x $.97@100 = $2.91SN74CBT - 3 x $.55@100 = $1.65ah, I was primarily asking since I had already bought those adafruit thingys, and since mouser/digikey gives me an $30 shipping penalty I'm not ordering from them that often, I need to buy lots of stuff, and then I'm getting the Norwegian customs penalty instead.. 25% tax.. Link to comment Share on other sites More sharing options...
zwabbit Posted October 3, 2012 Author Report Share Posted October 3, 2012 So I suppose I should explain what the end goal here is. Would help with the conversation we're having here, I think. My papilio is also not here yet, should be here within the next week assuming the project supervisor remembered the order them like he promised me, so I'm still working based on theory here.The idea is a staggered educational series that starts out with an Arduino and ends with people implementing their own AVR processor to stick on an FPGA board that has the necessary setup to act as an Arduino analog, so that they can use the shields and programs they wrote for the first stage and see them work. There's a side project/step that involves writing a compiler for the AVR, but I'm fortunately (in my opinion at least) not involved in trying to bootstrap that. My responsibilities right now is to see what platform is most suitable or the closest to our needs and do whatever is needed to plug in whatever holes are there. Right now the Papilio looks very enticing, since it's small, relatively cheap, and has good documentation.My own skillset has a few holes. I have experience with digital design and I've done simple processor implementations using Verilog (not VHDL, but the principles are interchangeable so that's not a major problem). My primary weakness is in the actual electrical aspects. I have people here that can help me plan out what to do based on the information the two of you have provided, though I'm likely the one that'll end up doing the board (if that ends being the best way for dealing with the voltage tolerance issue you mentioned). Construction of this voltage tolerance board could actually serve as an interesting intermediary step as well for students, albeit manufacturing hundreds of variations of the same thing might not be the most cost effective strategy. Might be a good opportunity to let them experience the joys of etching and why most people just buy printed boards. The one thing I am still a bit unsure on is the analog output/input pins and what, if anything, needs to be done to get those on the Papilio (or if they're already there and I just need to read the documentation more carefully).The other gap, one that I'm not sure I have ready access to expertise here because those of us who have done micro-controller programming or FPGA work have generally relied upon provided tools, involves the work Jack mentioned was needed even if one had a drop-in Verilog/VHDL implementation of the AVR on the arduino. Specifically, the modified tools needed to I presume load the synthesized Verilog/VHDL into the Papilio. I am also getting the impression that the compiled Arduino code is also merged into the synthesized image for loading onto the Papilio (hopefully I'm understanding you correctly there). I am curious whether it's possible to get a Papilio into a configuration where the vanilla Arduino IDE could be used to program it. This decouples the configuration of the FPGA from the loading of the Arduino sketch, but that's not necessarily a bad thing from my perspective. Link to comment Share on other sites More sharing options...
Jack Gassett Posted October 3, 2012 Report Share Posted October 3, 2012 My own skillset has a few holes. I have experience with digital design and I've done simple processor implementations using Verilog (not VHDL, but the principles are interchangeable so that's not a major problem). My primary weakness is in the actual electrical aspects. I have people here that can help me plan out what to do based on the information the two of you have provided, though I'm likely the one that'll end up doing the board (if that ends being the best way for dealing with the voltage tolerance issue you mentioned). Construction of this voltage tolerance board could actually serve as an interesting intermediary step as well for students, albeit manufacturing hundreds of variations of the same thing might not be the most cost effective strategy. Might be a good opportunity to let them experience the joys of etching and why most people just buy printed boards. The one thing I am still a bit unsure on is the analog output/input pins and what, if anything, needs to be done to get those on the Papilio (or if they're already there and I just need to read the documentation more carefully).I just uploaded the first revision of the Dual Shield MegaWing to Github so you can take a look. The PDF of the schematic can be found here.There are no voltage buffers yet, I will add those as the next step, but you can see that there are SPI ADC's to handle the analog inputs. It should be possible to add support to the arduino library so they can be interfaced in the same way that the Arduino analog pins are. Girish pointed out that it might be a good idea to only put an SPI ADC on one of the shields and let the other one be digital. I'm thinking that is a good idea and will probably be done in the next revision. One shield will have digital only I/O on the Analog pins and the other will have analog only.This MegaWing will be released under the Open Source CC-BY-SA license so you would be more then welcome to have your class build their own boards, order a batch of PCB's for the classes, or buy them from me. Whatever gives people the best opportunity to learn makes me happy. The other gap, one that I'm not sure I have ready access to expertise here because those of us who have done micro-controller programming or FPGA work have generally relied upon provided tools, involves the work Jack mentioned was needed even if one had a drop-in Verilog/VHDL implementation of the AVR on the arduino. Specifically, the modified tools needed to I presume load the synthesized Verilog/VHDL into the Papilio. I am also getting the impression that the compiled Arduino code is also merged into the synthesized image for loading onto the Papilio (hopefully I'm understanding you correctly there). I am curious whether it's possible to get a Papilio into a configuration where the vanilla Arduino IDE could be used to program it. This decouples the configuration of the FPGA from the loading of the Arduino sketch, but that's not necessarily a bad thing from my perspective.It is possible to make your own custom version of the AVR8 and load it with the Papilio modified version of the Arduino IDE without having to do any work:http://papilio.cc/index.php?n=Papilio.CustomAVR8SoftProcessorhttp://papilio.cc/index.php?n=Papilio.CustomAVR8UserCoreIt's not the best solution but it does work... I think everything you need is already in place with the exception of using the vanilla Arduino IDE. I suppose if we adopted the AtMega128 design, or modified it to look like an atmega168, and then made it so code is not merged into the bit file but is rather uploaded by the papilio-programmer we would then just need to add the papilio-programmer to the list of supported arduino programmers. I think it's doable given time and effort. So things would work for the new AVR128 design like they do for the ZPUino, you load the soft processor's bit file to the Papilio's SPI Flash and then when you want to load code you just send it over the USB's com port. Heck I guess we could even look into supporting the avrdude programmer.Jack. Link to comment Share on other sites More sharing options...
zwabbit Posted October 5, 2012 Author Report Share Posted October 5, 2012 Jack, hopefully this is the right place to bring this up, but we're seeing two broken links in the gadgetfactory store site. We're trying to order the headers along with the Papilio One 500K but the links on that page lead back to the front page. I assume that the "unassembled" header link is supposed to point here: http://store.gadgetfactory.net/index.php?main_page=product_info&cPath=7&products_id=49 but the link on the Pailio One 500K page starts out as www.gadgetfactory.net instead of just store.gadgetfactory.net. Just want to make sure we're ordering the right thing. Also, there's a link to an "assembled" header that does not seem to point to anywhere anymore. I presume that's been discontinued? Link to comment Share on other sites More sharing options...
Jack Gassett Posted October 5, 2012 Report Share Posted October 5, 2012 Oh, thank you. I corrected the links and removed the assembled header option as it was discontinued.Thanks!Jack Link to comment Share on other sites More sharing options...
zwabbit Posted October 10, 2012 Author Report Share Posted October 10, 2012 I'm thinking at some point we should probably move this to the wings subforum, but anyway.I've had a chat with the embedded devs I work with and based on that discussion this is what I'm going to attempt. As we do not need the ability to mount two arduinos together, I'll be putting together a simplified board based on your design (thank you for doing the analogy output setup already) that will sit on top of the papilio (they're supposed to have been ordered now so hopefully will be here by the end of the week) and will support sticking on one arduino shield. I'll be using the bus switch which you recommended on the previous page and have it sit between the papilio's output pins and the "arduino" output pins. One of the devs suggested I allow for pull-up resistors for all of the connections for the prototype in case a need arises. Assuming the design works as expected, I'm happy to contribute it back upstream. Any comments/suggestions would be welcome. Link to comment Share on other sites More sharing options...
hamster Posted October 10, 2012 Report Share Posted October 10, 2012 . ... then made it so code is not merged into the bit file but is rather uploaded by the papilio-programmer...I feel the better solution would be to store the code in the configuration flash but outside of the bitstream, and have the design load the code into the block RAM as part of the reset process. That way it would be completely independent of the XST toolset - still programmable using the generic papilio-programmer, but doesn't need DATA2MEM or the runtime librariesI've re-implemented Alex's bitmerge.py in C for my own use. It was pretty simple - must put it on my WIki.. - maybe it is worth adding an option on the programmer to append arbitrary binary blob to the end of the FPGA bitstream? Link to comment Share on other sites More sharing options...
Jack Gassett Posted October 10, 2012 Report Share Posted October 10, 2012 I'm thinking at some point we should probably move this to the wings subforum, but anyway.I've had a chat with the embedded devs I work with and based on that discussion this is what I'm going to attempt. As we do not need the ability to mount two arduinos together, I'll be putting together a simplified board based on your design (thank you for doing the analogy output setup already) that will sit on top of the papilio (they're supposed to have been ordered now so hopefully will be here by the end of the week) and will support sticking on one arduino shield. I'll be using the bus switch which you recommended on the previous page and have it sit between the papilio's output pins and the "arduino" output pins. One of the devs suggested I allow for pull-up resistors for all of the connections for the prototype in case a need arises. Assuming the design works as expected, I'm happy to contribute it back upstream. Any comments/suggestions would be welcome.There are pullup resistors built into the FPGA that can be configured in the ucf file...Jack. Link to comment Share on other sites More sharing options...
Jack Gassett Posted October 10, 2012 Report Share Posted October 10, 2012 I feel the better solution would be to store the code in the configuration flash but outside of the bitstream, and have the design load the code into the block RAM as part of the reset process. That way it would be completely independent of the XST toolset - still programmable using the generic papilio-programmer, but doesn't need DATA2MEM or the runtime librariesI've re-implemented Alex's bitmerge.py in C for my own use. It was pretty simple - must put it on my WIki.. - maybe it is worth adding an option on the programmer to append arbitrary binary blob to the end of the FPGA bitstream?That would be a nice addition to papilio-prog.Jack. Link to comment Share on other sites More sharing options...
zwabbit Posted October 10, 2012 Author Report Share Posted October 10, 2012 Even better. Feeling better and better about the papilio's suitability for the project. Thanks Jack.My own ability to pull this off, well..... Link to comment Share on other sites More sharing options...
alex Posted October 10, 2012 Report Share Posted October 10, 2012 maybe it is worth adding an option on the programmer to append arbitrary binary blob to the end of the FPGA bitstream?OMG, yes please!A little gotcha with that is that the fpga bitstream _may_ vary in size by small amounts between compilations. I don't know why, because I though the bitstream size is fixed but I implemented a small "gap" between the end of fpga bitstream and start of arbitrary code appended. This is implemented as a modulo operation so the fpga bitstream can grow and shrink a little (1Kb? from memory) without changing the start offset address of the appended binary. You may want to follow that same logic when you port the code. Link to comment Share on other sites More sharing options...
hamster Posted October 11, 2012 Report Share Posted October 11, 2012 @Alex, how do you think we should get the design to work out the start of the blob? A magic header at the start of the blob, or a command line parameter to indicate the starting address of the blob, and pad with zeros out to that? Something like "--blob 0x4000:binary.dat" perhaps?That way the program could throw an error should the bit file extend into the data area... Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.