I am learning STM32F407 MCU but confused with its Input Data Register. This register is 32 bits which 0-15 bits are read only and the remain bits are reserved. My question is that the register is defined with defaulf value of 0x0000XXXX in data sheet. XXXX are "undefined" in datasheet. What does really mean "undefined" term ?
Here is an example:
if (GPIOA->IDR & 0x0001)
GPIOD-ODR |= 0xF000;
So undefined register bits can cause turning the LEDS on while I do not pressing the button ?
Thanks....
Related
As I understand the term "word length" (spi_bits_per_word) in spi, defines the CS (chip select) active time.
It therefore seems that linux driver will function correctly when dealing with simple spi protocols which keeps word size constant.
But, How can we deal with spi protocols which use different spi size as part of protocol.
for example cs need to be active for sending spi word - 9 bits, and then reading spi - 8 bits or 24 bits (the length of the register read is different each time, depends on register)
How can we implement that using spi_write_then_read ?
Do we need to set bits_per_word size for the sending and then another bits_per_word for the receiving ?
Regards,
Ran
"word length" means number of bits you can send in one transaction. It doesn't defines the CS (chip select) active time. You can keep it active for whatever time you want(least is for word-length).
SPI has got some format. You cannot randomly read-write whatever number of bits you want.Most of SPI supports 4-bit, 8-bit, 16-bit and 32-bit mode. If the given mode doesn't satisfy your requirement then you need to break your requirement. For eg:- To read 24-bit data, we need to use 8-bit word-length transfer for 3 times.
Generally SPI is fullduplex means it will read at same time it will write.
I am new to vera and trying to understand the syntax. What does 4b' and 32' represent ? Is this like 4 bit and 32 bit?
I am so confused and have to work on something related to this.
Another question is what does bit [31:0] mean ? does that mean anything from bit 31 and 0 ?
Thnks
The number number format is:
[width]'[base][value]
So 4'b1001 is a 4-bit, binary value 1001 (9)
32'h0 is a 32-bit, hex value 0.
Sometimes you'll see 'd as well which is decimal.
Appended to the end of a bus, [n:m] is a part select, which means, select the bits from n to m of this bus. So [31:0] selects the lower 32 bits of a bus (or all of the bus if it's 32-bit wide).
I am using beaglebone to access digital input from specific pin using sysfs interface. And I can change the output states but not the input :(. What I did is, I have two pins pinA and pinB. pinA I made it output and pinB I made input. Connected pinA to pinB. Configured pinA as output pin by sending out to direction attribute in sysfs and pinB as input by passing in. And I changed value of PinA to 1 and it is giving 1 as output (I tested using LED). But when I read the value of PinB it is giving 0 only, even I pass 0 to value of pinA. what may be the reason ?
Thank you :)
As I understood, the steps you followed:
echo 7 > /sys/kernel/debug/omap_mux/gpmc_ad6
echo 38 > /sys/class/gpio/export
echo in > /sys/class/gpio/gpio38/direction
cat /sys/class/gpio/gpio38/value
I also did the same mistake and it took me hours, but the answer was simple: The first line starting with "echo 7" is the problem. Look at the muxing bits:
Bit 5: 1 - Input, 0 - Output
Bit 4: 1 - Pull up, 0 - Pull down
Bit 3: 1 - Pull disabled, 0 - Pull enabled
Bit 2 \
Bit 1 |- Mode
Bit 0 /
You were entering echo 7 which is --> 0 0 0111 and it means: bit 0,1 and 2 is 1, so the mode is set. No problem. However you just forgot to set whether it's an input or output. And it should be like this:
echo 0x27 > /sys/kernel/debug/omap_mux/gpmc_ad6
your bits are now: 1 0 0111 binary which is 0x27 (hex).
When you write "cat /sys/class/gpio/gpio38/value" while giving input, you can see a wonderful 1 :) I’m sure you will be very happy as much as I was :)
Also, one more thing, you are right for Analog input about 1.8V, but GPIO operates with 3.3v.
Several possible causes:
1) Did you set the IO direction of the input pin?
eg. echo "in" > /sys/class/gpio/gpioN/direction
2) (less likely) Is the GPIO pin you're using as an input multiplexed as a GPIO line and in the right direction? Most of the GPIO pins on the OMAP SoCs are multi-function. You're kernel might have set it for an alternate function.
You can check it with:
cat /sys/kernel/debug/omap_mux/board/core
Which dumps the configurations of all IO pins. The output looks like this:
OMAP4_MUX(CSI22_DY1, OMAP_PIN_INPUT | OMAP_MUX_MODE0),
/* gpio_81 */
OMAP4_MUX(CAM_SHUTTER, OMAP_PIN_OUTPUT | OMAP_MUX_MODE3),
OMAP4_MUX(CAM_STROBE, OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
/* gpio_83 */
In this case, CAM_SHUTTER is set an output, and routed as to the GPIO module (OMAP_MUX_MODE3)
[Caveat: this is from my OMAP4 board - without having the OMAP3 data sheet to hand - there will be a fair amount of similarity]
You can't change this through sysfs - instead you'll need to modify either your kernel (or possibly boot-loader if the kernel uses the configuration it set up).
In the board-file for your system - which I think in your case will be in <linux_source_root>/arch/arm/mach-omap2/board-omap3beagle.c - you'll find a initialiser for the MUX table. You will need the board's schematics, the kernel source tree and the SoC data sheet to get between the primary function name of the pin (in my example above CAM_SHUTTER) and a GPIO number.
3) I was a bit confused by even I pass 0 to value of pinA - I wonder whether you meant that? This does however point to another thing to watch for - there is the programmable pull-up or -down on each IO pin. These are set with the MUX settings. There may conceivably be an external one as well - again you'll need the schematics to be sure.
Yes. The internal pull up and down is configured in the same register as the mux-mode - so it might be that you can configure this in the same way you're setting the mux-mode. Get the AM335x TRM (for OMAP4 the chapter is called Control Module).
In terns of the kernel, look in <linux_source_root>/arch/arm/mach-omap2/mux.h where a bunch of macros are defined
As an example for use I have in my board file:
/* PIC -> OMAP4 interrupt line 2 - GPIO81 */
OMAP4_MUX(CAM_SHUTTER, OMAP_MUX_MODE3 | OMAP_PIN_INPUT_PULLUP),
and
OMAP4_MUX(GPMC_AD11, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
From memory you get a choice of either a pull-up or pull-down but can't select neither.
a bit exotic question :D
I'm programming c++ in ubuntu 10 and i need to code a mdb(multi drop bus) protocol which uses 9 data bits in serial communication (YES 9 data bits :D)
Some drivers do support 9 data bits on some uart chips, but mostly they do not.
To explain briefly:
mdb uses 8 data bits for data and 9th data bit for mode set.
So when master sends first BYTE it sets mode=9thbit to 1 which means that all devices on the bus are interrupted and are looking for this first byte that holds the address of a device.
If the listening device (one of many) finds its address in this first byte it knows that the following bytes will be data bytes for it. data bytes have bit 9 = mode bit set to 0
example in bits: 000001011 000000010 000000100 000000110 (1stbyte address and 3 data bytes)
The return situation from slave -> master mode bit is used for end of transmission.
So the master reads from serial so long until it finds a 9bit packet that has 9th bit = 1 usualy the last 9bit sequence is a chk byte + mode = 1
So finally my question:
I know how to user CMPAR flag in termios to use parity bit for mode bit eg. setting it to either MARK(1) or SPACE(0)
example FOR ALL that don't know how:
First check if this is defined if not probably no support in termios:
# define CMSPAR 010000000000 /* mark or space (stick) parity */
And the code for sending with mark or space parity eg. simulating 9th data bit
struct termios tio;
bzero(&tio, sizeof(tio));
tcgetattr(portFileDescriptor, &tio);
if(useMarkParity)
{
// Send with mark parity
tio.c_cflag |= PARENB | CMSPAR | PARODD;
tcsetattr(portFileDescriptor, TCSADRAIN, &tio);
}
else
{
// Send with space parity
tio.c_cflag |= PARENB | CMSPAR;
tio.c_cflag &= ~PARODD;
tcsetattr(portFileDescriptor, TCSADRAIN, &tio);
}
write(portFileDescriptor,DATA, DATALEN);
Now what i don't know HOW to set the parity checking on receive, i have tried almost all combinations and i cannot get that error parity byte sequence.
Can anyone help me how to set parity checking on receive that it does not ignore parity and does not strip bytes but it adds DEL before "bad" received byte:
As it says in the POSIX Serial help
INPCK and PARMRK If IGNPAR is enabled, a NUL character (000 octal) is
sent to your program before every character with a parity error.
Otherwise, a DEL (177 octal) and NUL character is sent along with
the bad character.
So how to correctly set PARMRK AND INPCK that it will detect mode bit = 1 as parity bit error and insert DEL 177 octal in the return stream.
Thank you :D
It sounds to me like you want to set space parity on the receiver and don't enable IGNPAR. That way when a byte with mark parity is received it should generate the parity error with the DEL.
I was having the same problem running in a Linux guest OS. Running the same program on another machine with Linux as the host OS works. I suspect that the virtual serial port does not pass on the parity error. See PARMRK termios behavior not working on Linux. It is still possible that the VM is not the problem because it was a completely different computer. I was able to get parity errors using Realterm in Windows (the host OS on the computer where Linux was the guest), however.
Also, note the code in n_tty.c shows it inserts '\377' '\0' rather than '\177' '\0'. This was also verified on the working configuration.
RS-232 communication sometimes uses 9-bit bytes. This can be used to communicate with multiple microcontrollers on a bus where 8 bits are data and the extra bit indicates an address byte (rather than data). Inactive controllers only generate an interrupt for address bytes.
Can a Linux program send and receive 9-bit bytes over a serial device? How?
The termios system does not directly support 9 bit operation but it can be emulated on some systems by playing tricks with the CMSPAR flag. It is undocumented and my not appear in all implementations.
Here is a link to a detailed write-up on how 9-bit emulation is done:
http://www.lothosoft.ch/thomas/libmip/markspaceparity.php
9-bit data is a standard part of RS-485 and used in multidrop applications. Hardware based on 16C950 devices may support 9-bits, but only if the UART is used in its 950 mode (rather than the more common 450/550 modes used for RS-232).
A description of the 16C950 may be found here.
This page summarizes Linux RS-485 support, which is baked into more recent kernels (>=3.2 rc3).
9-bit data framing is possible even if a real world UARTs doesn't.
Found one library that also does it under Windows and Linux.
See http://adontec.com/9-bit-serial-communication.htm
basically what he wants is to output data from a linux box, then send it on let's say a 2 wire bus with a bunch of max232 ic's -> some microcontroller with uart or software rs232 implementation
one can leave the individual max232 level converter's away as long as there are no voltage potency issues between the individual microcontrollers (on the same pcb, for example, rather than in different buildings ;) up until the maximum output (ttl) load of the max232 (or clones, or a resistor and invertor/transistor) ic.
can't find linux termios settings for MARK or SPACE parity (Which i'm sure the hardware uarts actually do support, just not linux tty implementation), so we shall just hackzor the actual parity generation a bit.
8 data bits, 2 stop bits is the same length as 8 databits, 1 parity bit, 1 stop bit. (where the first stopbit is a logic 1, negative line voltage).
one would then use the 9th bit as an indicator that the other 8 bits are the address of the individual or group of microcontrollers, which then take the next bytes as some sort of command, or data, as well, they are 'addressed'.
this provides for an 8 bit transparant, although one way traffic, means to address 'a lot of things' (256 different (groups of) things, actually ;) on the same bus. it's one way, for when one would want to do 2 way, you'd need 2 wire pairs, or modulate at multiple frequencies, or implement colission detection and the whole lot of that.
PIC microcontrollers can do 9 bit serial communication with ehm 'some trickery' (the 9th bit is actually in another register ;)
now... considering the fact that on linux and the likes it is not -that- simple...
have you considered simply turning parity on for the 'address word' (the one in which you need 9 bits ;) and then either setting it to odd or even, calculate it so that the right one is chosen to make the 9th (parity) bit '1' with parity on and 8 bit 'data', then turn parity back off and turn 2 stop bits on. (which still keeps a 9 bit word length in as far as your microcontroller is concerned ;)... it's a long time ago but as far as i recall stop bits are just as long as data bits in the timing of things.
this should work on anything that can do 8 bit output, with parity, and with 2 stop bits. which includes pc hardware and linux. (and dos etc)
pc hardware also has options to just turn 'parity' on or off for all words (Without actually calculating it) if i recall correctly from 'back in the days'
furthermore, the 9th bit the pic datasheet speaks about, actually IS the parity bit as in RS-232 specifications. just that you're free to turn it off or on. (on PIC's anyway - in linux it's a bit more complicated than that)
(nothing a few termios settings on linux won't solve i think... just turn it on and off then... we've made that stuff do weirder things ;)
a pic microcontroller actually does exactly the same, just that it's not presented like 'what it actually is' in the datasheet. they actually call it 'the 9th bit' and things like that. on pc's and therefore on linux it works pretty much the same way tho.
anyway if this thing should work 'both ways' then good luck wiring it with 2 pairs or figuring out some way to do collission detection, which is hell a lot more problematic than getting 9 bits out.
either way it's not much more than an overrated shift register. if the uart on the pc doesn't want to do it (which i doubt), just abuse the DTR pin to just shift out the data by hand, or abuse the printer port to do the same, or hook up a shift register to the printer port... but with the parity trick it should work fine anyway.
#include<termios.h>
#include<stdio.h>
#include<sys/types.h>
#include<sys/stat.h>
#include<fcntl.h>
#include<unistd.h>
#include<stdint.h>
#include<string.h>
#include<stdlib.h>
struct termios com1pr;
int com1fd;
void bit9oneven(int fd){
cfmakeraw(&com1pr);
com1pr.c_iflag=IGNPAR;
com1pr.c_cflag=CS8|CREAD|CLOCAL|PARENB;
cfsetispeed(&com1pr,B300);
cfsetospeed(&com1pr,B300);
tcsetattr(fd,TCSANOW,&com1pr);
};//bit9even
void bit9onodd(int fd){
cfmakeraw(&com1pr);
com1pr.c_iflag=IGNPAR;
com1pr.c_cflag=CS8|CREAD|CLOCAL|PARENB|PARODD;
cfsetispeed(&com1pr,B300);
cfsetospeed(&com1pr,B300);
tcsetattr(fd,TCSANOW,&com1pr);
};//bit9odd
void bit9off(int fd){
cfmakeraw(&com1pr);
com1pr.c_iflag=IGNPAR;
com1pr.c_cflag=CS8|CREAD|CLOCAL|CSTOPB;
cfsetispeed(&com1pr,B300);
cfsetospeed(&com1pr,B300);
tcsetattr(fd,TCSANOW,&com1pr);
};//bit9off
void initrs232(){
com1fd=open("/dev/ttyUSB0",O_RDWR|O_SYNC|O_NOCTTY);
if(com1fd>=0){
tcflush(com1fd,TCIOFLUSH);
}else{printf("FAILED TO INITIALIZE\n");exit(1);};
};//initrs232
void sendaddress(unsigned char x){
unsigned char n;
unsigned char t=0;
for(n=0;n<8;n++)if(x&2^n)t++;
if(t&1)bit9oneven(com1fd);
if(!(t&1))bit9onodd(com1fd);
write(com1fd,&x,1);
};
void main(){
unsigned char datatosend=0x00; //bogus data byte to send
initrs232();
while(1){
bit9oneven(com1fd);
while(1)write(com1fd,&datatosend,1);
//sendaddress(223); // address microcontroller at address 223;
//write(com1fd,&datatosend,1); // send an a
//sendaddress(128); // address microcontroller at address 128;
//write(com1fd,&datatosend,1); //send an a
}
//close(com1fd);
};
somewhat works.. maybe some things the wrong way around but it does send 9 bits. (CSTOPB sets 2 stopbits, meaning that on 8 bit transparant data the 9th bit = 1, in addressing mode the 9th bit = 0 ;)
also take note that the actual rs232 line voltage levels are the other way around from what your software 'reads' (which is the same as the 'inverted' 5v ttl levels your pic microcontroller gets from the transistor or inverter or max232 clone ic). (-19v or -10v (pc) for logic 1, +19/+10 for logic 0), stop bits are negative voltage, like a 1, and the same lenght.
bits go out 0-7 (and in this case: 8 ;)... so start bit -> 0 ,1,2,3,4,5,6,7,
it's a bit hacky but it seems to work on the scope.
Can a Linux program send and receive 9-bit bytes over a serial device?
The standard UART hardware (8251 etc.) doesn't support 9-bit-data modes.
I also made complete demo for 9-bit UART emulation (based on even/odd parity). You can find it here.
All sources available on git.
You can easily adapt it for your device. Hope you like it.