|
|
View previous topic :: View next topic |
Author |
Message |
gabirelms
Joined: 28 Jun 2014 Posts: 38
|
Produce a 2Mhz square wave |
Posted: Fri Jul 04, 2014 3:56 pm |
|
|
Hi all,
I'm trying to produce a 2Mhz square wave on my PIC16LF1459.
I'm running at 16MHz, which means that the internal clock is 4MHz.
I need a pulse period of 500ns to achieve 2Mhz. Which means that I can set a PIN to be high for 250ns, then low for 250ns and so on... right?
Well, I tried this code:
Code: |
output_high(PIN_RB5);
delay_cycles(1);
output_low(PIN_RB5);
delay_cycles(1);
|
But I think I'm getting less than 2Mhz. Am I doing something wrong?
Is there any difference if I use PIN RB7 ?
Any help would be appreciated
Thanks |
|
|
dyeatman
Joined: 06 Sep 2003 Posts: 1933 Location: Norman, OK
|
|
Posted: Fri Jul 04, 2014 4:00 pm |
|
|
The first question I have is why only 16Mhz?
The chip will run at 48Mhz on the internal oscillator.
Should be easy to get 2Mhz output with a 24Mhz or 48Mhz clock.
If you are limited due to this being a class project then you need to
figure it out. That's the purpose of a class assignment is to learn. _________________ Google and Forum Search are some of your best tools!!!! |
|
|
jeremiah
Joined: 20 Jul 2010 Posts: 1346
|
|
Posted: Fri Jul 04, 2014 4:10 pm |
|
|
You need to think about how long each of those lines of code takes to execute.
output_high() takes time. Calculate how much. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9225 Location: Greensville,Ontario
|
|
Posted: Fri Jul 04, 2014 4:33 pm |
|
|
Yes, you're doing something wrong..see Jeremiah's post.....Just dump the listing, open datasheet to 'instruction set', and 'play computer' to calculate the times. It's easy, simple takes all of 10-15 minutes at most.
No, pin RB7 should be the same as RB5, though you should read the datasheet for that PIC, just to confirm/deny that they are the same. Some pins are 'funny' (aka the open-collector RA4 for example).
The bottom line is YOU must READ the datasheet to decide what is happening and why. It's part of the scientific method of learning. The more you read the more you absorb(learn) and the better you get, so hopefully you get a great job.
hth
jay |
|
|
gabirelms
Joined: 28 Jun 2014 Posts: 38
|
|
Posted: Fri Jul 04, 2014 5:30 pm |
|
|
I feel my knowledge is very basic, I would like to learn faster.
I will check data sheet more in details. I can increase mcu to 24Mhz, or 48Mhz, I was trying my best to keep power low.
I wanted to connect PIC to a sensor using UART.
I asked about RB7 pin because data sheet says:
RB5 - RX/DX
RB7 - TX/CK
But I already soldered RB5 to sensor IC strobe (clock) pin, and RB7 to sensor IC data pin. I hope no problem with that...
Last edited by gabirelms on Sat Jul 05, 2014 1:50 am; edited 1 time in total |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Fri Jul 04, 2014 6:07 pm |
|
|
Instead of doing all this, why not tell us what your sensor chip is ?
Maybe we can think of a better way. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9225 Location: Greensville,Ontario
|
|
Posted: Fri Jul 04, 2014 6:16 pm |
|
|
In 'reading between the lines' I get the idea you're running off a battery ? if so, you'll need to do an very, very detailed analysis of REAL power consumption vs time to deal with how BIG a battery you need ( hint...always triple your capacity !)
Normally you would not use delays to generate square wave as it means the PIC is only doing that. Typically you use a PWM peripheral and most PICs have them these days.
As previously posted we really need more info about the overall concept and devices you're using.
hth
jay |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19506
|
|
Posted: Sat Jul 05, 2014 12:09 am |
|
|
Even more directly, if the sensor wants a signal at a clock frequency, with it's data, or outputs it''s data using a clock, then it sounds rather like SPI....
Seriously, to do this in software, you will be very unlikely to get to the clock frequency required. There is no problem clocking the line, but doing anything else, runs out of time.
If (for instance), the unit requires this line at 250KHz, and outputs data bits synchronised to this, then the code needs to output the clock, read the bit, shift this into a register, count bits, loop, etc. etc. You run out of time, even with much faster processors. This is why the chips have hardware for this (SPI....).
However most units using a synchronous clock, don't need the clock to be 'at' a frequency. Instead they _synchronise_ to the clock (the 'S' in SPI, stands for 'synchronous'), so they will accept any clock _below_ their rated figure, so that they can be driven from a wide variety of processors, that can't generate an exact frequency...
Now, the 'UART' on the PIC chips is commonly called a 'UART' (universal asynchronous receiver transmitter), but is actually a _USART_ (note the 'S'). The 'S' again stands for synchronous. In synchronous mode, when you send a byte, the peripheral develops a clock out the TX pin, and sends/receives the data (only one way at a time), on the RX pin. This mode is enabled in CCS, by using 'SYNC_MASTER' in the #use RS232 declaration. It may well be that this is what you need, but it will depend on the peripheral you are talking to.
So 'part number' for the peripheral. Preferably with a line to the data sheet, then we should be able to help you to get the interface as needed by it and the PIC. |
|
|
gabirelms
Joined: 28 Jun 2014 Posts: 38
|
|
Posted: Sat Jul 05, 2014 1:49 am |
|
|
This is a multi-axis sensor with data buffer.
Data sheet is not public, but the idea is quite simple, to extract information from buffer I have to send strobe, and receive data.
Maximum strobe frequency is 2Mhz, of course I can work at lower frequency, I just wanted to know how to reach the maximum. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19506
|
|
Posted: Sat Jul 05, 2014 2:51 am |
|
|
Sounds like it uses an SPI chip.....
Look at what the MSSP hardware does. Can generate data clocks up to 4Mhz from a chip clocked at 16MHz. 2Mhz is easy.
Even better, it can be clocking the next byte, while you save the last one.
It's worth realising that if you use software SPI (which generates the clock, reads the input, shifts this into a byte for use, updates the counters etc..), the best speed is around 16 instruction cycles per bit. All optimised in assembler. The hardware SPI, instead manages to go up to 1 instruction cycle per bit..... |
|
|
gabirelms
Joined: 28 Jun 2014 Posts: 38
|
|
Posted: Sat Jul 05, 2014 5:35 am |
|
|
Well, I'm using SPI to connect PIC to SPI flash. Which needs 4 wires: CS, SDI, SDO, and SCK.
And the sensor only has 2 wires: data (output of the sensor), and strobe (input of the sensor). I think this must be USART.
I used RB5 and RB7, which are the USART pins in PIC16LF1459.
Maybe I should change my questions:
1. Is it doable to generate 2mhz strobe (for usart), with mcu running at 16Mhz ?
2. Port RB5 and port RB7 are interchangeable ? |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9225 Location: Greensville,Ontario
|
|
Posted: Sat Jul 05, 2014 6:42 am |
|
|
...
Data sheet is not public
..
HUH ????
Without a proper datasheet how are we supposed to know HOW this device communicates?
WHAT does 'strobe' do ? Initiate the data transfer or 1 pulse per data bit? HUGE difference!
HOW many databits?
WHY do you 'think' it's a UART compatible datastream? Most UARTS are good for 5-9 bits of data,plus start/stop bits though that's NOT a hard rule. I use 22 bit UARTs all the time.
Without proper documentation it could take you months to decode the correct command and data format.
Then there's the 5V PIC vs 3V peripheral problem, or maybe the device is RS232 or other interface ?
TOO many questions need real answers before I ( and others) can really help.
Jay |
|
|
dyeatman
Joined: 06 Sep 2003 Posts: 1933 Location: Norman, OK
|
|
Posted: Sat Jul 05, 2014 7:19 am |
|
|
This project has gone from just trying to produce a 2Mhz square wave
to being "low power" or "battery", to a using a "UART", to a having "sensor",
to using SPI, to using "SPI flash", and now is trying to talk
to a device that doesn't have a public datasheet!
It would REALLY be nice if you had told us up front what you have and are
trying to do instead of a game of twenty questions. We shouldn't have to,
as TTelmah puts it, "read between the lines"!
I have better things to do with my time... _________________ Google and Forum Search are some of your best tools!!!! |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9225 Location: Greensville,Ontario
|
|
Posted: Sat Jul 05, 2014 8:06 am |
|
|
and of course NOW I'm curious as to WHAT the 'sensor' is !!!
I did manage to properly rebuild an 8n carb that a 'pro' had rebuilt while thinking about this 'project'.....
oh well...keeps the grey cells working...
just WHAT is it anyway ?
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19506
|
|
Posted: Sat Jul 05, 2014 8:20 am |
|
|
gabirelms wrote: | Well, I'm using SPI to connect PIC to SPI flash. Which needs 4 wires: CS, SDI, SDO, and SCK.
And the sensor only has 2 wires: data (output of the sensor), and strobe (input of the sensor). I think this must be USART.
I used RB5 and RB7, which are the USART pins in PIC16LF1459.
Maybe I should change my questions:
1. Is it doable to generate 2mhz strobe (for usart), with mcu running at 16Mhz ?
2. Port RB5 and port RB7 are interchangeable ? |
No.
SPI, needs three wires when it is both sending _and_ receiving. However 'one way' SPI, only needs two wires.
The extra wire (CS) is just a 'select', but also makes _staying in sync_ much easier. The device stops what is doing when this goes off (normally high), and starts with a 'count' of zero when this drops. Without this, starting a transmission 'in sync' is very hard. At the very least there needs to be some form of 'marker', or some similar way of resetting the device (usually by stopping the clock for a long period).
At the very least you are going to need to ensure that the PIC lines are biased to the off state when the PIC is starting to have any hope of beginning in sync.
Even if you can't post a data sheet for the device, the odds are that the interface either uses a standard chip, or uses logic in a gate array. As such the protocol must be defined. Post this.
It sounds like it is based on something like a standard multi-axis accelerometer chip.
You can use the SPI for multiple devices (this is the whole point of the CS line). If your device doesn't have a select, this can be generated, by using a simple logic gate to turn off the clock to the second device when you want to talk to the first. Even easier, get hold of a chip with multiple SPI ports.
The MSSP supports higher clock rates than the USART can manage.
Your connections would be wrong even if using the USART. It is the TX line that develops the clock in sync mode, and the RX line that both sends and receives the data. |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|