Need help in C51 Programming

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

 RE: Need help in C51 Programming

Your code is broken - you have no loop to check if the "learn" button is pressed or not.

Next thing - there is nothing magic about this processsor. So what is stopping you from reading 8 bits and shift into a byte before storing and then read 8 new bits. Obviously, you need to consider the fact that 300 samples does not divide evenly with 8.

 RE: Need help in C51 Programming

Thank you Sir, for your reply. Your Sentence "Next thing - there is nothing magic about this processsor.", are you trying to say that this processor is really straight forward to program?

So, for me to be able to store bit by bit then shift to next byte, i have to use bitshift till i stored all 8 bits. Then shift byte and continue the process?

Regarding the 300 samples, i was trying to declare 300 bytes instead of bits. Well, my programming is seriously weak, so bear with my mistakes. So if i were to declare 300 bytes, it would mean that i will be storing my every bit data into every byte of data? If so, i will change it from 300 to 2400 as it will become 300bytes.

 bible time

http://www.8052.com/faqs/120112

 RE: Need help in C51 Programming

You have to either store one sample / byte (which would consume lots of extra RAM) or you have to perform traditional bit shift operations to fit 8 samples into the first byte before moving to the second byte.

The processor do not have any magic bit-array instruction that can allow it to write to the nth bit of an array - the code is limited to either write to a hard-coded bit position (in the specific memory bit-addressable memory area which is smaller than 300 bits anyway) or must perform compute which specific bit in which specify byte and then update that byte using standard C code.

 RE: Need help in C51 Programming

"...you have to perform traditional bit shift operations to fit 8 samples into the first byte before moving to the second byte." That is exactly what i wanted to do. I'm trying to store 2400 bits = 300 bytes. Which i want to use the bit shift method in order to save memory. However, i would want to ask if the first data be stored in the LSB or MSB of the byte?

Thanks in advance.

 RE: Need help in C51 Programming

"However, i would want to ask if the first data be stored in the LSB or MSB of the byte?"

That is entirely up to you. Do you want to shift in from left or from right? As I said - there isn't anything magic with the processor. You make the decisions, and select the suitable C constructs.

 RE: Need help in C51 Programming

I'm currently using Keil uvision to program AT89S4051 Microcontroller
I'm trying to store 2400 bits = 300 bytes
WHERE?, in thin air?

Erik

 RE: Need help in C51 Programming

Ah i'm sorry, trying to program it on an external memory 16Kbit.

 RE: Need help in C51 Programming

how are you going to connect an external memory to an AT89S4051 ?

Erik

 RE: Need help in C51 Programming

Oh, i just realised that AT89S4051 doesn't support external memory. Sorry, i'm really a newb. I will change it to another Microcontroller

 RE: if the first data be stored in the LSB or MSB of the byte?

That depends on what you want to do with the byte once you have filled it!

If you want it to be usable as a 'C' variable, then you will have to use the same convention that the compiler uses - which is described in the compiler Manual:

http://www.keil.com/support/man/docs/c51/c51_ap_datastorage.htm

 RE: Need help in C51 Programming

"...or you have to perform traditional bit shift operations to fit 8 samples into the first byte before moving to the second byte."

But how do i exactly do that in the program?

 x[i] = x[i]>>1;

This way? Then how do i shift the byte? Is there any link to any website that will teach me how to bit shift by 1 and store and byte shift? Thank You.

 RE: any link to any website that will teach me how to bit shift by 1 and store and byte shift?

That is a basic 'C' coding question - nothing specifically to do with the 8051 or Keil.

Newly-updated 'C' learning/reference resources here: http://blog.antronics.co.uk/2011/08/08/

Note that a shift "up" is usually taken to mean a shift to the left:

x <<= 1;

 RE: any link to any website that will teach me how to bit shift by 1 and store and byte shift?

Almost all microcontrollers supports external memory. Just note that not all external memory are parallell-accessed RAM.

There are I2C-connected EEPROM memories.

Or for maximum write speed while still reducing the amount of processor pins consumed, there are SPI-connected F-RAM memories.

An interesting thing with the SPI interface is that it is a serial interface that makes it quite easy to integrate the shifting of new bit data from your input pin directly to the memory chip. So you send out eight bits (a full byte) and the F-RAM memory moves to next byte and expects 8 new bits.

With EEPROM or F-RAM, the memory is non-volatile, so the stored data will be retained even you remove the power. But you need to add some extra logic to store some indexing data, so you can later figure out if there are valid measurements stored in the memory or not.

If you don't need non-volatile memory, then it's enough to select a processor with enough built-in RAM memory, allowing you to use a standard array for storing the sampled data.

 RE: any link to any website that will teach me how to bit shift by 1 and store and byte shift?

So, if i were to use Fujitsu I2C 16Kbit FRAM (http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=46583)it will still work perfectly fine? And Yes, i do need a non-volatile memory.

 strange choice

if i were to use Fujitsu I2C 16Kbit FRAM
the AT89S4051 has hardware SPI, so using an I²C EEPROM when SPI EEPROMS are plentiful is a strange choice.

Oh, i just realised that AT89S4051 doesn't support external memory. Sorry, i'm really a newb.
being a newbie is not an excuse for not reading the datasheet. au contraire, it makes it much more important.

STOP with what you are doing, and familiarize yourself with "the bible" (link in earlier post) and the datasheet. To get what you want done the method is NOT to bungle along and every time you find a bump in the road write another post. Many of your previous questions would not have been asked had you read the bible and the datasheet.

Erik

 RE: strange choice

Okay, thanks alot Erik. I will follow your advice well and sorry for all the inconvenience/annoyance caused :)

 RE: strange choice

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.

 another factor

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

 RE: another factor

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

 RE: strange choice

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.

 RE: strange choice

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

Erik

 RE: strange choice

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.