8-bit uC question

Discussion in 'Embedded Systems and Microcontrollers' started by rasosina, Aug 21, 2011.

  1. rasosina

    Thread Starter Member

    Jun 30, 2010
    25
    0
    Hi All,

    I'm sorry for being such a noob, but I have no experience with microcontrollers so I was wondering if it is possible to do the following:

    I have a chip that needs a 24-bit burst of serial data fed to it from a microcontroller. now i'm wondering if my microcontroller needs to be 24/32-bit to do this, or can an 8-bit controller work for this?

    the 24-bit data needs to be updated by the microcontroller on the falling edge of clk and it gets sampled by the chip at the rising edge of clk.

    so is it possible to store the data on 3 bytes of memory and outputted to a pin seamlessly to give the 24-bit data the chip needs?


    thanks
     
  2. Arm_n_Legs

    Active Member

    Mar 7, 2007
    183
    10
    Yes. A 8-bit u-C will do the job.
     
  3. hgmjr

    Moderator

    Jan 28, 2005
    9,030
    214
    It would be helpful if you could provide us with a few more details.

    What is the bit rate of this bit stream?

    How often do these bursts take place?

    The 8 bit micro has the ability to perform the bit stream you described but if the aggregate bit rate is to high then you may need to look to a more powerful device.

    hgmjr
     
  4. rasosina

    Thread Starter Member

    Jun 30, 2010
    25
    0
    Hi all,

    thanks for the replies.

    hgmjr: these bursts don't occur that often at all, they're initiated by a user input (which may be once every couple seconds) and there's no requirement for the speed of operation.

    also, since the device is powered by a battery the bit rate can be chosen to be small so there's no limitations on that either.

    basically no real need for speed. just needs a clock and 24-bit burst of data input.

    now my question is how would i be able to do that? i've been lookin through tech specs of some microcontrollers and i'm seeing features like I2C and SPI. but those features seem to send extra start/stop bits, or wait for acknowledge bits after the 8th bit which i don't want.

    this may be another noob question but is it possible to just output each individual bit from 3 bytes of memory onto a digital pin at every falling edge of clock without missing a clk cycle?

    any suggestions/input is appreciated. also, i'd like to go with a PIC controller if that helps, as I already have a pickit2 programmer.

    thanks
     
  5. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,386
    1,605
    Don't put the cart before the horse, meaning you need to define what the receiver of this data stream is expecting. Just saying "serial" can mean many many things. What is this "chip" that is receiving this data?

    Well, not really. You will need a few instructions to pull the appropriate bit from the 3 bytes, place it on an output pin, and then wiggle the clock pin. This gets back to my first point where you need to define this serial data stream better.

    Picking the PIC should be a step near then end as there may be a speed limitation. That's doubtful, but no reason to design yourself into a corner just yet. A PicKit 2 can control a huge set of PICs, and you can pick one that is fast enough and probably get one on an inexpensive development board too.
     
    absf and jj_alukkas like this.
  6. hgmjr

    Moderator

    Jan 28, 2005
    9,030
    214
    erniem has a good point. It would be helpful for you to let us know what the receiver is going to be provided on already exists. Also, over what distance do you need this serial bit stream to be sent?

    I understand from your answer to my earlier query that the speed of the bit stream is not all that critical. That does make it more likely that your application can be solved with a PIC, or an AVR You could even use an Arduino Uno (www.arduino.cc) if you don't want to be bothered with designing the hardware.

    hgmjr
     
  7. rasosina

    Thread Starter Member

    Jun 30, 2010
    25
    0
    Hey guys,

    Sorry I should have shed a little more light into the situation. Basically I want to design a controller to control the Rohm BH1414k ic.

    here's the link to the bh1414k datasheet and the info can be found on page 17:
    http://www.pira.cz/pdf/bh1414k.pdf

    so i would need to provide pin 31 with a clock, drive pin 32 high, and drive the serial data into pin 30.

    in a bigger scheme of things, i want to build an fm transmitter. so i want to have a microcontroller that takes an analog signal from the user (such as the adjustment of a pot), do some basic calculations and map it to a certain frequency, spit the data out to the Rohm fm ic and also display the frequency on a 7-segment display.

    This project proved to be a harder beginner's project than i anticipated. but all of your inputs is greatly appreciated.

    thanks again
     
  8. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,386
    1,605
    Yeah, just about any micro will do. The timing diagram you pointed to says the pulse widths are 1.5 uS minimum, so you can go slower as you pull out each bit and send it along. "Slower" is a relative term, you'll get out the whole 24 bits in a millisecond or so.
     
  9. jj_alukkas

    Well-Known Member

    Jan 8, 2009
    751
    5
    Your eyes are so catchy!! you tell the exact solution with a quick view of the datasheet! WoW!
     
  10. rasosina

    Thread Starter Member

    Jun 30, 2010
    25
    0
    Hi ErnieM,

    Thanks for your reply, but I'm not sure if I fully got what you meant by 'go slower as you pull out each bit'. Do you mean that I can output a slower clock to the Rohm IC compared to the internal controller clock? and then output each bit based on the slower clock?

    thanks again.
     
  11. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,386
    1,605
    Page 17 of the data sheet says the clock period is a minimum, that means you can make it larger. That is good as it means your micro can output bits at a slower pace and it will still accept the data. So you don't have to make any tight timing loops as you shift out the bits, just write some decent code to wiggle the pins and you're good.

    That compares to say the RS-232 protocol where the data is the clock and you must send it at fairly precise intervals.

    @jj: A millisecond is not quite a wild ass guess, I made some stuff up before I typed it. If you assume 1uS per instruction (which is a 4MHz clock on a PIC so pretty much all of them can do that), guestimate 50 instructions per bit, and 24 bits gives: 1us * 50 * 24 = 1200 uS = 1.2 mS.

    That's just an "engineering sense," get yourself a quantitative guess before you do any real work on something that is not going to work.
     
  12. rasosina

    Thread Starter Member

    Jun 30, 2010
    25
    0
    oh ok, so when you say your micro can output bits at a slower pace, you are comparing it to the micro's internal clock right? because the fm ic still needs to be fed a clock that is in sync with the data that it's being fed.

    so to sum up, you're saying that i can feed the ic with a new slow clock generated by the micro and also have the micro send the data bits sync'd on the same slow clock. so this way the micro can execute and do whatever it needs to prepare each bit to be outputted, all in one cycle of the new slow clock. i hope that makes sense lol.

    also, if i want to drive a 7 segment display with 32 segments do i need to get a pic that has LCD drive capabilities, or can i just use any pic that has 32 digital io pins available to drive each segment? I think the lcd needs 5v supply so i know i gotta make sure that the pic can output 5v, but other than that do i need to consider anything else? like current limitations, etc.?
     
  13. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,386
    1,605
    LOL, it can gets bit confusing yep. The term "clock" meals lots of things and can mean different things inside the same circuit. The micro has a clock that sets how fast it runs. The micro will also have an I/O pin, driven up and down by software, that drives the clock input on the FM IC.

    So we have 2 clocks with different frequencies on one chip.

    That depends on what kind of display you want to use. Something like this:

    [​IMG]

    is a raw display and needs some special handling to work right as every pin is an exact 50% duty cycle square wave. A 4 digit display has 32 elements and a common (33 total), the pin for a segment element needs go in phase or out of phase to the common line to turn off or on. It can be done with just about any micro (I did it years back) but it takes some work by the micro to keep the display updated. The pins take no appreciable current.
     
  14. rasosina

    Thread Starter Member

    Jun 30, 2010
    25
    0
    oh ok. ya thats actually the type of screen i was looking at, thanks for the tips im sure i can get it to work somehow. but thanks a lot for all ur help ernie :D. i really appreciate it.
     
  15. nickelflipper

    Active Member

    Jun 2, 2010
    280
    35
    The PIC16F917 and others have an LCD driver module for those "bare glass" type LCD's.
     
  16. rasosina

    Thread Starter Member

    Jun 30, 2010
    25
    0
    oh sweet. ok thx nickel i'll look into it.

    guys i just realized that one of the computations that the pic needs to do some calculations that may require more than 8-bits.

    in the datasheet it says for example (page 17 of datasheet i posted before):

    In case of 99.7MHz oscillation
    99.7MHz
    ÷100kHz(fref)=997→3E5(HEX)

    which is 12-bit binary number.. so can i still use an 8-bit micro for this? basically a pot that the user adjusts will determine the frequency of oscillation so i'm getting pretty confused as to how this 12 bit number would get stored on the memory.

    thanks
     
  17. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,386
    1,605
    Oh heck yeah an 8 bit processor can handle numbers bigger then 255.

    You haven't said what you will use to compile the program but any (any!) compiler will handle integers of 16 bits, and most up to 32 bits.

    That's 65,535 or 4,294,967,295. They just get stored as a series of bytes.

    There are free compilers available for download from Microchip. Try em out.
     
  18. rasosina

    Thread Starter Member

    Jun 30, 2010
    25
    0
    oh sweet ok. so the micro will do the calculation and store the 12 bits in two bytes, got it.

    well i haven't really done any uC programming and have a pretty weak C++ programming background so i gotta start considering the programming aspect of it. I'm planning on using the standard Microchip IDE that they give with their pics. We'll see how that goes.

    Thanks again Ernie.
     
  19. Markd77

    Senior Member

    Sep 7, 2009
    2,803
    594
    In your case you need to store numbers from 88-108MHz but at a guess you need a resolution of 0.05MHz (that's what my tuner does) so you only need to store a number from 0-399 (20X20).
    That takes 2 bytes but so does storing the range 0-108MHz at the same resolution (108X20=2160).
    The ADC on most PICs (which you would use to read the dial) is 10 bit ie. a number from 0-1023 so there is a bit of conversion to do, but it's not too bad.
     
  20. rasosina

    Thread Starter Member

    Jun 30, 2010
    25
    0
    Hey Markd,

    thanks for the clarification. I see what you mean. and i can always go with a lower resolution if i can't work the conversion out. i think if i use a 0.1Mhz res which would give 20x10 possibilities which i can fit in 1 byte so i'd have no problems with the 10-bit ADC.

    but i have another question: i understand when you use a voltage reg, u'd need to have shunt caps to minimize transients, but i've seen some schematics using two shunt capacitances on the same side with different sizes. i.e. they would have 2 caps on output side one being 10uF and the other being 1uF. is this really needed? is it to just filter out the different frequencies? i went thru a couple datasheets but they never mentioned such thing.

    thanks again for all the info, i really appreciate it.
     
Loading...