I Have a simple function in FPGA ( like an adder ) but I want to this adder get the inputs from PC from ( Quartus II )
for example I want to add two 12 bit number but I haven't enough switches .
How get input from pc and send them to FPGA and How get them in FPGA ?
(I just have USB Blaster Cable )
Since you are already using the USB Blaster, you could use the in-system sources and probes feature. That will allow communication to and from the FPGA through the USB Blaster.
ISSP
Related
I am creating a Primitive Virtual Machine which is kind of inspired by LC-3 VMs but a 32-bit version. I am feeding the machine set of instructions. After executing the first instruction, how will the PC know the location of the second instruction.
Is there a particular method to store the instructions in memory in a systematic way so that PC knows the address of the next instruction
Example - All instructions are stored in a linear way as in memory[0] = instruction1, memory[1] = instruction2 etc.
Thank you for the help.
It depends on whether your Processor architecture is RISC or CISC. In the context you asked, A CISC processor has instructions whose size vary, say from 1 to 14 bytes, like for Intel processors. If it is RISC, each instruction size is fixed, say 4 byte, like for ARM processors. All the instruction of a program are stored, in sequence, in main memory. It is the processor control unit that decides how much to increment the PC. Instructions from the main memory would be read in sequence.
So say in CISC architecture, a single 8 byte read from main memory, can contain up to 8 '1 byte' instructions, e.g., repetitive 'inc ax' instruction in Intel processors. After sending the first instruction for decode, the control unit will increment PC by 1. But, at other extreme, there could be a instruction like 'add REG , [BASE+INDEX+OFFSET]' , which can take 13 bytes to store all the information (opcode + REG id + base address + index + some offset) that is there in the instruction. For such instruction, two memory read operation would be required to fetch the full instruction. After sending it for decode, the control unit will increment the PC by 13.
For RISC it is simple. Increment PC by size (2,4,...) of instructions.
Only exception is when there is branch. In that case, PC value is reset at usually the execute stage.
Instructions and data are generally grouped (segmented in some processor architecture) and stored separately. A code segment will end with some kind of return or exit instruction. If PC is set to some memory address where data is stored, the control unit of the processor will process it as instruction. After all both data and instructions are nothing but a sequence of bits! The control unit will not be able to differentiate. It is usually the role of OS or programmer (if there is no OS, like on micro-controllers) to prevent such anomaly.
hw : lpc1549 eval board with usb hid test firmware ...
endpoint size 64 bytes
endpoint intr reads out-report buf and displays len and data in hex ...
copies out_report into in_report buf and echoes back with write funct and len
host :
using qt5 , libusb-1.0.19 wingw32 dll and hidapi code
hid test code issues all your api calls (except write and read) sucessfully in linux, win7 and win8.1
test code issues hid_write followed by hid_read and get's data back properly in linux
i am not using the, by hidapi hid_write mandatory flagged Report ID, since the nxp firmware and keil software do not use it (as far as i could figure out) ...
my linux sw sends and receives a defined 64 byte pattern or smaller len) correctly and byte [0] is part of this pattern ... out and in byte [0] data is intentionally different and correct received
running the keil hid client under windows succeeds to properly communicate with the lpc1549 firmware, even they only transfer and echo one byte ...
my firmware has the endpoint size changed to 64 bytes (i hope my changes are correct) and the keil hid client works with it in windows so my assumption is that my descriptors are correct ... hopefully
host sw kububtu 14.04
hid_write len = 17, device 17 bytes received, 17 bytes indicated as received ... all seems to work properly
host sw with hidapi in win 8.1
hid_write len = 17 bytes shows up on device with 16 bytes correct and the rest is 0, but the read indicates a received len of 64 ... i issued a write of 17, received 16 correctly, but was indicated as 64 received
also win 8.1 throws a blank system32/cmd prompt window up ... why ???
the same hangs on win7 and only a hid_write len = 0 succeeds ... popping the same cmd prompt ... received len = 64, but no data transferred (as it would make sense with len = 0)
i can not single step or breakpoints since qt debugger get's segment fault upon app loading
also i link in my qt app to the hidapi "windows/hid.c" code and it is now part my code
sorry for my rather complicated description
why is a Report ID mandatory if it's not being used ... it would be a waste of one byte and if uint32_t alignment is required it would be a waste of about 7 % of the 64 bytes data
why does the keil hid client written in c++ msvs work correctly with my fw and hidapi not
would the functioning of the keil hid client indicate that my fw and my descriptors and report len are correct
What would cause an empty cmd prompt popping up?
What could i be doing wrong (a whole hidapi based app is correctly communicating with a complete usb based firmware pgm, not just the described test code)?
after a couple of days a few things got clear
the ReportID seems to be something in windows and on the host side only ... the firmware is not effected on my setup
also what was not to clear initially is that the ReportID is in addition to the max of 64 report bytes
so i create a buffer with 1 + 64 bytes = 65 ... the 1st one is zero since i do not use the ReportID mechanism and the remaining 64 are normally used
the write call data size needs to be therefore 1 + whatever the reportsize is in the usb hid descriptor endpoint side
in linux there is no ReportID on hid what i could see
next : make sure the data length specified in the write call on the host as well on the device match exactly the endpoint size definitions, otherwise no data gets across either direction and your software might hang (wait forever) on the read on the other end
i hope this might help others to get a better pict of the windows end of the hidapi hid_write calls
Alan Ott wrote me the following
http://www.signal11.us/oss/hidapi/hidapi/doxygen/html/group__API.html#gad14ea48e440cf5066df87cc6488493af
There is always a report ID. You must always send a report ID in HIDAPI, but it will not be sent to the device if the report ID is 0.
I want to drive a birectionnal logic signal through the FPGA.
PGD_ICD <--> PGD_TARGET
for those who have recognized the Microchip ICD3 you know that PGD line is bidirectional.
I've read that we can't do something like that but have you any idea ?
many thanks
Passing a bidirectional bus through an FPGA without knowing the bus protocol won't work.
While FPGA I/O pins do support tristate logic signals (floating output state), you will need to know when to drive a value onto the output, and when to tristate the output (high impedence, or 'Z').
Once you have a signal (for example out_enable) that is '1' when you want to drive a value and '0' when the output should be floating, you can use a tri-state buffer to drive the output:
out_pin <= out_signal when(out_enable='1') else 'Z';
Are all pins set to Alternate Function Mode 0 when the board powers-up?
If question 1 is true, then what function is set on header P1, pin 12? BCM2865 ARM Peripherals.pdf Table 6-31 indicates pin 12 in alt-0 mode would have a PW-M0 function. While, the Raspberry Pi Revision 2 schematics show GPIO18 coming out of IC2 is labeled GPIO_Gen1 (sheet 2 of 5) and it is directly wired to header P1 pin 12 and that pad is also labeled GPIO_Gen1 (also sheet 2 of 5). So I am confused as to which is correct.
The other possibility is that all pins default to GPIO mode when the board powers-up and to attain the special functions like, UART, I2C and SPI then each respective pin must be set to its respective alternate function mode.
Debian 2.6.30 on a glomation gesbc-9260
with an atmel arm cored chip at91sam9260 - datasheet
I want an interrupt on a GPIO pin
i need to use request_irq(interrupt number, *handler, conditions, name, id)
but god only knows what interrupt number i use ... if it were ttys0 i'd be fine...
any help would be a godsend
It depends on which GPIO you want.
The file arch/arm/mach-at91/include/mach/gpio.h lists the #defines for requesting GPIOs as IRQs.