I am using the intel XDK for the first time and I am trying to get a reading from this SPI ADC ADS7951SRGER 12 Bit Analog to Digital Converter 8 Input 1 SAR 24-VQFN (4x4) http://www.ti.com/lit/ds/symlink/ads7950.pdf
its connected like so
SPI_2_RXD -> MISO
SPI_2_TXD -> MOSI
SPI_2_CLK -> SCLK
SPI_2_FS0 -> ADC_CS
I have never used SPI before, I am very lost. I've been searching for 24 hours now and I'm not much closer to understanding what I'm supposed to do here.
here is the current hail mary code I'm trying. all I get back is ffffffff
var x = new m.Spi(0);
x.bitPerWord=12;
x.frequency = 20;
var buf = new Buffer(4);
buf[0] = char('0x0b');
buf[1] = char('0x11');
buf[2] = char('0x11');
buf[3] = char('0x11');
var buf2 = x.write(buf);
console.log("Sent: " + buf.toString('hex') + ". Received: " + buf2.toString('hex'));
Any help is appreciated
In the end, I had to pull the CS (SPI_2_FS0 -> ADC_CS) manually, pulling low before each write/read then high again.
Related
I'm sending bits as LED blinks from one Pi Pico, and using another Pico to receive voltage from a photodiode and read the bits.
When sending/receiving from the same PiPico, it works accurately at 60us a bit. However, when sending from one pico and receiving from a second pico, I can only send/receive bits accurately at 0.1s a bit. If I move to sending/receiving at 0.01s, I start losing information. This leads me to believe my issue is with the clocks or sampling rates on the two pipicos, that they are slightly different.
Is there a way to synchronize two pipico clocks using Thonny/Micropython?
Code for Pico #1 sending blinks/bits:
led=Pin(13,Pin.OUT) #Led to blink
SaqVoltage = machine.ADC(28) #receive an input signal, when over a certain voltage, send the time using bits
#Ommitted code here to grab first low voltage values from SaqVoltage signal and use to determine if there is a high voltage received, when high voltage is received, send "hi" in led bits
#More omitted calibration code here for led/photodiode
hi = "0110100001101001"
while True:
SaqVoltage_value = SaqVoltage.read_u16()*3.3 / 65536 #read input signal to see if high voltage is sent
finalBitString = ""
if SaqVoltage_value > saQCutOff: #high voltage found, send "hi" sequence
finalBitString = #hi plus some start/stop sequences
for i in range (0, len(finalBitString)):
if finalBitString[i]=="1":
led(1)
elif finalBitString[i]=="0":
led(0)
utime.sleep(.01)
Code for Pico#2 receiving bits:
SaqDiode = machine.ADC(28) #read photodiode
#ommitted code here to calibrate leds/photodiodes
startSeqSaq = []
wordBits=[]
while True:
utime.sleep(.01) #sample diode every 0.01 seconds
SaqDiode_value = SaqDiode.read_u16()*3.3 / 65536
if (saqDiodeHi - saqCutOff <= SaqDiode_value): #read saq diode and determine 1 or 0
bit=1
elif (SaqDiode_value <= saqDiodeLo + saqCutOff):
bit=0
if len(startSeqSaq)==10: #record last 10 received bits to check if start sequence
startSeqSaq.pop(0)
startSeqSaq.append(bit)
elif len(startSeqSaq)<10:
startSeqSaq.append(bit)
if startSeqSaq == startSeq: #found start sequence, start reading bits
while True:
utime.sleep(.01)
SaqDiode_value = SaqDiode.read_u16()*3.3 / 65536
if (saqDiodeHi - saqCutOff <= SaqDiode_value):
bit=1
wordBits.append(bit)
elif (SaqDiode_value < saqDiodeLo + saqCutOff):
bit=0
wordBits.append(bit)
if len(wordBits)>10: #check for stop sequence
last14=wordBits[-10:]
else:
last14 = []
if last14==endSeq:
char = frombits(wordBits[:-10])
wordBits=[]
print("Function Generator Reset Signal Time in ms from Start: ", char)
break
I'm having trouble reading and writing to my Adafruit LSM6DSOX IMU from my Raspberry Pi 4 running Ubuntu 20.04. I need to do it via SPI since I require the bandwidth, but I can only seem to read the WHO_AM_I register successfully. Reading/writing to any other register only returns 0x00. I have verified that I can read data off the IMU from an Arduino via SPI, but if I try to read a register other than 0x0F (the IMU_ID) I get 0x0 as a response. Any insight/ideas what could be causing this would be greatly appreciated!
EDIT: It turns out I can read the following registers:
0x0f : 0x6c
0x13 : 0x1c
0x33 : 0x1c
0x53 : 0x1c
0x73 : 0x1c
These are all random registers however, and the value 0x1C doesn't seem to correspond with anything.
This is my main.py:
import LSM6DSOX
def main():
imu=LSM6DSOX.LSM6DSOX()
imu.initSPI()
whoamI=imu.read_reg(0x0F)
while(whoamI != imu.LSM6DSOX_ID):
imu.ms_sleep(200)
print('searching for IMU')
whoamI=imu.get_id()
print(hex(whoamI))
print('found lsm6dsox IMU')
imu.spi.close()
imu.spi = None
if __name__=="__main__":
main()
This is an excerpt from my LSM6DSOX.py:
def initSPI(self):
# Setup communication SPI
self.spi = spidev.SpiDev()
self.spi.open(0, 0)
self.spi.mode=0b11 #mode 3, (mode 0 is also fine)
self.spi.max_speed_hz = 500000
return self.spi
def read_reg(self, reg, len=1):
# Set up message
buf = bytearray(len+1)
buf[0] = 0b10000000 | reg # MSB bit must be 1 to indicate a read operation. this is OR'd with the register address you want to read
resp =self.spi.xfer2(buf) #send (and recieve) data to the imu
if len==1:
return resp[1]
else:
return resp[1:] #display recieved data
def write_reg(self, reg, data, len=1):
# Set up message
buf = bytearray(len+1)
buf[0] = 0b00000000 | reg # MSB bit must be 0 to indicate a read operation. this is OR'd with the register address you want to read
buf[1:] =bytes(data)
resp =self.spi.xfer2(buf) #send (and recieve) data to the imu
return resp[1:] #display recieved data
I'm trying to understand how to interface a TFT screen module with an STM32F4 chip on a custom PCB.
Here is the module and its basic info.
To write commands and data to the screen, the ILI9481 driver on the screen module uses the Display Bus Interface (DBI), where data is sent over 8 or 16 bits through data wires.
Looking at library examples, I understand (and please correct me, if I am wrong), that in order to send a command of one byte, it simply sets the digital pins of the chip high or low, depending on the command. For example, command 0x2 in 8bit communication would be 00000010, where 0 would be the digital low on the chips GPIO pin and 1 would be digital high, meaning 1 of 8 wires are active (logical high). I Hope, I understand this correctly.
Now as I looked over examples, usually these digital pins are on the same GPIO port. And if I understand correctly, GPIO ports have a register, called BSRR, where you can manipulate the logical levels of the pins of the GPIO port. If the data pins are all on the same GPIO port, I assume this would work (from the example, where c is the command byte):
void STM32_TFT_8bit::write8(uint8_t c) {
// BRR or BSRR avoid read, mask write cycle time
// BSRR is 32 bits wide. 1's in the most significant 16 bits signify pins to reset (clear)
// 1's in least significant 16 bits signify pins to set high. 0's mean 'do nothing'
TFT_DATA->regs->BSRR = ((~c)<<16) | (c); //Set pins to the 8 bit number
WR_STROBE;
}
However, on my PCB board, the data pins of the screen module are separated on different ports.
So, my question is, how would I do the same thing, send a command while manipulating the logical levels? I assume, that I could write set/reset my pins one by one, depending on the command, but how would it look with the BSRR registers?
If my data pins are as follows:
D0 -> PC12
D1 -> PC11
D2 -> PC10
D4 -> PA12
D5 -> PA11
D6 -> PA10
D7 -> PA9
Would a command of 0x9D (0b10011101) through the registers would look something like this? :
GPIOA->regs->BSRR = 0b0001101000000000; // A port: turn on PA9, PA11, PA12
GPIOC->regs->BSRR = 0b0001010000000000; // C port: turn on PC10 and PC12
how would it look with the BSRR registers?
A bitmask can be applied to the value that is written to the BSRR, for example like this:
/* set/reset selected GPIO output pins, ignore the rest */
static inline void _gpio_write(GPIO_TypeDef* GPIOx, uint16_t state, uint16_t mask)
{
GPIOx->BSRR = ((uint32_t)(~state & mask) << 16) | (state & mask);
}
The data bits need to be rearranged before writing them to the GPIO output registers, for example like this:
#define BITS(w,b) (((w) & (1 << (b))) >> (b))
/* write a data/command byte to the data bus DB[7:0] of custom ILI9481 board
used pin assignment: D0 -> PC12, D1 -> PC11, D2 -> PC10, (D3 -> PC1) (?)
D4 -> PA12, D5 -> PA11, D6 -> PA10, D7 -> PA9 */
static void _write_data_to_pins(uint8_t data)
{
const uint16_t mask_c = 1<<12 | 1<<11 | 1<<10 | 1<<1; /* 0x1c02 */
const uint16_t mask_a = 1<<12 | 1<<11 | 1<<10 | 1<<9; /* 0x1e00 */
_gpio_write(GPIOC, (uint16_t)(BITS(data, 0) << 12 | BITS(data, 1) << 11 |
BITS(data, 2) << 10 | BITS(data, 3) << 1), mask_c);
_gpio_write(GPIOA, (uint16_t)(BITS(data, 4) << 12 | BITS(data, 5) << 11 |
BITS(data, 6) << 10 | BITS(data, 7) << 9), mask_a);
}
Test:
/* just for testing: read the written data bits back and arrange them in a byte */
static uint8_t _read_data_from_pins(void)
{
const uint32_t reg_c = GPIOC->ODR;
const uint32_t reg_a = GPIOA->ODR;
return (uint8_t)(BITS(reg_c, 12) << 0 | BITS(reg_c, 11) << 1 |
BITS(reg_c, 10) << 2 | BITS(reg_c, 1) << 3 |
BITS(reg_a, 12) << 4 | BITS(reg_a, 11) << 5 |
BITS(reg_a, 10) << 6 | BITS(reg_a, 9) << 7);
}
/* somewhere in main loop of test project */
{
uint8_t d = 0xff;
do {
_write_data_to_pins(d);
if (d != _read_data_from_pins()) {
Error_Handler();
}
} while (d--);
}
(Note: Only 7 of the 8 data pins DB[7:0] were listed in the question, PC1 was assigned to data pin D3 here.)
(Note: Most of these bit-shifts can be easily optimized out by the compiler, use at least -O1 to get somewhat compact results with GCC.)
GPIOA->regs->BSRR = 0b0001101000000000; // A port: turn on PA9, PA11, PA12
GPIOC->regs->BSRR = 0b0001010000000000; // C port: turn on PC10 and PC12
These two code lines do what is stated in the comments. But they will leave all the other pins unchanged.
The resulting output will depend on the previous state of the output data register. - For the LOW data pins, the corresponding GPIO port bits in BSRR[31:16] need to be set to 1 in order to update all the 8-bit data bus lines at once.
To answer the actual question:
No, the output on the data bus will not be 0x9D (0b1001'1101) after writing the two quoted bit patterns to the two BSRR registers. - In my case, it would look like this (please correct me if I'm wrong):
/* write 0x9D (0b1001'1101) to the data bus
used pin assignment: D0 -> PC12, D1 -> PC11, D2 -> PC10, (D3 -> PC1) (?)
D4 -> PA12, D5 -> PA11, D6 -> PA10, D7 -> PA9 */
GPIOC->BSRR = 0x8001402; /* = 0b00001000'00000000'00010100'00000010 */
GPIOA->BSRR = 0xc001200; /* = 0b00001100'00000000'00010010'00000000 */
Suppose 'command' is the byte to send (I hope there is a strobe somewhere...).
I would simply make 8 lines of code like this (If I well understand the port registers of the STM32):
if (command & 1) GPIOC->BSRR |= 1 << 12; else GPIOC->BSRR &= ~(1 << 12);
if (command & 2) GPIOC->BSRR |= 1 << 11; else GPIOC->BSRR &= ~(1 << 11);
...
if (command & 128) GPIOA->BSRR |= 1 << 9; else GPIOA->BSRR &= ~(1 << 9);
Maybe this is quite raw, but it works and it is easy to understand (i.e. more difficult to make typos). Next time tell the hardware designer to arrange wires just a little better... it is hard to think at something worse than this, the bits seem reversed just to see if the software guy can cope with them!
I desperately try to get the PRU on my BBB working. By working I mean that I would want to use the pins P8 39-46 (GPIO2[6-13]) as a fast output controlled by the PRU.
I installed the debian for BBB (2 weeks ago, should be current) on SD.
Then I started with the following article: http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone/blog/2013/05/22/bbb--working-with-the-pru-icssprussv2
doing so, I got the PRU working with the LED example as well as with pin P8[12].
Now I try to get the other pins working. I started all over by just making a little change to the original am335x-boneblack.dtb. I just activated the PRU.
I did not change the LED heartbeat as well as pin P8.12.
Then I disabled HDMI in uEnv.txt
My "slots" look like this now:
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
I stumbled upon this post here: https://groups.google.com/forum/#!topic/beagleboard/JRG36bOURfk
EXACTLY what I would want to have, so I took the dts ( the second one) , compiled it, copied it to /lib/firmware and loaded it. "slots" says the overlay was loaded.
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-PRU-IO
BB-PRU-IO is me.
dmesg says:
... part_number 'BB-PRU-IO', version 'N/A'
... slot #7: generic override
... bone: Using override eeprom data at slot 7
... slot #7: 'Override Board Name,00A0,Override Manuf,BB-PRU-IO'
... slot #7: Requesting part number/version based 'BB-PRU-IO-00A0.dtbo
... slot #7: Requesting firmware 'BB-PRU-IO-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
... slot #7: dtbo 'BB-PRU-IO-00A0.dtbo' loaded; converting to live tree
... slot #7: #2 overlays
... slot #7: Applied #2 overlays.
Looking good I would say.
The problem is the pinmux does not seam to be impressed:
cat pins | grep 8a4
=> pin 41 (44e108a4) 0000002f pinctrl-single
This is MODE 7 (GPIO Out). Not what I wanted. For all of pins I intended to switch to PRU Mode 5.
Now I tried the delivered dtbo's for the PRU 01,02 in /lib/firmware
PRU-01.dtbo seems to be a fitting example. Only the Pin is different (P9.27).
I loaded it and changed the PRU code example.
The pins did not show the expected result:
pin 105 (44e109a4) 00000027 pinctrl-single
When I run the modified testprogram from the first articel my osci shows a flatline.
I tried PRU-02.dtbo.
At least the pins showed the expected result:
pin 105 (44e109a4) 00000025 pinctrl-single
When I start my little test program I get a "bus error"
dmesg has several lines. the important ones I would say are:
[ 119.258978] WARNING: at arch/arm/mach-omap2/omap_hwmod.c:2096 _enable+0x101/0x174()
[ 119.259004] omap_hwmod: pruss: enabled state can only be entered from initialized, idle, or disabled state
[ 119.259027] Modules linked in: g_multi libcomposite btusb bluetooth rfkill uio_pruss mt7601Usta(O)
.... several trace messages
[ 119.272382] pru-rproc 4a300000.prurproc: #8 PRU interrupts registered
[ 119.272445] pru-rproc 4a300000.prurproc: Failed to read events array
[ 119.287545] pru-rproc: probe of 4a300000.prurproc failed with error -22
PRU-02 does more than PRU-01 (what I do not understand). And it does not seem to work for me.
Now I am kind of helpless.
Any ideas on that?
EDIT:
I did what you should not do. I changed the pinmux setting in the am335x-boneblack.dtb file. I just added:
0xA0 0x05
0xA4 0x05
0xA8 0x05
0xAC 0x05
0xB0 0x05
0xB4 0x05
0xB8 0x05
0xBC 0x05
to pinmux_userled_pins {
pinctrl-single,pins = <
Now it works, but I am not happy. I still would appreciate a regular overlay file.
OK I got it working:
just enable the pruss in the am335x-boneblack.dtb (convert to dts. do the changes as described in the article mentioned in the original post)
Got to the website : http://kilobaser.com/blog/2014-07-28-beaglebone-black-devicetreeoverlay-generator#dtogenerator and let the site create dts files for the various pins in my case P8 46-39. Using a single DTS(DTBO) File for each individual pin works but requires 8 dtbos loaded => I moved all of them into one DTS File.
this is it:
/dts-v1/;
/plugin/;
/{
compatible = "ti,beaglebone", "ti,beaglebone-black";
part_number = "BS_PINMODE_PRU_OUT";
exclusive-use =
"P8.46",
"P8.45",
"P8.44",
"P8.43",
"P8.42",
"P8.41",
"P8.40",
"P8.39",
"pr1_pru1_pru_r30_6",
"pr1_pru_pru1_r30_7",
"pr1_pru1_pru_r30_4",
"pr1_pru1_pru_r30_5",
"pr1_pru1_pru_r30_2",
"pr1_pru1_pru_r30_3",
"pr1_pru1_pru_r30_0",
"pr1_pru1_pru_r30_1";
fragment#0 {
target = <&am33xx_pinmux>;
__overlay__ {
bs_pinmode_pru_out: pinmux_bs_pinmode_pru_out {
pinctrl-single,pins = <0x0a4 0x5 0x0a0 0x5 0x0ac 0x5 0x0a8 0x5 0x0b4 0x5 0x0b0 0x5 0x0bc 0x5 0x0b8 0x5>;
};
};
};
fragment#1 {
target = <&ocp>;
__overlay__ {
bs_pinmode_pru_out_pinmux {
compatible = "bone-pinmux-helper";
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&bs_pinmode_pru_out>;
};
};
};
};
I named the file bspm_pru_out-00A0.dts, compiled it to bspm_pru_out-00A0.dtbo and placed it it in the /lib/firmware.
You can load it via /boot/uEnv.txt or via echo... in a rc.local file... whatever you like.
I work on Atom-32bit-intel, I have to port MicroC OS II, so there is no code to make any configuration on the Atom (No GDT, no LDT...):
my question is more about the state of the Atom-32bit after a reset, is the Atom in protecte mode or not ? and the most important how do i check which mode is it (which registers have to be checked nad how)?
Remark:
The CR0.PE = 1 (I checked it), is that enough to prove that the Atom is in protected mode ?
************ UPDATE : *****************
/*Read the IDTR*/
sidt (idt_ptr)
/*Read the GDTR*/
sgdt (gdt_ptr)
So I tried just to use IDT's address to link my ISR to the IDT :
fill_interrupt(ISR_Nbr,(unsigned int) isr33, 0x08, 0x8E);
static void fill_interrupt(unsigned char num, unsigned int base, unsigned short sel, unsigned char flags)
{
unsigned short *Interrupt_Address;
/*address = idt_ptr.base + num * 8 byte*/
Interrupt_Address = (unsigned short *)(idt_ptr.base + num*8);
*(Interrupt_Address) = base&0xFFFF;
*(Interrupt_Address+1) = sel;
*(Interrupt_Address+1) = (flags>>8)&0xFF00;
*(Interrupt_Address+1) = (base>>16)&0xFFFF;
}
my ISR a imple one :
isr33:
nop
nop
cli
push %ebp //save the context to swith back
mov %esp,%ebp
pop %ebp //Return to the calling function
sti
ret
Chapter 9 of volume 3 of the Intel Software Developer's Manual says that the reset value of CR0 is 60000010H. As you can see, bit 0, aka PE, is clear.
Regardless, you can setup the descriptor tables in Protected Mode as well as in Real Mode. You just have to be more careful about it.
I suggest you check if the BIOS or OS are setting this bit at a stage before you read it.
Atom is x86 instruction set, and as such, should be starting in real mode for compatibility. I don't have one on hand to test with though.
Resolved, I use N450 Atom board, it has already a BIOS, the BIOS configures the board in Protected Mode.