I have a relatively simple circuit that I'm trying to compile. It requires 491 I/O pins, so I'm selecting a non-default device that has more than 456 (Cyclone IV GX with 508 user I/Os). The problem is that when compiling I receive this error:
Error: Can't place 489 pins with 1.2 V I/O standard because Fitter has
only 380 such free pins available for general purpose I/O placement
I'm not sure what this 380 free pins mean, I'm sure that the I/O pins should be enough, I can see it in the report:
Total Pins 491 / 508 ( 97 % )
I think that is probably because it's talking about some other type of pin I'm not aware of (I'm just starting with electronics and VHDL).
Not all pins on a given FPGA can support every I/O standard. That error message indicates that there are only 380 pins that support 1.2V I/O pins. You will need to assign some of your pins to a standard that is compatible with the other pins. The device documentation or Quartus should have documentation on which pins support what I/O standards.
Related
I'm currently trying to burn the pinguino bootloader in a pic32mx250f128b which is 5V tolerant with an arduino uno. I'd want to try pic32 chips, but I haven't a pickit3 now, I can only access to pickit2.
So to burn the bootloader I'm using an arduino uno, and use the bitbang sketch from pic32prog to try to burn it.
For the wiring I did this :
All VDD and the VUSB3V3BUS pins are wired to the 3V3 regulator of the arduino uno.
All VSS pins are connected to the ground of the arduino uno.
Arduino D2 (PGC) is directly connected to PGEC1
Arduino D3 (PGD) is directly connected to PGED1
Arduino D4 (MCLR) is directly connected to MCLR
But actually, when I launch pic32prog I always have this output :
Programmer for Microchip PIC32 microcontrollers, Version 2.0.218
Copyright: (C) 2011-2015 Serge Vakulenko
(ascii ICSP coded by Robert Rozee)
Adapter: ... OK1 OK2 - ascii ICSP v1E
No target found.
I tried also with the couples PGEC2/PGED2 and PGEC3/PGED3.
I haven't tried to use a crystal yet, but I think from what I read it's not needed for ICSP programming.
For now here is what I've done on my breadboard :
photo of the pic on the breadboard
I don't know what could cause this detection problem,
Thank you very much for your help :)
Edit : I tried several things and here is where I am :
I added the pull-up on MCLR, capacitors on VDD pins, and others recommended : Still the error No target found.
I saw that pic32prog add compatibility with pickit2 so I tried it : this time the pic is detected but I get this error : Unknown CPUID : ffffffff. I tried also with a new pic32mx250 on the pickit2 to be sure it wasn't the first which was damaged.
Finally to recheck my connections I found another version of the datasheet. In this one it seems that PGECx and PGEDx pins aren't 5V compatible... -> So I'll test with 3.3v compatible circuit this time
you need 3k3 pullups to the 3v3 supply rail on both PGC and PGD. these two outputs are 'open collector' (simulated) and the 3k3 resistors define the logic '1' voltage fed to the PGC and PGD pins of the target PIC32.
as mentioned by others, you also need a 10k pullup on MCLR. in addition, you need to ensure that all Vcc pins (13 and 28) are connected together, all ground pins (8, 19 and 27) are connected together, and that there is a 10uF low ESR ceramic capacitor from pin 20 to ground (a 22uF tantalum will do).
see the "ascii ICSP construction guide" article here:
http://www.thebackshed.com/docregister/Browse.asp
the article includes a schematic of what is required.
cheers,
rob :-)
the 10uF low ESR ceramic capacitor on pin 20 is crucial. pin 20 connects ONLY to this capacitor, nothing else. without it, the core of the PIC32 will not run and programming will be impossible.
the reason for this is that the core of the PIC32 runs at 1.8 volts, and the capacitor on pin 20 is part of the circuitry that generates this supply. in your photo it looks like pin 20 is not connected to anything.
cheers,
rob :-)
I am working on linux kernel 4.8 and have configured ttyS2 to act as HSUART as shown in the dmesg log:
[2.599632] dw-apb-uart.9: ttyS2 at MMIO 0x9232e000 (irq = 5, base_baud = 115200) is a 16550A
I am able to communicate through ttyS2 successfully till 921800 baud rate with software flow control, but for higher baud rates i.e 3M/4M there is FIFO overrun at the receiver side. The FIFO_SIZE is 16 bytes and I have tried configuring RECEIVER_FIFO_THRESHOLD to 8 and 14 bytes but still the issue persists. However there is no issue seen if I use Hardware Flow Control (CTS & RTS)
Any inputs on the maximum baud rate that can be used with software flow control for successful serial communication would definitely be of help! Thanks in advance!
I am posting this question after not getting any sort of help across the web and reading many articles and tutorials. I ended up asking questions with hope of getting guided.
DESPERATE FOR HELP.
What i want:
1) I want to build a R/C tank.
2) Basically its not controlled by a remote control but i want control by a laptop.(i could write a c++ or c# program).
What i know:
1) I know how to develop a development board. (i want to develop my own, not use arduino)
2) I know c++ and assembly very well.
3) I know about AVR's ALU, Memories(all 3), Stack, Interrupts, IO Operations well.
4) I know theory about how SPI, RS232, UART works.
PROBLEMS: (I have many questions, but most important are)
1) B/c i have made my own board. How can i transfer my program(hex file) to my board(i seek practical and physical implementation, not theory please)(i know about a 6-pin ISP but not clear about practical implementation)
2) After it, how can i make wireless communication b/w my AVR and laptop.(hardware device?)(SPI, RS232, UART?)
MAIN CONFUSION:
1) I cannot help myself differentiating or relating SPI, RS232 and UART.
I know these are used for serial communication between devices but how?(which is used when and why and how)(appropriate hardware for transmitting device and receiving device)
THING TO KNOW:
1) I haven't started making my board and programming it because i think i should learn everything first and then do it in a one go. OR should i start practical work and things get easier automatically??
2) I learnt a tutorial series on Serial Communication from http://maxembedded.com/2013/09/serial-communication-introduction/ the starting 5 topics leaving the last one(I2C). Am i missing something there?
I hope everything is clear, and waiting for a good-men's words.
Note: I am already very misguided and lost, so i want experienced and expert's guidance. Many Many Many Many Thanks in Advance.
MY BOARD LOOKS LIKE:
http://www.robotplatform.com/howto/dev_board/schematic_l/38.jpg
1) To upload your code into AVR chip, you can use ISP interface. That requires you to connect at least 5 pins: SCK, MISO, MOSI, RESET, GND, and optionally VCC (it used to control or supply voltage, but not mandatory, if your board has it's own power supply). All you need is just to wire 6- or 10-pin ISP connector to that pins of your CPU.
To begin programming process you need to obtain some programmer device (USBasp, AVRISPmk2, STK500/600 etc.), Also, you can use Arduino board itself as ISP-programmer for external AVR chip, like this: http://www.instructables.com/id/Programming-an-ATTiny13A-using-Arduino-servo-int/
Each of programmer model requires it's compatible software (such as PonyProg), for example STK500 and AVRISP programmes could be used directly from Atmel Studio.
Also, you can connect ISP to parallel (LPT) port of the PC, and upload firmware using specialized software, such as uniprof
Another way to upload software - it is to make your own bootloader - a tiny program that will update firmware, using any available interface.
2) USART, SPI, I2C - it is different interfaces to communicate with peripherals. Note that RS232 - it is electrical interface built over USART. I.e. you need external IC which will convert USART logical level signals to RS232 electrical levels.
each of that interfaces have it's own profs and cons. And usually selection of which interface to use depends on which interface is supported by peripherals.
SPI - it is interface for high-speed communication. One master many slaves. It requires a lot of wires: MISO (data from master to slave), MOSI (data from slave to master), SCK (clock) - those three could be common for all slaves. Also it requires a SS (slave select) - one SS wire for each slave to determine which slave is in communication at the moment, also it sets the edges of the data packet.
USART - it is common interface, to communicate two chips. Each byte transmitted with foregoing start bit, optional parity and following stop bit. I.e. transfer has a quarter overhead, but byte can be transmitted in any moment.
Works in synchronous and asynchronous modes. Asynchronous mode requires only 2 wires (RX and TX, not counting GND that also required). This mode requires that receiver and transmitter to be sychronized, in most cases that required to crystal oscillator to be installed.
Synchronous mode works in the same format as asynchronous, but have additional XCK (clock) wire, that determines in which moments bits are possible to be transmitted. This allows to increase transmission speed and not requires time precision from receiver. Synchronous mode is rare used.
I2C - it's a bus with only two wires, allows many masters and many slaves. Utilizes pull-up resistors to achieve wired AND, have it's own algorithm to detect collisions, more complicated to be programmed, transmission speed is limited.
Often used by peripherals, such as accelerometers, RTCs etc.
AVR chips have no it's own support for wireless communication, therefore, to do that you need to use some external wireless chip, for example bluetooth, or WiFi, there are a lot of such modules (for example ESP8266). AVR chip communicate with them using USART, sending and receiving simple commands.
i am using arduino isp to program a ATtiny2313 avr microcontroller.
Here is the probelm,
when i was programming the avr chip using the default fuse values, everything worked just fine.
But then, i changed the fuse bytes as i wanted to use an external 16 MHz crystal.
When i changed the lfuse value from 0x64 to 0xff (as per the calculation of the fuse bits), the microcontroller stopped responding.
Now everytime i try to program the microcontroller using arduino uno isp, i get an error message :
avrdude: Yikes! Invalid device signature.
avrdude: Expected signature for ATtiny2313 is 1E 91 0A
and then the fuse bytes shown after verification, very strangely are all set to 0x00 :
avrdude: safemode: Fuses OK (H:00, E:00, L:00)
i dont understand what the hell is happening and i have spent hours trying to figure out the probelm.
should the 16Mhz crystal be connected to the microcontroller while programming ?
PLEASE HELP !
Yes. When you change the configuration bits to use the external oscillator, the internal oscillator is no longer utilised - including during programming. The chip is just stuck in reset until it is provided with an external clock signal. When the ISP attempts to read out a value it is just seeing the data line stuck in the reset state - which is where all the 0x00 values are coming from.
Hook up the crystal or a signal generator to the CLOCKIN pin and you should be able to talk to the chip again.
Had the same issue. If you do not have an external oscillator, you can use
Arduino ISP
On PIN9 you get an osciallator signal you can put on the target on PIN XTAL1.
Saved me two 328p.
Can SPI hardware on the Arduino Nano be used?
On the Nano page it says:
SPI: 10 (SS), 11 (MOSI), 12 (MISO), 13 (SCK). These pins support SPI
communication, which, although provided by the underlying hardware, is
not currently included in the Arduino language.
Yet there is an SPI library.
Please can someone explain this contradiction? I think, either
The nano page is out of date
SPI library is unsupported for the Nano SPI hardware but is supported on other boards
SPI library is implemented for the Nano in software only
Which is it?
Thanks
The correct answer is "some combination of the above":
Arduino Nano is based on the ATmega168/328 chip, which does support SPI in hardware.
The SPI library only supports hardware SPI (regardless of the Arduino model). Note that you could bitbang (relatively) slow SPI without any problems, this would be a relatively easy software implementation.
The status of SPI library should be considered same as the status of the Wire library: not part of core Arduino services (in contrast to PWM, ADC, and digital GPIO), but widely supported nonetheless.
So perhaps the closest answer in your multiple-choice question is "out of date". The status of SPI should look the same as the status of I2C.
This should be a comment but I haven't the rep.
As angelatlarge said, the SPI library is as supported for the Nano as it is for any of the other Arduinos. Except:
The Nano (like all Arduinos) has an LED attached to digital pin 13. Since, for the Nano, pin 13 is also SCLK for SPI, you may well run into trouble with high baud rates. If this is a problem for you, try removing the LED.
From the Nano's page: Source
...
SPI: 10 (SS), 11 (MOSI), 12 (MISO), 13 (SCK). These pins support SPI communication, which, although provided by the underlying hardware, is not currently included in the Arduino language.
LED: 13. There is a built-in LED connected to digital pin 13. When the pin is HIGH value, the LED is on, when the pin is LOW, it's off.
The Nano's product page is out of date, but it has the same hardware and software SPI support as the other ATmega168/ATmega328p-based Arduinos.
Some archaeology in the wayback machine reveals that the functionally comparable Duemilanove's product page was changed from a hardware-but-not-software mention to a mention of SPI library support between September 15th and 26th of 2010. When the Uno came out, its product page was based on the then-current state of the Duemilanvoe's, so it has always claimed support.
A corresponding update should have been made to the Nano page, but this appears to have been overlooked.