I was thinking since clock timing is provided by master microcontroller to rtc/sensor etc.We can use any crystal (including internal) on microcontroller and there will be no timing problem.
is this true?
If you don't need precise timings, you can use internal RC oscillator.
Note, there is no 'internal crystal', it is only R-C circuit like this.
I don't know any MCUs with integrated quartz crystal, there is only some RTC ICs (like Maxim DS3231) feature.
If you use SPI or I2C (TWI), bus timings may have any values, and you may use simple internal RC-circuit.
If your device use UART or will measure any timeouts, you should examine oscillator parameters of your MCU. Which oscillator should be used, depends on required accuracy, parameters, provided by MCU, and some other options (like device working temperatures).
Related
I am a high school student, who is not very familiar with FPGAs and the Xilinx line.
I am running a ring oscillator module on a Zybo Z7 board. I am also running a counter module, which I want to sample at a high rate. I am currently sending the data through AXI to the ZYNQ processing system, and then using the inbuilt UART to USB buffer to send the data through a USB cable to my computer. On the computer side, I treat this input as a virtual serial line, and use a python script to take and log the data from an IOstream. This method takes very long, however, and I am trying to increase the sample speed. Thus, I was wondering if I could bypass the onboard PS, and connect the FPGA fabric directly to the UART buffer.
I have tried optimizing my PS code, which I have written in C. I have reached the point where it takes 30 oscillations of the onboard ZYNQ clock between samples. Now, however, I have created a newer and more reliable sampling framework in the FPGA logic, which requires a 'handshake' mechanism to start and stop the counter between samples. It takes a very long time for the PS to sample the counter, send the sample, and then restart the counter. Thus, the uptime of my sampling framework is a fraction of what I want it to be. Removing the PS would be ideal, as I know I can automate this handshake signal within the PL if I am able to connect it to a UART interface.
You can implement logic in the PL that can handle the UART communication thus bypassing the PS.
Here's an implementation you can try using:https://github.com/jakubcabal/uart-for-fpga
You would connect the UART pins to one of the Zybo Z7 Pmod ports and use an external USB to UART adapter such as this one, anyone would work as long it supports 3.3V: https://www.adafruit.com/product/5335
The adapter built into the board is connected to directly to the PS MIO pins and cannot be used by the PL.
As you probably guessed this question is not about a programming language but about arduino.
I'm making a big project which includes a GSM SIM900A module but it draws too much power.
I've looked up the datasheet but I didn't understand a lot as it references a DTR pin, something my module doesn't have.
Can someone tell me how to put it to sleep mode?
Any help will be grately appreciated!
Thanks in advance!
The GSM standard AT command for the setting of modem's level of functionality is AT+CFUN.
According to SIM900 AT commands guide its syntax is
AT+CFUN=fun[,rst]
Where:
fun: is the power saving mode
rst: is the reset flag
There are several possible values of fun parameter that can be supported or not depending on the modem vendor.
In order to reduce power consumption, SIM900A offers two possibilities:
AT+CFUN=0, means that the device is in sleep mode, and the AT interface is not accessible. Usually it keeps its network paging activities and its registration status to the network (it's not really clear from SIM900 guide). The device is woken up as soon as a wake up event occurs (for example an incoming SMS). Test it on your device.
AT+CFUN=4, that disable both TX and RX RF circuits. The AT interface remains reachable.
Usually first solution results in a bigger reduction of power consumption, but I suggest trying both of them in your specific board in order to understand what is the better choice for you.
I have developed a card with sim900 and ATmel, and it works very well, but when I changed sim900 for sim800 it did not recognize the sim card.
Difference in hardware design?
SIM800,SIM800C modem operates from 3.4V to 4.4V supply range (Reduced operating range !)
SIM900, SIM900A modules operate from 3.2V to 4.8V supply range.
SIM800 is having a Pin to connect with Bluetooth Antenna
Apart from these differences the hardware design is almost similar. The same hardware circuit can be used for the SIM IC if the generated supply is within 3.4V to 4.4V for both types..
I faced this issue before. I tried to contact SIMCOM but I didn't get any response.
My solution was to give to the modem a few seconds more time to boot, before I sent any commands to it.
Even if you get an ERROR as a response when you check for the SIM card you can insist on polling the same command until a predefined timeout time.
Also, note that not all of SIM800 have a Bluetooth feature.
Which country are you currently located? SIM900A works with Dual-Band 900/ 1800 MHz. I believe it was designed for US band while SIM800C is Quad-band 850/900/1800/1900MHz and may operate world wide.
Find out the bands used by your mobile service provider and use module compatible with the band.
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 know both are bluetooth smart devices. I need to know whether both can be used for the same applications. If not what do they have in common and what is different about them?
A sensortag can be configured to be an iBeacon, but it is designed to be a more generic Bluetooth LE device that can be put to many other uses as well, providing many other Bluetooth services.
An iBeacon is a very specific type of Bluetooth LE device, and many types of iBeacons can only perform that one function.
Because a sensortag is so generic, it is not optimized to be an iBeacon. Its battery, for example, will not last a super long time when acting as an iBeacon.
A TI "Sensortag" is basically just an eval board for the CC2540 / CC2541 BLE chips.
Most hardware "iBeacon" implementations use either that chip, or the competing NRF51822, on a more specialized custom board.
In either case, the transmission of "iBeacon"-formatted BLE advertising packets is controlled by the custom firmware loaded into the device.
The duty cycle, which is the major determination of power consumption, is also determined by the firmware. The Sensortag does have some other onboard peripherals, but if the design is sane it should be possible to get those into a negligible powered-down state.
Answering #TimTisdall comment (below), the following link is a 3rd party, non-official iBeacon-enabled firmware update for TI's 2541DK SensorTag hardware:
hex firmware files, demonstrating iBeacon on the cc254x
For more info regarding SensorTag, see:
http://www.ti.com/ww/en/wireless_connectivity/sensortag
&
http://www.ti.com/tool/CC2541DK-SENSOR
This question was a bit ahead of the time and here are some updates: The SensorTag now officially supports iBeacon technology. Information on how to configure it to act as an iBeacon is described in the wiki.
As davidgyoung already pointed out: it wasn't build to solely work as an iBeacon, so it may come with reduced battery life. On the other hand, it provides more functionality, which makes it a valuable tool for development at a good price tag.
As noted before the SensorTag has many other sensors on board. Using a "generic" iBeacon firmware on the SensorTag results in a high current consumption. The unused sensors need to be put into sleep mode (I believe it was the Gyro implementation, which eats a lot of power when not configured correctly in sleep mode).