We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi, i'm pretty new to programming. I'm currently using Keil uvision to program AT89S4051 Microcontroller in C language. I'm trying to read bit by bit data from the I/O port every 50us and store it in an external memory bit by bit. However, i would want to store a bit then shift to next bit and store. After 8 bits, store on a new byte and for 300 bytes. Anyone could suggest a method on how to do that? My program is posted down below (it's probably full of mistakes) Thanks in advance.
#include <reg51.h> sbit Tsignal = P1^2; //Input Signal sbit Learn = P1^3; unsigned int i; unsigned char xdata x[300]; unsigned char xdata y[300]; void timer0(void) { TMOD = 0x01; //Timer0 , Mode 1 TH0 = 0xFF; //Set timer to count from -46 = FFD2h TL0 = 0xD2; TR0 = 1; while(TF0==0); //Turn on Timer0 TF0 = 0; //Set Flag to 0; TR0 = 0; //Turn off Timer0 } void main(void) { Learn=0; if(Learn==1) //If learn button is pressed, data as stored as sampling data { for(i=0;i<299;i++) //Loop for 300 bytes { timer0(); //Call timer0 function x[i] = Tsignal; //Store Tsignal in x } } else //When Learn button is not pressed, data is stored as { for(i=0;i<299;i++) //Loop for 300 bytes { timer0(); //Call timer0 function y[i] = Tsignal; //Store Tsignal in y } } }
Okay, thanks alot Erik. I will follow your advice well and sorry for all the inconvenience/annoyance caused :)
From a timing perspective, SPI is way nicer to work with. And the code is normally way simpler to write than for I2C-connected memories, unless you happen to find complete code.
You seem to be quick to take decisions - you should try to do the reverse. Spend time reading up on your alternatives before taking a decision. Like now - you should not instantly jump at I2C because the first sentence in my previous post mentioned I2C. You should read enough to know the difference between I2C and SPI, and then check the implications of the two alternatives for your specific processor.
Taking too quick decisions just means you get stuck because you spend your time running through brick walls. Wasting extra time reading up on your alternatives means you can make decisions that ends in working solutions. Every hour extra you spend to make good decisions will save you 10 hours later in the project.
And the code is normally way simpler to write than for I2C-connected memories my primary consideration would be if the chosen processor had hardware interface for either. Serial comm by bit-banging is VERY processor intensive.
Erik
Advice noted, however i have already decided on that External Memory a couple of days ago when i needed external memory. But, i didn't read the datasheet well enough and my understanding of the fundamentals are weak. Thus, reading up the 'bible links' and the datasheet will be done. Thanks for all the help Westermark.
Per writes: You seem to be quick to take decisions - you should try to do the reverse. Spend time reading up on your alternatives before taking a decision.
you reply: i have already decided ...
you can (in my opinion should) change that decision after studying the availabe documentation
Yeah, definitely i will choose a suitable/better choice after i studied the notes. Just now i was only trying to say that i chose the External Memory is not because of Per mentioned about I2C.
"Serial comm by bit-banging is VERY processor intensive."
Depends on required timing. When you have sw-driven SPI and the external SPI device supports 40MHz, the amount of delay between each bit is very short, so a busy-looped write of one byte is quite inexpensive. In some situations, a SPI-connected memory may be so fast compared to the processor core that zero delays may be needed. So the microcontrollers performs 16 writes to the clock line and 8 writes to the data out signal at maximum speed and then one byte have been written.
In this case, the code is expected to read in bits one-by-one from a pin every 50us. That also means that it is very easy to have that same loop save out the data one bit at a time with almost zero extra "cost". So SPI would be a good choice, even if the processor do not have hw support for SPI.
Obviously, hardware SPI is good to use if the processor has it. It does give the developer more options on how to interface the memory - if the data should be emitted a bit at a time as it is read in, or if the data should be buffered until a full byte can be written. Or if the data should maybe be buffered until multiple bytes can be sent out. It's just a question of the capabilities of the SPI hardware in the processor, and what other choices the software developer needs to date - writing to a SPI-connected memory is seldom the only task of a real embedded application.