I have a custom board with device LPC1768. While every other functionalities (such as LCD on SPI, Ethernet, I2C EEPROM, etc.) are OK,
for some reason, while I can turn ON and OFF LEDs on the GPIO2 but I can't do the same for the pins on the GPIO1. Maybe I shouldn't blame whole GPIO1 (or myself) but at least the part I try to use.
If I connect a button on one of the the GPIO1 pins (with internal pull-ups and as an OUTPUT)
I can read the button inputs as it should be.
Here is the definition part as per the user manual;
#define FIO_BASE_ADDR (0x2009C000)
#define FIO1CLR (*(volatile unsigned int *)(FIO_BASE_ADDR + 0x3C))
#define FIO2CLR (*(volatile unsigned int *)(FIO_BASE_ADDR + 0x5C))
#define FIO1SET (*(volatile unsigned int *)(FIO_BASE_ADDR + 0x38))
#define FIO2SET (*(volatile unsigned int *)(FIO_BASE_ADDR + 0x58))
While a LED on the pin P2.5 turns ON and OFF as it should be;
FIO2SET = (1uL << 5); // P2.5
FIO2CLR = (1uL << 5); // P2.5
A LED on P1.18 doesn't turn ON;
FIO1SET = (1uL << 18); // P1.18
In order to test all the LEDs connected to the GPIO1 pins, I wrote two lines of code using LPC17xx.h and then proofed that it works, all the LEDs are turning ON and OFF accordingly.
LPC_GPIO1->FIOSET = 0xffffffff;
LPC_GPIO1->FIOCLR = 0xffffffff;
Any input highly appreciated.
I have this code:
void GPIO_InitPortPin(uint8* PortControl, uint8 Pin, uint8 PinDir){
*PortControl &= (~(1U << Pin));
*PortControl |= (PinDir << Pin);
}
If the PortControl register is 11111111, the first line should clear the bit of whatever the corresponding Pin is, but unexpectedly it clears all the register.
My Client Function is: GPIO_InitPortPin(&TRISB, GPIO_PIN_0, GPIO_IN);
GPIO_PIN_0 and GPIO_IN are macros defined as follows:
#define GPIO_PIN_0 (0)
#define GPIO_PIN_1 (1)
...
#define GPIO_PIN_7 (7)
#define GPIO_OUT (0)
#define GPIO_IN (1)
So, I tried to cast Pin to sint8: *PortControl &= (~(1U << (sint8) Pin));
and it worked. Also, I tried to hard-code the Pin as 1 and it worked fine. I know the problem is that Pin is uint8 or specifically to be unsigned since
*PortControl &= (~(1U << 1));
also worked fine.
My Question is: why the right operand type affects the shifting operation, although I've red otherwise before(That RHS doesn't affect operation)?
Iam using SDCC compiler.
Edit : I've tested the function without casting on gcc and it worked as expected.
I am reviewing the open source AMD GPU drivers for Linux. I noticed something I haven't seen before, and I would like to know the purpose. On line 1441 of the sid.h file, there are a series of defines that are integers being bitshifted left by 0. Wouldn't this just result in the original integer being operated on?
Here is an excerpt and a link to the head
#define VGT_EVENT_INITIATOR 0xA2A4
#define SAMPLE_STREAMOUTSTATS1 (1 << 0)
#define SAMPLE_STREAMOUTSTATS2 (2 << 0)
#define SAMPLE_STREAMOUTSTATS3 (3 << 0)
https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/amdgpu/sid.h#L1441
Also, I am learning to access the performance counter registers of AMD GPUs in order to calculate the GPU load. Any tips on that would be appreciated as well.
Things like that could be done just for the sake of consistency (not necessarily applicable to your specific case). For example, I can describe a set of single-bit flags as
#define FLAG_1 0x01
#define FLAG_2 0x02
#define FLAG_3 0x04
#define FLAG_4 0x08
or as
#define FLAG_1 (1u << 0)
#define FLAG_2 (1u << 1)
#define FLAG_3 (1u << 2)
#define FLAG_4 (1u << 3)
In the first line of the latter approach I did not have to shift by 0. But it just looks more consistent that way and emphasizes the fact that FLAG_1 has the same nature as the rest of the flags. And 0 acts as a placeholder for a different value, if I some day decide to change it.
You can actually see exactly that in the linked code with shift by 0 in the definitions of DYN_OR_EN and DYN_RR_EN macros.
The approach can be extended to multi-bit fields within a word, like in the following (contrived) example
// Bits 0-3 - lower counter, bits 4-7 - upper counter
#define LOWER_0 (0u << 0)
#define LOWER_1 (1u << 0)
#define LOWER_2 (2u << 0)
#define LOWER_3 (3u << 0)
#define UPPER_0 (0u << 4)
#define UPPER_1 (1u << 4)
#define UPPER_2 (2u << 4)
#define UPPER_3 (3u << 4)
unsigned packed_counters = LOWER_2 + UPPER_3; /* or `LOWER_2 | UPPER_3` */
Again, shifts by 0 bits are present purely for visual consistency. As well as shifts of 0 values.
You can actually see exactly that in the linked code with shift by 0 in the definitions of LC_XMIT_N_FTS and LC_XMIT_N_FTS_MASK macros.
I am working on a embedded project trying to learn some of the ins and outs of programming an embedded board. As one might have guessed, this involves writing code in C. I am not having too much trouble getting the grasp of setting things up correctly (in terms of ports/pins/etc..) but I am looking to abstract some of my code to make it a bit more readable.
For example, the following code turns on a Green LED that is on the board:
// Required CPU Speed Define
#define F_CPU 16000000
// Include the necissary library header files
#include <avr/io.h>
int main() {
DDRD |= (1 << DDD5);
PORTD |= (1 << PD5);
PORTD ^= (1 << PD5);
for(;;) { }
}
On the other hand, I can #define the names of the ports so they are more clear, but that doesn't seem like the ideal solution (and it's unfortunately the method that I am currently using).
I would like to abstract some of the setting/functionality of enabling the on board leds (which I eventually hope to extend to other concepts such as timers/interrupts/etc..).
How do I use Struct/Pointers to properly abstract this?
I am currently trying the following method, but it is falling flat, and the LED is failing to turn on:
OnBoardLED.h
typedef struct {
unsigned int dataDirectionRegister;
unsigned int portNumber;
unsigned int pinNumber;
} OnBoardLED;
void setDataDirectionRegister(OnBoardLED* led, unsigned int DDR);
void setPortNumber(OnBoardLED* led, unsigned int port);
void setPinNumber(OnBoardLED* led, unsigned int pin);
void turnOn(OnBoardLED* led);
void turnOff(OnBoardLED* led);
and
main.c
#include "inc/OnBoardLED.h"
int main(void) {
OnBoardLED greenLED;
setDataDirectionRegister(&greenLED, DDRD);
setPortNumber(&greenLED, PORTD);
setPinNumber(&greenLED, 5);
turnOn(&greenLED);
for(;;) { }
}
I know that I should be using pointers in this instance, specifically for the Data Direction Registers and the Port (so that I am properly referencing that memory location), but I do not know how to properly reference them.
What am I missing here?
Note: If needed I will post my current implementations of each function, defined in OnBoardLED.c
Edit:
OnBoardLED.c
#include "inc/OnBoardLED.h"
void setDataDirectionRegister(OnBoardLED* led, unsigned int DDR) {
led->dataDirectionRegister = DDR;
}
void setPortNumber(OnBoardLED* led, unsigned int port) {
led->portNumber = port;
}
void setPinNumber(OnBoardLED* led, unsigned int pin) {
led->pinNumber = pin;
}
void turnOn(OnBoardLED* led) {
led->dataDirectionRegister |= (1 << led->pinNumber);
led->portNumber |= (1 << led->pinNumber);
led->portNumber ^= (1 << led->pinNumber);
}
I'm not too much practical with AVR toolchain but from what I remember and understand things like DDRD are macro which map addresses from address space to register of the CPU.
So by inspecting the source code you obtain something like:
#define __SFR_OFFSET 0
#define _MMIO_BYTE(mem_addr) (*(volatile uint8_t *)(mem_addr))
#define _SFR_IO8(io_addr) _MMIO_BYTE((io_addr) + __SFR_OFFSET)
#define DDRD _SFR_IO8(0x0A)
This means that replacing DDRD yields something like:
*(volatile uint8_t*)((0x0A) + 0)
which is a smart macro, when used as a left-hand operand allows you to store a value at that memory address, when used as a right-hand operand you can read the value of the register. But this is still a macro and macros can hide evil details like in this situation.
What happens is that your code is
led->dataDirectionRegister = *(volatile uint8_t*)((0x0A) + 0);
led->dataDirectionRegister |= (1 << led->pinNumber);
so what you are doing is just saving the value of the data direction register into the struct member and then overwrite it with the value you would like to save into the register. So nothing basically happens.
What you need is to save the address of the data direction register to be able to dereference it later when calling the turnOn method. This is easily accomplished by having a member declared as
volatile uint8_t* dataDirectionRegister;
So that you can do
void setDataDirectionRegister(OnBoardLED* led, volatile uint8_t* DDR) {
led->dataDirectionRegister = DDR;
}
and invoke it as setDataDirectionRegister(&led, &DDRD);. Notice the & operator used to obtain the address of the memory location of the register.
But now you have an address so in your turnOn method you must dereference the variable to store data into it:
void turnOn(OnBoardLED* led) {
*led->dataDirectionRegister |= (1 << led->pinNumber);
...
So let's make a concrete example to show you the problem and how to fix it:
#include <stdio.h>
#include <stdint.h>
#include <string.h>
#define __SFR_OFFSET 0
#define _MMIO_BYTE(mem_addr) (*(volatile uint8_t *)(&buffer[0] + mem_addr))
#define _SFR_IO8(io_addr) _MMIO_BYTE((io_addr) + __SFR_OFFSET)
#define DDRD _SFR_IO8(0x0A)
uint8_t buffer[256];
int main(void) {
memset(&buffer[0], 0, 256);
DDRD = 0x40;
printf("value: %x\n", (int)DDRD);
*(volatile uint8_t*)(&buffer[0] + (0x0A + 0)) = 0x41;
printf("value: %x\n", (int)DDRD);
// now let's do what you are doing in your struct
unsigned int dataDirectionRegister = DDRD; // value of register is copied into variable
dataDirectionRegister = 0x80; // variable is changed but not real register
printf("register: %x, variable: %x\n", (int)DDRD, dataDirectionRegister);
// you must save an address to do what you need
volatile uint8_t* realDataDirectionRegister = &DDRD;
*realDataDirectionRegister = 0x80;
printf("register: %x, variable: %x\n", (int)DDRD, (int)*realDataDirectionRegister);
return 0;
}
Mind that I used a buffer as my fake memory space, since you don't have a flat memory model free to use like in a x86 architecture like you have in a microcontroller.
I am currently working on setting up a framework in C for usage between several microcontrollers.
The framework has to carry all device specific code, so the application only contains the abstract usage of peripherals (like SerialPort_Read, write, SetBaudRate, etc etc.)
One of the things I am struggling with to find a solution for in C are the I/O pin map. I've seen projects (like the very very popular Arduino) where the pin map is putten in a LUT (look up table) which is used during runtime. However, this LUT will never be modified during runtime, so there is no use to have this in the memory.
For example, this function resolves some bit indexes and registers from some 'const uint' tables, and either sets or clears a bit:
void pinMode(uint8_t pin, uint8_t mode)
{
uint8_t bit = digitalPinToBitMask(pin);
uint8_t port = digitalPinToPort(pin);
volatile uint8_t *reg;
if (port == NOT_A_PIN) return;
// JWS: can I let the optimizer do this?
reg = portModeRegister(port);
if (mode == INPUT) {
uint8_t oldSREG = SREG;
cli();
*reg &= ~bit;
SREG = oldSREG;
} else {
uint8_t oldSREG = SREG;
cli();
*reg |= bit;
SREG = oldSREG;
}
}
Because this is actual C code running on the controller it's draining effiency and speed. I'd rather define some sort of macro that does the same thing, but is already resolved during compilation to a 'one-liner' that can be compiled much more efficiently:
GPIO_Write(PORTA, 5, 1); // Write '1' to pin 5 on PORTA
> LATA |= 1<<5; // Sets bit 5 high
GPIO_Tris(PORTA, 4, OUTPUT); // Set pin 4 on PORTA to output
> PORTA &= ~(1<<4); // sets pin 4 as output I/O type
Does anyone know if it's possible (and how) to define and use a look-up table with a macro in C?
At this moment I am using the MicroChip C30 compiler, which I believe is based in GCC. It's supposed to be portable between different compilers, including MicroChip C18, C32 and in further also ARM and AVR.
For your specific example, something along these lines will work:
#define WRITE_PORTA LATA
#define GPIO_Write(port, pin, value) \
(value ? WRITE_##port |= (1U << (pin)) \
: WRITE_##port &= ~(1U << (pin)))
#define INPUT 0
#define OUTPUT 1
#define GPIO_Tris(port, pin, direction) \
((direction) == INPUT ? port |= (1U << (pin)) \
: port &= ~(1U << (pin)))
You'll have to make sure to define LATA and PORTA in a way the system will understand - in particular trying to overload its meaning the way it seems to be in your example might be hard to resolve.
Which processor or microcontroller are you targeting?
You might be underestimating the usefulness of the LUT.
For many processors, the LUT does more than map a 'logical' pin number to a single value, the 'physical' pin number. The LUT maps the 'logical' pin number to several pieces of information.
In general, the 'logical' pin is mapped to the port address of the appropriate read/input or write/output register, and the bit offset within the read or write register. So the pin value, on many MCU's, is really mapped to a struct. It might also include a mapping to the data direction register and fields within it, as well as registers which set the state of pull-up or pull-down resistors.
For example, I have code to multiplex a 8x8 display. At run-time, I need to use pinMode to turn a pin from an output to a high impedance input, and so that information needs to be encoded somehow.
It is possible to do this sort of thing, with some ingenuity, on some MCU's.
ARM MCU's (and I believe 8051, though I've never used one) using 'bit band addressing' http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0179b/CHDJHIDF.html
This assigns a unique memory address for each port pin, and fixed offsets can derive the address of the pin for the other data register, and other functions. This is not magic, the code encodes the information that is often stored in the LUT.
For other MCU's, they really do need both port and bit position, so it is two values for each pin number.
If you are willing to ditch the idea of using integers for pins, and instead use names, like P0, P1, then you could initialise a lot of const struct's, one per pin name, and your functions would take the const struct values. The struct would contain the initialised port and bit offset or bit mask values. The compiler may be able to optimise for speed. This would avoid having a LUT, but would still use similar amounts of space for pins that are used. You might be able to arrange it so that unused pins would not need to be included in the code, and hence saving space.
Edit: If you are willing to use C++, I'd suggest C++ templates which can give a much better solution than macros. They can be type safe, and are often easier to debug (if you have hardware debugging, e.g. JTAG and gdb)
Consider the following macro:
#define write(port, pin, value) do { \
if (value) \
LAT##port |= 1 << pin; \
else \
LAT##port &= ~(1 << pin); \
} while (0)
Usage:
write(A, 3, 1); // compiles to LATA |= 1 << 3;
write(B, 2, 0); // compiles to LATB &= ~(1 << 2);
Is that the kind of thing you were after?
I've seen it done (https://github.com/triffid/Teacup_Firmware/blob/Gen7/arduino.h) with a couple macros:
/// Read a pin
#define _READ(IO) (IO ## _RPORT & MASK(IO ## _PIN))
/// write to a pin
#define _WRITE(IO, v) do { if (v) { IO ## _WPORT |= MASK(IO ## _PIN); } else { IO ## _WPORT &= ~MASK(IO ## _PIN); }; } while (0)
/// set pin as input
#define _SET_INPUT(IO) do { IO ## _DDR &= ~MASK(IO ## _PIN); } while (0)
/// set pin as output
#define _SET_OUTPUT(IO) do { IO ## _DDR |= MASK(IO ## _PIN); } while (0)
// why double up on these macros? see http://gcc.gnu.org/onlinedocs/cpp/Stringification.html
/// Read a pin wrapper
#define READ(IO) _READ(IO)
/// Write to a pin wrapper
#define WRITE(IO, v) _WRITE(IO, v)
/// set pin as input wrapper
#define SET_INPUT(IO) _SET_INPUT(IO)
/// set pin as output wrapper
#define SET_OUTPUT(IO) _SET_OUTPUT(IO)
with:
#define DIO0_PIN PIND0
#define DIO0_RPORT PIND
#define DIO0_WPORT PORTD
#define DIO0_PWM &OCR0B
#define DIO0_DDR DDRD
#define DIO1_PIN PIND1
#define DIO1_RPORT PIND
#define DIO1_WPORT PORTD
#define DIO1_PWM &OCR2B
#define DIO1_DDR DDRD
...
You could modify the macros to take straight integers rather than DIOn