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 } } }
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
"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.