FPGAExperimentor550 Posted June 29, 2013 Report Share Posted June 29, 2013 This is running ZAP 2.0.3 avr8 shifty papilio 500k on the BPC3003 V2.04 board (1) I am getting inconsistent downloads. I will change one line of code and try to re download, even though it says it has downloaded the results do not take effect. I have to switch between load to ram and load to flash for the changes to take effect...everytime. or restart the software. (2) Is it possible to stop the fpga pins from pulsing to 3.3v for 1 second on boot up? My board does this every time I power it on. No matter what code I run. (3) The avr8 says it supports port A-F but I have found through testing that all the pins are not functioning. Is there a way to make them function properly? I have found the followingPORTA WorksPORTB WorksPORTC Does not work...compiler complains that DDRC was not defined.PORTD WorksPORTE worksPORTF Does not work...compiler complains that DDRF was not defined. compiler also claims portF was not declared in the scope I need to set 8bits at once...so I figured this is the only way to do that? (4)How to set a byte of data in zpuino? I need to move a byte 8 bits to io pins at one time...actually 16bits so I would normally use two byte to port moves. I am wondering the fastest way to do this using zpuino? I tried the following and it does not work....This is running ZAP 2.0.3 zpuino vanilla 500k on the BPC3003 V2.04 boardvoid setup() {}void loop() { GPIODATA(0) = 0xFFFF; delay(1); GPIODATA(0) = 0x0000; delay(1);}it compiles and loads but nothing happens. -any help is appreciated Link to comment Share on other sites More sharing options...
hamster Posted June 29, 2013 Report Share Posted June 29, 2013 On the original AVR103 had one input-only port and one output-only port (alongside it's four bidirectional ports). All the ports on the Soft AVR8 processor are bi-directional. Because of this there are two data direction registers the need to be set appropriately. Of course these are not defined in any of AVR studio's 'C' headers files so you will need to add your own - All the I/O ports are defined the same, so you can define it with something like: #define DDRF (PORTF+(DDRA-PORTA))#define DDRC (PORTC+(DDRA-PORTA)) Link to comment Share on other sites More sharing options...
alvieboy Posted June 29, 2013 Report Share Posted June 29, 2013 In ZPUino, you need to set the GPIO pins as output first - they default to inputs at reset. But, if you want to transfer all that amount of data in a fast manner, I'd suggest writing a dedicated IO device for it. HDL is not that hard, and I can give you a hand if needed. Alvie Link to comment Share on other sites More sharing options...
FPGAExperimentor550 Posted June 30, 2013 Author Report Share Posted June 30, 2013 how do you set the zpuino pins as outputs? Link to comment Share on other sites More sharing options...
FPGAExperimentor550 Posted June 30, 2013 Author Report Share Posted June 30, 2013 I don't totally understand your define statements I tried the following and it did not work. It should blink all pins on board.//http://www.papilio.cc/index.php?n=Papilio.ArduinoCore#define DDRF (PORTF+(DDRA-PORTA))#define DDRC (PORTC+(DDRA-PORTA))void setup() { // put your setup code here, to run once: DDRA = 0xFF; //required...lower 8 bits DDRB = 0xFF; //DDRC = 0xFF; //uncomment compiler complains DDRD = 0xFF; DDRE = 0xFF; //DDRF = 0xFF; //uncomment compiler complains Serial.begin(9600);}void loop() { Serial.println("2"); // put your main code here, to run repeatedly: PORTA = PORTA | 0b11111111; PORTB = PORTB | 0b11111111; PORTC = 0b11111111; //compiler does not complain but it does not work PORTD = PORTD | 0b11111111; PORTE = 0b11111111; //PORTF = 0b11111111; uncomment compiler complains delay(1); PORTA = PORTA & 0b00000000; PORTB = PORTB & 0b00000000; PORTC = 0b00000000; PORTD = PORTD & 0b00000000; PORTE = 0b00000000; PORTF = 0b00000000; //uncomment compiler complains delay(1); } Link to comment Share on other sites More sharing options...
Jack Gassett Posted July 1, 2013 Report Share Posted July 1, 2013 This is what I have setup in pins_arduino.c:/* Data Direction Register, Port C */#define DDRC _SFR_IO8(0x14)/* Data Direction Register, Port F */#define DDRF _SFR_IO8(0x08)/* Data Register, Port F */#define PORTF _SFR_IO8(0x07)/* Input Pins, Port C */#define PINC _SFR_IO8(0x13)If you put this at the top of your sketch it should solve the problem. But I'm not sure why this is not already working, will have to dig in some more and fix it for the next release. Here is the full code:/* Data Direction Register, Port C */#define DDRC _SFR_IO8(0x14)/* Data Direction Register, Port F */#define DDRF _SFR_IO8(0x08)/* Data Register, Port F */#define PORTF _SFR_IO8(0x07)/* Input Pins, Port C */#define PINC _SFR_IO8(0x13)void setup() { // put your setup code here, to run once: DDRA = 0xFF; //required...lower 8 bits DDRB = 0xFF; //DDRC = 0xFF; //uncomment compiler complains DDRD = 0xFF; DDRE = 0xFF; //DDRF = 0xFF; //uncomment compiler complains Serial.begin(9600);}void loop() { Serial.println("2"); // put your main code here, to run repeatedly: PORTA = PORTA | 0b11111111; PORTB = PORTB | 0b11111111; PORTC = 0b11111111; //compiler does not complain but it does not work PORTD = PORTD | 0b11111111; PORTE = 0b11111111; //PORTF = 0b11111111; uncomment compiler complains delay(1); PORTA = PORTA & 0b00000000; PORTB = PORTB & 0b00000000; PORTC = 0b00000000; PORTD = PORTD & 0b00000000; PORTE = 0b00000000; PORTF = 0b00000000; //uncomment compiler complains delay(1); }Jack. Link to comment Share on other sites More sharing options...
Jack Gassett Posted July 1, 2013 Report Share Posted July 1, 2013 This is running ZAP 2.0.3 avr8 shifty papilio 500k on the BPC3003 V2.04 board (1) I am getting inconsistent downloads. I will change one line of code and try to re download, even though it says it has downloaded the results do not take effect. I have to switch between load to ram and load to flash for the changes to take effect...everytime. or restart the software. That is strange, please try to turn verbose output on under file/preferences for both compiler and uploader and see if that gives us more info. (2) Is it possible to stop the fpga pins from pulsing to 3.3v for 1 second on boot up? My board does this every time I power it on. No matter what code I run. That is the Quickstart bit file running from SPI Flash, if you succesfully write any other bit file to SPI Flash it will stop that. You should also be able to select a bit file in the file system, right click on it, and choose "Erase Papilio". (Not 100% sure that works correctly.) (3) The avr8 says it supports port A-F but I have found through testing that all the pins are not functioning. Is there a way to make them function properly? I have found the followingPORTA WorksPORTB WorksPORTC Does not work...compiler complains that DDRC was not defined.PORTD WorksPORTE worksPORTF Does not work...compiler complains that DDRF was not defined. compiler also claims portF was not declared in the scope I need to set 8bits at once...so I figured this is the only way to do that? (4)How to set a byte of data in zpuino? I need to move a byte 8 bits to io pins at one time...actually 16bits so I would normally use two byte to port moves. I am wondering the fastest way to do this using zpuino? I tried the following and it does not work....This is running ZAP 2.0.3 zpuino vanilla 500k on the BPC3003 V2.04 boardvoid setup() {}void loop() { GPIODATA(0) = 0xFFFF; delay(1); GPIODATA(0) = 0x0000; delay(1);}it compiles and loads but nothing happens. -any help is appreciated Link to comment Share on other sites More sharing options...
FPGAExperimentor550 Posted July 2, 2013 Author Report Share Posted July 2, 2013 Thanks the port defines worked...even though there are some problems I still think this is a great project and I appreciate all the effort. As far as the downloading issue goes here is what is occuring...1.open zap2.open program3.select board and com port (lets say papilio 500k shifty)4.press download.....program downloads fine5.Edit the program6.press download...board behaves as if a program has downloaded...but still runs last progrm...edits did not take effect.7.switch to papilio 500k (load to flash)8.press download....download works fine and program changes show they are working.. Due to this error I have to constantly switch between boards..just fyi it makes no difference whether is start with flash load or just fpga load. It is almost like zap only looks at the first compiled code once selecting a board...so I have to change board type after editing the program. So here are two outputs...the first one is successful the second is the program edited...but download is unsuccessful...aka previous program is loaded. First download on opening board.. cygwin warning: MS-DOS style path detected: C:\Users\Jeff\AppData\Local\Temp\build7491285760912672360.tmp Preferred POSIX equivalent is: /cygdrive/c/Users/Jeff/AppData/Local/Temp/build7491285760912672360.tmp CYGWIN environment variable option "nodosfilewarning" turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnamesExecuting C:\Users\Jeff\Documents\Lab\FPGA\Papilio\Software\zap-2.0.3\hardware\tools\avr\bin\avr-size -A C:\Users\Jeff\AppData\Local\Temp\build7491285760912672360.tmp/Test.cpp.hexBinary sketch size: 1,776 bytes (of a 16,384 byte maximum) - 10% usedmake: Entering directory `C:/Users/Jeff/AppData/Local/Temp/build7491285760912672360.tmp' Converting Intel hex file to Verilog Mem format:./srec_cat test.cpp.hex -Intel -Byte_Swap 2 -Data_Only -o tmp.mem -vmem 8./gawk ' BEGIN{FS=" ";} { $1= ""; print}' tmp.mem > out.mem Selecting Papilio One 500K Bit file. Merging Verilog Mem file with Xilinx bitstream:./data2mem -bm bitstreams/AVR8_PapilioOne_500_bd.bmm -bt bitstreams/AVR8_PapilioOne_500.bit -bd out.mem -o b out.bit#./data2mem -bm bitstreams/AVR8_PapilioOne_500_bd.bmm -bt out.bit -d > out.dmp Writing Bit file to the Hardware./papilio-prog -v -f out.bit -vJTAG chainpos: 0 Device IDCODE = 0x41c22093 Desc: XC3S500EUsing devlist.txtCreated from NCD file: top_avr_core_v8.ncd;UserID=0xFFFFFFFFTarget device: 3s500evq100Created: 2010/10/15 13:08:29Bitstream length: 2270208 bits Uploading "out.bit". Done.Programming time 467.0 msUSB transactions: Write 146 read 6 retries 0make: Leaving directory `C:/Users/Jeff/AppData/Local/Temp/build7491285760912672360.tmp' second download that does not take effect. cygwin warning: MS-DOS style path detected: C:\Users\Jeff\AppData\Local\Temp\build7491285760912672360.tmp Preferred POSIX equivalent is: /cygdrive/c/Users/Jeff/AppData/Local/Temp/build7491285760912672360.tmp CYGWIN environment variable option "nodosfilewarning" turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnamesExecuting C:\Users\Jeff\Documents\Lab\FPGA\Papilio\Software\zap-2.0.3\hardware\tools\avr\bin\avr-size -A C:\Users\Jeff\AppData\Local\Temp\build7491285760912672360.tmp/Test.cpp.hexBinary sketch size: 1,756 bytes (of a 16,384 byte maximum) - 10% usedmake: Entering directory `C:/Users/Jeff/AppData/Local/Temp/build7491285760912672360.tmp' Selecting Papilio One 500K Bit file. Merging Verilog Mem file with Xilinx bitstream:./data2mem -bm bitstreams/AVR8_PapilioOne_500_bd.bmm -bt bitstreams/AVR8_PapilioOne_500.bit -bd out.mem -o b out.bit#./data2mem -bm bitstreams/AVR8_PapilioOne_500_bd.bmm -bt out.bit -d > out.dmp Writing Bit file to the Hardware./papilio-prog -v -f out.bit -vJTAG chainpos: 0 Device IDCODE = 0x41c22093 Desc: XC3S500ECreated from NCD file: top_avr_core_v8.ncd;UserID=0xFFFFFFFFTarget device: 3s500evq100Created: 2010/10/15 13:08:29Bitstream length: 2270208 bits Uploading "out.bit". Done.Programming time 467.0 msUSB transactions: Write 146 read 6 retries 0Using devlist.txtmake: Leaving directory `C:/Users/Jeff/AppData/Local/Temp/build7491285760912672360.tmp' So the board flashes like it was loaded but it is still running the old program... if you look closely the second output is missing this part...Converting Intel hex file to Verilog Mem format:./srec_cat test.cpp.hex -Intel -Byte_Swap 2 -Data_Only -o tmp.mem -vmem 8./gawk ' BEGIN{FS=" ";} { $1= ""; print}' tmp.mem > out.mem So that could be the problem but I don't know how to fix it... As far as the pins going high at startup. I tried.. 1.Going into the papilio loader and clicking erase...result was the pins went high and stayed high the hole time, and after power cycle same thing.2.Then I loaded a program from zap and the pins still went high for a second as they did before. So basically...The pin define solution workedthe compile issue still remainsthe pins going high on startup remain... Link to comment Share on other sites More sharing options...
Jack Gassett Posted July 3, 2013 Report Share Posted July 3, 2013 For some reason the Makefile is not detecting that the hex file was updated, not sure why this stopped working. But here is a fix: Copy the attached Makefile to hardware/tools/papilio (be sure to unzip it first). I am making a new release for download too. Jack.Makefile.zip Link to comment Share on other sites More sharing options...
Jack Gassett Posted July 3, 2013 Report Share Posted July 3, 2013 Version 2.0.4 with a fix for the problem of multiple uploads not working is available now:http://forum.gadgetfactory.net/index.php?/files/file/8-zap-zpuino-arduino-papilio-ide/ Link to comment Share on other sites More sharing options...
FPGAExperimentor550 Posted July 4, 2013 Author Report Share Posted July 4, 2013 Thanks, that fixed the problem. Link to comment Share on other sites More sharing options...
OmniTechnoMancer Posted July 5, 2013 Report Share Posted July 5, 2013 By the way the pins going high on startup is an artifact of the way that the FPGA works, when it powers on it doesn't have any design programmed into it and everything is in a default state, I believe the defaults for the IO pins are inputs with pull-ups enabled, so until the design is loaded from the SPI flash the pins will remain in this state, it takes a few hundred milliseconds at startup to load the design out of the flash. If you absolutely cant deal with the pins doing this then I believe you can connect a stronger pull-down resistor to the IO's it matters for. Link to comment Share on other sites More sharing options...
Felix Posted July 5, 2013 Report Share Posted July 5, 2013 on an unrelated note, By the way the pins going high on startup is an artifact of the way that the FPGA works, when it powers on it doesn't have any design programmed into it and everything is in a default state, I believe the defaults for the IO pins are inputs with pull-ups enabled, so until the design is loaded from the SPI flash the pins will remain in this state, it takes a few hundred milliseconds at startup to load the design out of the flash. If you absolutely cant deal with the pins doing this then I believe you can connect a stronger pull-down resistor to the IO's it matters for. thanks for that. i thought i was going insane, wondering where my code went wrong Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.