All Activity

This stream auto-updates   

  1. Last week
  2. Jack, Thanks for getting back, but the error message is regarding a compiler errors relating to file handling, C:\DesignLab-1.0.8\libraries\modplayer\ptplay.cpp:135: error: `FILE' undeclared (first use this function)C:\DesignLab-1.0.8\libraries\modplayer\ptplay.cpp:135: error: `fp' undeclared (first use this function) C:\DesignLab-1.0.8\libraries\modplayer\ptplay.cpp:141: error: `fopen' undeclared (first use this function) C:\DesignLab-1.0.8\libraries\modplayer\ptplay.cpp:143: error: `fseek' undeclared (first use this function) C:\DesignLab-1.0.8\libraries\modplayer\ptplay.cpp:144: error: `ftell' undeclared (first use this function) C:\DesignLab-1.0.8\libraries\modplayer\ptplay.cpp:147: error: `fread' undeclared (first use this function) C:\DesignLab-1.0.8\libraries\modplayer\ptplay.cpp:148: error: `fclose' undeclared (first use this function) Error compiling. Do you really think this could be related to a memory issue ? BTW it give the same error on the non-hyperion ZPUINO, Regards, Tony
  3. Not everything will fit into the Hyperion version of ZPUino. Hyperion sacrifices some memory that was available for program space for video memory. The Papilio One does not have any external memory so it is very memory constrained compared to the Papilio Pro. Then Hyperion makes it even more so... I would recommend trying the regular version of ZPUino for the Papilio One and see if it works. If not then the Papilio One does not have enough memory for the example you are trying to synthesize. Jack
  4. I get the following error message when compiling for the papilio one 500, in designlab 1.08 (and 1.07) it works correctly for the papilio pro. Any one has any ideas ? Arduino: 1.0.8 (Windows 7), Board: "Papilio One (500K) - ZPUino Hyperion" Build options changed, rebuilding all Found smallfs directory C:\DesignLab-1.0.8/hardware/tools/zpu/bin/mksmallfs C:\Users\Tony\AppData\Local\Temp\build9072019199683906941.tmp/smallfs.dat C:\Users\Tony\Documents\DesignLab\Tony_LogicStart/smallfs SmallFS: Packed 1 files sucessfully!!! C:\DesignLab-1.0.8\hardware\zpuino\zpu20\libraries\SPI\SPI.cpp:116: warning: unused parameter 'bitOrder' C:\DesignLab-1.0.8\libraries\SD\SD.cpp:320: warning: unused parameter 'object' C:\DesignLab-1.0.8\libraries\SD\SD.cpp:312: warning: unused parameter 'object' C:\DesignLab-1.0.8\libraries\SD\SD.cpp:234: warning: unused parameter 'isLastComponent' C:\DesignLab-1.0.8\libraries\SD\SD.cpp:234: warning: unused parameter 'object' C:\DesignLab-1.0.8\libraries\SD\SD.cpp: In member function `bool SDClass::begin(uint8_t, uint8_t)': C:\DesignLab-1.0.8\libraries\SD\SD.cpp:362: warning: control reaches end of non-void function C:\DesignLab-1.0.8\libraries\SD\utility\Sd2Card.cpp:763: warning: unused parameter 'blockNumber' C:\DesignLab-1.0.8\libraries\SD\utility\Sd2Card.cpp:763: warning: unused parameter 'eraseCount' C:\DesignLab-1.0.8\libraries\SD\utility\Sd2Card.cpp:713: warning: unused parameter 'token' C:\DesignLab-1.0.8\libraries\SD\utility\Sd2Card.cpp:713: warning: unused parameter 'src' C:\DesignLab-1.0.8\libraries\SD\utility\Sd2Card.cpp:698: warning: unused parameter 'src' C:\DesignLab-1.0.8\libraries\SD\utility\Sd2Card.cpp:659: warning: unused parameter 'blockNumber' C:\DesignLab-1.0.8\libraries\SD\utility\Sd2Card.cpp:659: warning: unused parameter 'src' C:\DesignLab-1.0.8\libraries\SD\utility\Sd2Card.cpp:582: warning: unused parameter 'sckRateID' C:\DesignLab-1.0.8\libraries\SD\utility\SdFile.cpp:1291: warning: unused parameter 'str' C:\DesignLab-1.0.8\libraries\SD\utility\SdFile.cpp:1276: warning: unused parameter 'b' C:\DesignLab-1.0.8\libraries\SD\utility\SdFile.cpp:1174: warning: unused parameter 'buf' C:\DesignLab-1.0.8\libraries\SD\utility\SdFile.cpp:1174: warning: unused parameter 'nbyte' C:\DesignLab-1.0.8\libraries\SD\utility\SdFile.cpp:667: warning: unused parameter 'v' C:\DesignLab-1.0.8\libraries\SD\utility\SdFile.cpp:653: warning: unused parameter 'fatTime' C:\DesignLab-1.0.8\libraries\SD\utility\SdFile.cpp:637: warning: unused parameter 'fatDate' C:\DesignLab-1.0.8\libraries\SD\utility\SdFile.cpp:608: warning: unused parameter 'dir' C:\DesignLab-1.0.8\libraries\SD\utility\SdFile.cpp:608: warning: unused parameter 'width' C:\DesignLab-1.0.8\libraries\SD\utility\SdFile.cpp:210: warning: unused parameter 'flags' C:\DesignLab-1.0.8\libraries\SD\utility\SdFile.cpp:210: warning: unused parameter 'indent' C:\DesignLab-1.0.8\libraries\modplayer\ptplay.cpp: In function `pt_mod_s* pt_load(char*, int)': C:\DesignLab-1.0.8\libraries\modplayer\ptplay.cpp:135: error: `FILE' undeclared (first use this function) C:\DesignLab-1.0.8\libraries\modplayer\ptplay.cpp:135: error: (Each undeclared identifier is reported only once for each function it appears in.) C:\DesignLab-1.0.8\libraries\modplayer\ptplay.cpp:135: error: `fp' undeclared (first use this function) C:\DesignLab-1.0.8\libraries\modplayer\ptplay.cpp:141: error: `fopen' undeclared (first use this function) C:\DesignLab-1.0.8\libraries\modplayer\ptplay.cpp:143: error: `fseek' undeclared (first use this function) C:\DesignLab-1.0.8\libraries\modplayer\ptplay.cpp:144: error: `ftell' undeclared (first use this function) C:\DesignLab-1.0.8\libraries\modplayer\ptplay.cpp:147: error: `fread' undeclared (first use this function) C:\DesignLab-1.0.8\libraries\modplayer\ptplay.cpp:148: error: `fclose' undeclared (first use this function) Error compiling. Regards Tony Smith
  5. actually, if its a sensor, shouldnt you just be able to set the chip to receive mode and not even bother with writing to it other than once (or just pull the pin LOW) then just listen to the receive in a loop?
  6. SP485 and SP3485 are 2 different voltage chips. the 3485 is the 3v3 model where as the 485 is the 5V0 model.. the SP3485 // SP485 don't have automatic flow control, you are most likely just missing your data. how to fix, no idea. maybe try (note: i have never used that chip nor modbus) and ofc listen to @alvieboy since he is 100000 times smarter than me. int response_length; int req_length int rww; int fauxWDT=0; .. .. // yadda yadda // .. write(fd,"1",1); // make gpio(enable pin) high. req_length = modbus_send_raw_request(ctx, raw_req, 6 * sizeof(uint8_t)); //write usleep(50); // or just remove entirely write(fd,"0",1);//After write(), make gpio low to receive messages from sensor. rww = 1; while (rww == 1) { response_length = modbus_receive_confirmation(ctx, rsp); if (response_length == -1) { rww = 0; } /* maybe add some sort of timeout counter here.. fauxWDT++; if (fauxWDT >= 10000) { rww = 0; } */ } /* do something with rsp here */
  7. Earlier
  8. GF does not support Zynq at the moment, nor Linux interfacing. But my 2 cents: 1 - flush the write to the GPIO control port. 2 - If you really need control over all lines, write a Linux Kernel Driver for it. Also check documentation for that "modbus" library you are using. Alvie
  9. I am testing infrared temperature sensor. It is connected to SP485(converter RS485 to RS232?) which is connected to ZYNQ,FPGA. write(fd,"1",1); // make gpio(enable pin) high. req_length = modbus_send_raw_request(ctx, raw_req, 6 * sizeof(uint8_t)); //write write(fd,"0",1);//After write(), make gpio low to receive messages from sensor. int response_length = modbus_receive_confirmation(ctx, rsp); This code was not working properly. Write() is not write immediately.. or the prosess is working independently.(so there is possibility that when I input Low, write() is not finished). I don't know reason actually. it's just my assuming. So I added usleep(); write(fd,"1",1); // make gpio(enable pin) high. req_length = modbus_send_raw_request(ctx, raw_req, 6 * sizeof(uint8_t)); //write usleep(9050); //waite until write is finished write(fd,"0",1);//After write(), make gpio low to receive messages from sensor. int response_length = modbus_receive_confirmation(ctx, rsp);` this code is working sometimes..... it also not the best answer. the result is here. After 1'22, it's working. enable Pin is connected to FPGA (ZYNQ) It is difficult to add other circuit to control enable pin. it is more convenience to make a design on the FPGA. should I control this by software?(controlling gpio) or Hardware? Let me know the best way, approach.. Thank you.
  10. This looks really cool, I can't wait until I get some time to dig into this and check it out some more. Jack
  11. The reset behavior is automatically generated by the tools; you can choose from a predefined list of behaviors (sync (default), async, at boot (FPGA)) for each clock domain, but currently only synchronous is implemented. Any issues of guaranteeing proper timing of the async reset signals would be outside of the scope of the auto-generated RTL, so you would have to take care of that manually.
  12. Thanks for your reply, Luís. Yes, I am from Coimbra, but don't go to Lisbon that often (except to fly abroad, and that's more often that I'd wished). Still one question: how do you model sync vs. async resets ? Rather easy in low-level HDL languages, but hard to do even in SystemC (I heard newer versions do support it, but it's an ugly hack in my opinion). Alvie
  13. - The circuits have an implicit clock, but you can specify your own input clock ports and assign those clocks to sub-circuits. Synchronization between those clocks domains is done manually; - You can integrate external Verilog / VHDL modules, so if your hard-IP blocks can be instantiated from Verilog / VHDL then you just instantiate one of those; - At its most basic, you manually instantiate the stages and registers that connect the various stages, just like in Verilog / VHDL. It should be possible to create higher-level abstractions based on that, but I haven't explored that yet. If you mean how do you use the times ("*") operator and automatically get a multi-cycle multiplier, you can't do that, not at the moment, you'll have to manually create a multiplier. Of course, you can design a generic/parameterised multiplier once and be done with that. You get more flexibility for creating generic components than with Verilog / VHDL, whose introspection abilities are a bit limited. You're from Coimbra? Yeah, we can meet there some time, or whenever you come to Lisbon :-)
  14. It may be possible with an USB3300 transceiver. I have a couple, but unfortunately had no time to put those to work. I may need to in a recent future, I'll let you know. Alvie
  15. I read one of your PDF files, and to be honest I have much more questions now than I had before, like: - How do you model different clock domains ? - How do you integrate with hard-IP blocks ? - How do you model multi-cycle operations, like a 5-pipeline multiplier ? If you happen to come by Coimbra you may explain me these in more detail Alvie
  16. Hello, I've just returned from DConf 2017, in Berlin. There I gave a talk on how to use an extension of the D programming language (DHDL) to design hardware. I showed a demo of Classic Empire, a game written by Walter Bright (the original creator of D), running on a Papilio Pro, inside a soft-core RISC-V CPU, plus my own handmade "wing" IO accessories and respective controller IP blocks (VGA, 7-segment, sound, etc.). You can see a quick demo below: You can also see the full talk, if it sparks your interest: Thanks to the generosity of GadgetFactory, we raffled a Papilio Pro and some accessories to the participants of the talk: Gauging from his reaction, Vang Le was very surprised and happy to be the winner, and he's looking forward to exploring the world of FPGAs. In my demo I loaded the binary code for the game through the USB/UART, using a custom utility. In the next few months I plan to further tweak this demo, so that the game code is loaded from flash and it works with standard GadgetFactory wings. When that is done, I'll provide the bit stream files for the combined hardware design + the game. Walter Bright has indicated that he would provide permission for the FPGA version of the game to be distributed freely, so GadgetFactory could use it for its showcase. Later, I will provide the source code for my whole setup; I used the LDC 2 D compiler with the (old) LLVM RISC-V backend, and I had to workaround a lot of bugs of invalid RISC-V code. When the new LLVM RISC-V backend is released I expect all of that to be alleviated or completely fixed, which will help with the release of the complete demo setup. I'll keep providing updates and feedback here on the GadgetFactory forums. You can also follow me on Twitter (@Luis3m), or email me if you have any questions (http://www.luismarques.eu/about). Also, a shout-out goes to Mike Field, whose book / tutorial helped me get started with FPGAs and hardware design. I shared the love for his book with some conference participants :-) So long, Luís
  17. Thanks for sharing. I still have to ship your stuff, will do so during this week. Also quite busy over here, but definitely have no connectivity issues I will try your design later, but more interested in the HDL design than in the demo. There's been quite some hype around RISC-V, but to be honest I believe it won't live longer - there are some issues with ISA, and some extensions may not play well with others. Also, MIPS is for sale AFAIK, if they drop the patents it may well be a more serious contender to ARM (I think at least Cavium may have some interest in buying MIPS from Imagination - and Imagination is eager to sell everything due to recent contract changes with Apple) Alvie
  18. it's probably better just to stream it using a serial port at 3Mbit/s. The audio DAC relies on the speaker themselves (their inductance) to perform a low-pass filter, in both Sigma-Delta and PWM outputs. What you hear is probably switching noise and some aliasing. Alternative is for you to design such an analogue filter. It can be technically possible to send that data over USB using a simple transceiver and isochronous transfers, but we have not done it before. Alvie
  19. Hi Felix and Jack. Many-many thanks for your replies, you gave a lot of info. Yes, I had the idea to use an ESP8266 but in the past I've used some just with serial interface (ESP-01) and in such case you get a very low throughoutput. I know the ESP8266 could be interfaced directly through it's SPI, but it seems to be poorly documented. Furthermore, such developement could stole too much time from the whole project... About saving to SD: i need to process the data on the fly: my system will sniff the data on the LCD bus and send it to a PC, where the images directed to the LCD are checked to control if the circuit/uP driving the LCD is doing a good job... The test will run for hours and may also change if something is not going ok, so I cannot get all the data later... Do you think getting out data with an ethernet module could be a feasible solution? I'm thinking at the http://store.gadgetfactory.net/ethernet-module/ based on the Microchip ENC28J60, or some similar module... Would it have enough bandwith to get out 230kbytes x 10fps (it's about 23 Mbit/s)? I'm reading that the ENC28J60 could get data at 20Mhz SPI clock, so it's surely not fast enough to receive a 23Mbit/s stream, but it could perhaps work with half such framerate, let's say at 5 frames per second. What do you think? I dont' want to abuse of your time, so just one more questions and I'll free you...; in the case one should find a praticable interface to get out the data (ethernet or else), what IDE should we use to develop into the FPGA the firmware for such task, is it Papilo Designlab IDE? Many thanks again, and kind regards, VALERIO
  20. Hey All, I'm trying to record audio from classic computing shield (which I think is basically the same as the arcade shield) but just getting terrible noise. The sound works fine when plugged into powered speakers, but plugging to sound card on my pc and recording/monitoring just gives buzzing/hissing noise. I've tried both mic in and line in on the sound card, same result. I'm guessing this is because of the way this kind of dac works, but wondering if there's some other reason. Has anyone else managed to get a clean recording into a PC from one of these shields? What am I missing? Brad
  21. Thanks Alvie... I've got something working well enough for now but I think I'll need to revisit it - sometime manual reset through the classic shield reset button doesn't work quite right. I guess because of the multiple clock domains. Brad
  22. Hello, The USB channel on the Papilio is a max of 3Mb/s so it will probably not be fast enough for what you are wanting to do. Alvie has created a USB wing that is a PHY and a USB core for the FPGA but it is just USB 1.1 I think so probably not fast enough. If we can get a USB 2.0 USB PHY wing then that would open up a lot more possibilities for projects like this one... Jack.
  23. disclaimer - i only play games with the fpga.. i dont do any vhdl/verilog... most of my hardware work i do with microchip PIC or arduino.. regardless, the amount of data you are talking about you would probably need to write the data to an SD card and read it out again later for post processing. assuming you could run the fpga fast enough to capture the data. the papilio usb interface is an FTDI chip so you would need to output that serially. (which wont work.. its too slow for 10 images/sec.. even @ max speed) that is to say, 10 images/second is a lot of data .. you wont be able to transfer that over serial port of the papilio. you could probably use the esp wifi wing that ?alvie? designed and send out the data that way if it was me, personally i would try using a vhdl/verilog implementation of a 74hc165 shift register with D0-D7 tapping the 8 bit bus and whatever pin the lcd uses as input from the mcu to say data is there, display it (RS i assume) either straight or inverted logic, to the clock pin on the shift register so you know when the bits are set and you can read them. you will need to use resistors and pull ups since iirc the papilio is LVTTL write data to SD card or sent out via wifi, and process later. pretty sure Zpuino can do it but not sure if it can do it fast enough. @alvieboy would be the one to ask about zpuino and esp8266 i dont know enough about the lcd protocol used to decode the data but i would guess it wouldnt be that hard to find online. if i may ask, what are you trying to capture data from ? @ anyone - feel free to correct me if anything seems off. i am honestly not sure if the fpga can read the bits fast enough or if the SD interface is fast enough to write the bits/bytes to the card.
  24. Hi. First of all, great compliments for all of your work; the Papilio seems a very powerful signal processing/interfacing hardware with a good software support (libraries, etc). My newby question is just to analyse if the Papilio could be used for a particular application we are going to implement. We need an hardware to sniff and decode signals going to an LCD, in order to get into a PC the images being represented on the LCD. We will use two types of LCDs; the first one has a standard 6800/8080 bus (8bits + handshaking), the second has a 3x6bit bus (RGB, each 6 bits) + horizontal, vertical and pixel clocks. So we can get all signals within a 32 bit input in both cases. We cannot understand if we could do the application inside the FPGA of the Papilio, having then enough bandwidth to send out the results (the images) through the USB channel to the host PC. The worst case is getting images from the bus of a 320x240 colour LCD, so each image is done of 320x240x3 = 230kbytes. We could not store it into the local memory, do you think it could be possible to put out the data on the fly through the USB port, let's say at about 10 images/s? What IDE should we use to develop into the FPGA the firmware for such task, is it Papilo Designlab IDE? Many thanks and kind regards, VALERIO
  25. Hi all, sorry for the long delay since my last post. I was distracted by a few other things, in addition it took the German Telekom two weeks to get the upgrade of my internet connection to VDSL working. Finally I have now 50/10Mbit instead of 3/0.5Mbit , so it was worth the trouble. Attached to this post is a Bitstream with the working Bonfire SoC for the Papilio Pro. It boots into a monitor program, which allows some basic operation of the board. Connection speed is 500000 Baud per default. If this is a problem, I can also provide bitstreams with other default baud rates. It should print a message like this: Bonfire Boot Monitor 0.2d MIMPID: 0001000e MISA: 40001100 UART Divisor: 11 UART Revision 00000012 Uptime 0 sec SPI Flash JEDEC ID: 001720c2 The monitor supports the following commands: D <address>: dump memory, it will always dump 64 32Bit words, starting per default with address 1000000. Without entering a address the dump command will automatically dump the next 64 words X <load adr> <max size in hex>: Download a file with xmodem-crc protocol and load to <load adr>. Default load address is 100000. When no size is specified it will load the whole file in case it fits into the DRAM. Normally it is sufficent to just enter x without arguments. It has been tested to work with minicom under Linux G <address> jumps to <address> (default is again hex 1000000 when ommited, can be used to start a program downloaded with the X command E print xmodem error status. Shows the status of the last xmodem download. T test DRAM. Makes a simple (destructive) pattern test of the DRAM. When running the bitstream the first time it is best to use this command to check that everything is fine. B change baudrate. The user will be prompted for a the new baudrate. Every value between 300 and 500000 is allowed, no check further check is done, so it is possible to enter baudrates like 2423 :-) I re-display the boot message with some system info W: Write boot image. Writes the image downloaded with the X command to the flash ROM. It will write a 4KB header to flash offset 512KB, and then the image data directly behind it. The command can only be executed directly after a X command, because it will take the size of the downloaded file to determine the size of the image. In addition the X command that the heap "sbrk" address to the first free address after the downloaded code, this address is also written to the flash header. R: run boot image. Will run an image written with the W command. The second attachment is a compiled binary of my eLua (http://www.eluaproject.net/) implementation for RISC-V (source is on https://github.com/ThomasHornschuh/elua). To run it, download it with the X command into RAM and start with G (both commands works with their default parameter). To permanently add it to flash do the following Reset the Papilio Pro with the reset button (or reload the bistream, in case you don't like to program the bitstream to flash Download with the X command Write to Flash with the W command From now on you can start eLua after boot just with "R" command >r Reading Header ...OK Boot Image found, length 339968 Bytes, Break Address: 00063b00 ...OK Heap: 00062eb0 .. 007ef7ff eLua for Bonfire SoC 1.0a __virt_timer_period 1920000 eLua v0.9_bonfire_RV32IM-7-g7996f83 Copyright (C) 2007-2013 www.eluaproject.net eLua# You can enter help to get a command help... Tipp: From the eLua# promt run: lua /rom/life.lua for a demo of the game of live in Lua. It runs 50 iterations and prints then the runtime: ---------O---------------O------ ----------O--------------------- -----OO---------O-O------------- ----OO---------OO-OO------------ ---OO--O-OO-OOO---O-O----O------ --OO--OO-O---O------O---O-O----- ---O---OOO---O-----O----O-O----- ----OOO------O-O---------O------ -----OOO----OO-OO--------------- ------------O-O--------------OO- -------OO-------------------O--O ---------OO------------------OO- --------O--O-------------------- ---------O-O-------------O------ ----------O-------------O-O----- ------------------------O-O----- Life - generation 50, mem 22.8 kB Execution time 16.903 sec (16903.39) ms eLua# Enjoy and please give me feedback if you like it. Regards Thomas monitor.bit elua_lua_bonfire_papilio_pro.bin
  26. Thank you for the understanding and I'm sorry we don't have a better answer. The material in the old ebook is still valid with the Papilio DUO, so it is still a great read... Jack.
  27. Thanks for the answer, it isn't about the money (didn't ask for a refund/store credit for the broken plexi case either).. just would like to get some hands on experience.. and the ebook combination seemed to be a nice combo.. Guess I will try to pick up another book.. if anyone has any recommendations..
  28. Load more activity