I need to communicate with a device using SMBus and display SOC on a seven segment display. I use PIC18F26K83. Seven Segment Display needs I2C connection. The problem is I will be using 2 different I2C modules with 2 different I2C clocks. SMBus needs to be between 10 kHz and 100 kHz. I use 8 MHz MCU clock. With seven segment display part I cannot make it work without setting I2CxCLK register to HFINTOSC (0010). I tried using TMR2 post scaled output for it. Timer code is below:
void InitTimer2(){
T2CLK =0b00000101; //500 kHz
T2CON.B7 = 1; //Timer 2 is on
T2CON.B3=0;
T2CON.B3=0;
T2CON.B3=0; //Timer 2 PostScaler = 1:2 (500/2 = 250 kHz)
T2CON.B3=1;
}
Then I call this InitTimer2() function in the main method. After that I choose I2CxCLK to be TMR2 post scaled output (0110). However, it does not work... If I directly set I2CxCLK HFINTOSC then it works. (In all cases MCU Clock is 8 MHz). So my questions are:
Is that timer initialization correct?
Does my MCU frequency, affect the timer frequency?
Are there any other ways that I can choose in order to have 100 kHz and 250 kHz I2C clocks with a 8 mHz MCU frequency?
Shouldn't be InitTimer2 function as the following:
void InitTimer2(){
T2CLK =0b00000101; //500 kHz
T2CON.B7 = 1; //Timer 2 is on
T2CON.B3=0;
T2CON.B2=0;
T2CON.B1=0;
T2CON.B0=1; //Timer 2 PostScaler = 1:2 (500/2 = 250 kHz)
}
Also please check the PMD function of the PIC. See pg.275 and pg.277 of the datasheet.
Make sure TMR2MD=0.
Related
I'm running a buildroot linux environment on a STM32MP157 dev board. I have a button with an internal pullup on pin B12. I want to fire an interrupt once the line goes low. On other linux boards like the RPi, I've been able to call gpio_to_irq(<gpio#>) and get the IRQ for that pin. Done, simple. However, on this board, there are only 16 external interrupts connected to the EXTI peripheral; they are configurable in a sense that any port may be connected to the EXTI, but the pin numbers cannot overlap. For example GPIO A12 and B12 may NOT be connected to the EXTI at the same time. I have ensured that no other devices are using and GPIO port pin 12.
I have edited my DTS file to reflect that I want my GPIO B12 connected to the EXTI controller. But so far I have had no luck in making that happen. Here is the documentation for the interrupts provided by ST. If someone can explain how to fix the device tree such that I can request the B12 interrupt from my driver I would really appreciate it.
Here's my DTS file:
/dts-v1/;
#include "stm32mp157.dtsi"
#include "stm32mp15xa.dtsi"
#include "stm32mp15-pinctrl.dtsi"
#include "stm32mp15xxac-pinctrl.dtsi"
#include "stm32mp15xx-dkx.dtsi"
/ {
model = "STMicroelectronics STM32MP157A-DK1 Discovery Board";
compatible = "st,stm32mp157a-dk1", "st,stm32mp157";
chosen {
stdout-path = "serial0:115200n8";
};
button {
compatible = "test,button";
input-gpios = <&gpiob 12 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>; //Works with pull-up once the driver is loaded.
interrupts-extended = <&gpiob 12 IRQ_TYPE_EDGE_FALLING>;
interrupt-names = "qwerty";
status = "okay";
};
led {
extern-led {
compatible = "test,led";
gpios = <&gpiob 10 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "cpu";
};
};
};
I have tried the following:
interrupts-extended = <&exti 28 IRQ_TYPE_EDGE_FALLING>; (This SOC only has 16 pins per GPIO bank, so B12 is global GPIO 28)
interrupts-extended = <&gpiob 12 IRQ_TYPE_EDGE_FALLING>;
interrupt-parent = <&gpiob>;
interrupts = <12
IRQ_TYPE_EDGE_FALLING>;
Lastly, my stretch goal is to be able to request the IRQ by name, from the interrupt-name property in the device tree. Something like request_irq("qwerty"). Is that possible?
EDIT: I have temporarily connected my pushbutton to GPIO A12, and it successfully fires the interrupt, confirming that the EXTI #12 interrupt is connected to GPIO bank A. How can I go about changing this from within the device tree? Thank you in advance.
Okay I have solved this. Apparently iterating through your GPIO pins with the gpio*_to_irq() functions was the problem. When the function was called, the kernel would immediately configure the EXTI interface for that pin. I thought it was defaulting to Port A, but that was actually caused by iterating through all the GPIO pins looking for the interrupt number starting at GPIO 0, aka Port A Pin 0. So by only calling the gpio_to_irq or gpiod_to_irq function for the pins you need, the kernel will properly configure the EXTI interface for the requested pins.
Introduction:
Okay so to start I just want to say that the sensor does send its data when commanded as I've tested this on Python connected to a COMPORT on a pc. I will include the Python Code I created that works with the sensor, so that all information is available to you guys. I also will include a link to the PJRC Forum that I've asked the same question on, because I've already gotten responses on the issue, but it still persists, and I want you guys to have what they've said at your disposal.
(Python Code & PJRC Link will be at the very bottom of the post)
Problem:
So, my problem is I cannot figure out how to properly send ASCII commands from the Teensy 3.5 and in return read the output of the Flowmeter with the Teensy 3.5. I am afraid that the hardware is connected wrong or I'm just going about something wrong.
The Serial Console will stay blank meaning nothing is available to be read in
What I've Tried - Software:
This is basic code I was given that should work for my use:
char s;
void setup() {
// put your setup code here, to run once:
Serial.begin(9600);
while (!Serial && (millis() < 5000)) {};
Serial1.begin(115200);
delay(1000);
Serial1.print("?\r\n");
}
void loop() {
// put your main code here, to run repeatedly:
while (Serial1.available()){
s = Serial1.read();
Serial.print(s);
}
}
What I've Tried - Hardware:
Image of TSI FlowMeter 5130 w/Cables
Black Wire - USB_C to USB_A - connected to a 5v power supply
Blue/White Wire - USB_A to MALE DB9
Image of Cables that connect the Flowmeter & Teensy 3.5
Blue/White Wire - Male DB9
Tan Serial Gender Converter - Female DB9 to Female DB9
Black Converter Board - Male DB9 to 4-Wire TTL (Red - VCC, Yellow - Transmit, Blue - Receive, Black - GND)
Image of RS232 to TTL Wiring
Yellow Wire - Teensy Transmit Pin 1
Blue Wire - Teensy Receive Pin 0
Red Wire - Currently Set to 5v, but I've tried 3.3v to no avail
Black Wire - GND
Image of LEDs Wired into Rx/Tx of Teensy to watch for data being sent
Blue LED - (Yellow - Teensy Receive Pin 0, Orange - GND)
Green LED - (Red - Teensy Transmit Pin 1, Brown - GND)
Image - 5v Power Supply
White Wire - Teensy 5v
Purple Wire - Teensy GND
Python Code:
import serial
import time
index = 0
total = 0
i = 0
avg = 0
# Serial Connection
time.sleep(.5)
ser = serial.Serial(
port="COM2", baudrate = 115200,
parity=serial.PARITY_NONE, stopbits=serial.STOPBITS_ONE,
bytesize=serial.EIGHTBITS, timeout=1)
# Write ASCII Commands To TSI 5300 Flow Sensor
ser.write(b'?\r\n') # Ask Sensor if it is getting a signal (Returns "OK")
ser.write(b'SUS\r\n') # Set Flow type to SLPM (Returns "OK")
ser.write(b'SG0\r\n') # Set Flow Gas to Air (Returns "OK")
ser.write(b'SSR0005\r\n') # Set Sample Rate to 5ms (Returns "OK")
ser.write(b'LPZ\r\n') # Zero Low Pressure Sensor
# Read serial output to remove all 'OK's from buffer
while (i <= 4):
OK = ser.readline() # Read one line of serial and discard it
print(OK)
i += 1
# Ask for 5 Flow readings
ser.write(b'DAFxxxxx0005\r\n') # Read 5 sensor Flow Reading
ser.readline() # Read one line of serial data and discard it
byte = ser.readline() # Read one line of serial data and store it
print("Unfiltered Bytes: " + str(byte))
string = byte.decode('utf-8') # Convert from BYTE to STRING
array = string.split(',') # Convert from STRING to STRING ARRAY
print("String Array of all 5 readings: " + str(array))
# Convert each element of the ARRAY to FLOAT then add them together
for data in array:
index += 1
data = float(data)
total += data
avg = total / index # Find the average Flow in LPM
print("Average Flow Rate: " + str(avg) + " LPM")
time.sleep(1)
ser.close()
PJRC LINK:
https://forum.pjrc.com/threads/69679-Sending-ASCII-Commands-to-a-Teensy-3-5-Via-RS232-to-TTL-Converter
Yes, you should be able to connect it to the second USB port of the Teensy. This port acts as Host. Whether it works of course depends on which USB interface your flowmeter implements. If it implements some standard (e.g. CDC aka virtual serial or some HID interface) the USB Host lib can probably communicate with it. If they did a proprietary interface you would need to write a corresponding driver first...
I assume they implemented a CDC interface. You can easily check: if you connect the flowmeter to a PC a COM Port (Windows) should appear in the device manager.
I found the solution! It didn't matter which serial it was on (serial1 or serial2), however the problem is I had to start the teensy before the flowmeter and give the flowmeter 20sec to boot up before letting the teensy send any commands! This sensor is so slow though, it takes 50 seconds to fully boot up to the test screen! I just used a 5v relay to delay the flowmeter turning on. Thanks for your help!
I am currently porting my DCF77 library (you may find the source code at GitHub) from Arduino (AVR based) to Arduino Due (ARM Cortex M3).
The library requires precise 1ms timing. An obvious candidate is the use of the systicks. Conveneniently the Arduino Due is already setup for systicks with 1 kHz.
However my (AVR) DCF77 library is capable to tune the timing once it locks to DCF77. This is done by manipulating the timer reload values like so
void isr_handler() {
cumulated_phase_deviation += adjust_pp16m;
// 1 / 250 / 64000 = 1 / 16 000 000
if (cumulated_phase_deviation >= 64000) {
cumulated_phase_deviation -= 64000;
// cumulated drift exceeds 1 timer step (4 microseconds)
// drop one timer step to realign
OCR2A = 248;
} else if (cumulated_phase_deviation <= -64000) {
// cumulated drift exceeds 1 timer step (4 microseconds)
// insert one timer step to realign
cumulated_phase_deviation += 64000;
OCR2A = 250;
} else {
// 249 + 1 == 250 == 250 000 / 1000 = (16 000 000 / 64) / 1000
OCR2A = 249;
}
DCF77_Clock_Controller::process_1_kHz_tick_data(the_input_provider());
}
I want to port this to the ARM processor. In the ARM information center I found the following documentation.
Configuring SysTick
...
To configure the SysTick you need to load the SysTick Reload Value
register with the interval required between SysTick events. The timer
interrupt or COUNTFLAG bit (in the SysTick Control and Status
register) is activated on the transition from 1 to 0, therefore it
activates every n+1 clock ticks. If a period of 100 is required 99
should be written to the SysTick Reload Value register. The SysTick
Reload Value register supports values between 1 and 0x00FFFFFF.
If you want to use the SysTick to generate an event at a timed
interval, for example 1ms, you can use the SysTick Calibration Value
Register to scale your value for the Reload register. The SysTick
Calibration Value Register is a read-only register that contains the
number of pulses for a period of 10ms, in the TENMS field (bits 0 to
23). This register also has a SKEW bit (30) that is used to indicate
that the calibration for 10ms in the TENMS section is not exactly 10ms
due to small variations in clock frequency. Bit 31 is used to indicate
if the reference clock is provided.
...
Unfortunately I did not find anything on how SysTick->LOAD and SysTick->CALIB are connected. That is: if I want to throttle or accelerate systicks, do I need to manipulate the LOAD or the CALIB value? And which values do I need to put into these registers?
Searching the internet did not bring up any better hints. Maybe I am searching at the wrong places.
Is there anywhere a more detailed reference for these questions? Or maybe even some good examples?
Comparing the AtMega328 datasheet with the Cortex-M3 TRM, the standout point is that the timers work opposite ways round: on the AVR, you're loading a value into OCR2A and waiting for the timer in TCNT2 to count up to it, whereas on the M3 you load the delay value into SYST_RVR, then the system will count down from this value to 0 in SYST_CVR.
The big difference for calibration is going to be because the comparison value is fixed at 0 and you can only adjust the reload value, you might have more latency compared to adjusting the comparison value directly (assuming the counter reload happens at the same time the interrupt is generated).
The read-only value in SYST_CALIB (if indeed it even exists, being implementation-defined and optional), is merely for relating SYSTICK ticks to actual wallclock time - when first initialising the timer, you need to know the tick frequency in order to pick an appropriate reload value for your desired period, so having a register field that says "this many reference clock ticks happen in 10ms (possibly)" offers some possibility of calculating that at runtime in a portable fashion, rather than having to hard-code a value that might need changing for different devices.
In this case, however, not only does having an even-more-accurate external clock to synchronise against makes this less important, but crucially, the firmware has already configured the timer for you. Thus you can assume that whatever value is in SYST_RVR represents close-enough-to-1KHz, and work from there - in fact to simply fine-tune the 1KHz period you don't even need to know what the actual value is, just do SysTick->LOAD++ or SysTick->LOAD-- if the error gets too big in either direction.
Delving a bit deeper, the SAM3X datasheet shows that for the particular M3 implementation in that SoC, SYSTICK has a 10.5 MHz reference clock, therefore the SYST_CALIB register should give a value of 105000 ticks for 10ms. Except it doesn't, because apparently Atmel thought it would be really clever to make the unambiguously-named TENMS field give the tick count for 1ms, 10500, instead. Wonderful.
Just for the reason that others do not have to dig around like had to do - here is what I found out in addition.
In arduino-1.5.8/hardware/arduino/sam/system/CMSIS/CMSIS/Include/core_cm*.h there is code to manipulate SysTick. In particular in core_cm3.h there is a function
static __INLINE uint32_t SysTick_Config(uint32_t ticks)
{
if (ticks > SysTick_LOAD_RELOAD_Msk) return (1); /* Reload value impossible */
SysTick->LOAD = (ticks & SysTick_LOAD_RELOAD_Msk) - 1; /* set reload register */
NVIC_SetPriority (SysTick_IRQn, (1<<__NVIC_PRIO_BITS) - 1); /* set Priority for Cortex-M0 System Interrupts */
SysTick->VAL = 0; /* Load the SysTick Counter Value */
SysTick->CTRL = SysTick_CTRL_CLKSOURCE_Msk |
SysTick_CTRL_TICKINT_Msk |
SysTick_CTRL_ENABLE_Msk; /* Enable SysTick IRQ and SysTick Timer */
return (0); /* Function successful */
}
Then in arduino-1.5.8/hardware/arduino/sam/variants/arduino_due_x/variant.cpp in function init there is
// Set Systick to 1ms interval, common to all SAM3 variants
if (SysTick_Config(SystemCoreClock / 1000))
{
// Capture error
while (true);
}
Since SystemCoreClock evaluates to 84000000 it follows that this compiles like SysTick_Config(84000). I verified against a DCF77 module that SysTick_Config(84001) will slow down SysTicks while SysTick_Config(83999) will speed it up.
I'm using USART of PIC18f2455 with RS232 and having some trouble to configure it.
I'm using a 24 MHz Crystal Oscillator.
The PLL is enabled with prescaler of 6 (to set 4MHz at input) and gives a fixed 96 MHz at output.
The postscaler is set to 6 giving at end a 16MHz to Microcontroller clock.
With this clock I set the SPBRG of OpenUSART function to 25 for a Baud Rate of 9600 .
This is my USART config:
#pragma config PLLDIV = 6, CPUDIV = OSC4_PLL6, USBDIV = 2, FOSC = HSPLL_HS
OpenUSART(USART_TX_INT_ON & USART_RX_INT_OFF & USART_ASYNCH_MODE & USART_EIGHT_BIT & USART_CONT_RX & USART_BRGH_LOW, 25);
It is getting stuck at OpenUSART function...
For a 16MHz microcontroller clock change USART_BRGH_LOW, 25 to USART_BRGH_HIGH, 103 which will result in 9,615.38 baud (9600 -0.2%). Why not use CPUDIV = OSC1_PLL2 to give you a 48 MHz clock? You'd then use USART_BRGH_LOW, 77.
I am using a PIC32MX534F064L (datasheet), and trying to read several of its analog pins (marked AN0 to AN15).
With none of those pins connected to anything, I expect to read a value of zero. Instead on AN0 through AN5 I read values between 650 and 900. Only from the rest (AN6 through AN15) I get a value of zero.
When each of the pins is connected to a source, they report correctly. Each of the pins, AN0 through AN15 will report 0 for 0.0V, and 1023 for 3.3V.
I've tried sampling the values in pairs, and each separately. Whether sampled together or apart, AN0 will report non-zero values (usually around 700-800), and AN13 will report 0.
My first thought was that I somehow failed to properly set up the ADC. Here's my code:
#include <stdio.h>
#include <plib.h>
unsigned int an0;
unsigned int offset;
char buffer[100];
int main(void)
{
SYSTEMConfigPerformance(72000000L);
CloseADC10();
#define ADC_CONFIG1 ADC_MODULE_ON | ADC_FORMAT_INTG | \
ADC_CLK_AUTO | ADC_AUTO_SAMPLING_ON
#define ADC_CONFIG2 ADC_VREF_AVDD_AVSS | ADC_OFFSET_CAL_DISABLE | \
ADC_SCAN_OFF | ADC_SAMPLES_PER_INT_2 | \
ADC_ALT_BUF_ON | ADC_ALT_INPUT_ON
#define ADC_CONFIG3 ADC_CONV_CLK_INTERNAL_RC | ADC_SAMPLE_TIME_15
#define ADC_CONFIGSCAN SKIP_SCAN_ALL
#define ADC_CONFIGPORT ENABLE_AN0_ANA
SetChanADC10( ADC_CH0_NEG_SAMPLEA_NVREF | ADC_CH0_POS_SAMPLEA_AN0 );
OpenADC10( ADC_CONFIG1, ADC_CONFIG2, ADC_CONFIG3, \
ADC_CONFIGPORT, ADC_CONFIGSCAN );
EnableADC10();
while ( ! mAD1GetIntFlag() ) { }
while (1)
{
offset = 8 * ((~ReadActiveBufferADC10() & 0x01));
an0 = ReadADC10(offset);
sprintf(buffer, "AN0 = %u", an0);
}
return 0;
}
Looking in the PIC's datasheet, I noticed two things:
The pins AN0 to AN5, the ones mis-reporting non-zero values, are also CNx pins. These pins are "Change Notification" pins, that are meant to raise an interrupt when the value on the pins changes.
There is a "weak pull-up" that can be enabled on all CNx pins.
So I tried disabling the "weak pull-up" by using this line:
mCNClose();
Which disables all the CNx pins and their pull-ups. Sadly, this did not help. And when I checked the value of the CN-pull-up-register (CNPUE
What else can I try? Am I doing something wrong in my code?
Well, your expectation is wrong!
The minimum input resistance for source should be only few kilo ohms check datasheet.
If ADC pins is floating (not connected) the unpredicted value of internal parasitic current will cause that measuring value will be bigger than 0. Remember the ADC sample capacitor has only few pF capacity so floating pins can oscillate in wide voltage range also from external EM (electromagnetic) influences.
So, connect at least 1M resistors to pull down voltage on ADC pin, the resistance of pull down resistor is depended of ADC sample time. If ADC sample time is short than decrease the pull down value of resistor.
EDIT:
Check datasheet page 214 parameter AD17: Recommended Impedance of Analog Voltage Source is 5 KOhms. And AD15 say that that max. Leakage Current on ADC input pins can be +/-0.61 uA.
It's probably just noise, since the inputs are high impedance when nothing is connected. Try grounding the inputs (connect to 0V) as an experiment - the values should then be close to 0. If you need the inputs to be zero when nothing is connected then connect a pull-down resistor to each input (between input and 0V) to lower the impedance - a value of 10k ohms should do it.
Do not leave pins unconnected! The unconnected pin is essentially an antenna which could pick up voltages outside of the Vss and Vdd range. Section 2.10 of the datasheet says to not leave any pins unconnected (or if you do, configure them as outputs and drive them low.)
If you want to test your A2D, you can configure the pin as a digital output (the analog setting only overrides the digital input) and then drive it high and low to test.