Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

micropython SPI syntax problem for nodemcu

yefj

Advanced Member level 4
Advanced Member level 4
Joined
Sep 12, 2019
Messages
1,404
Helped
1
Reputation
2
Reaction score
5
Trophy points
38
Activity points
8,544
UPDATE:
Hello I understood the table i think.
MOSI :SD1- pin23
CS: CMD-pin 20
MISO:SD0-pin 22
SCLK-CLK-pin 21

How do i define the pin numbers into the SPI command?
Thanks.

1723812075060.png

*********************************************************************************************************
Hello, I have a Nodemcu microcontoller shown bellow.
Where i want to use the periphery shown in the red arrow to communicate with my DAC8004 (link attached).
I tried to follow the formal SPI manual for micropython.
My first obsticle is to define the pins of SPI into the SPI object constructor.
In the manufacturer manual of esp8266 they present a table(shown below) with 9 pins although SPI only needs 4 pins.
How can I know the pin number of my esp8266?
for example how do i define the pin callde SD1 as mosi in the SPI command?
Thanks.


1723810435973.png


1723810732866.png


1723810874831.png
 
Last edited:
Hello, I am trying to communicate with DAC8004 using SPI and thonny micropython.
from the manufacturer manual the periphery is pins 12-15.

However when i try to run the following code of the manual, I get an error shown below that says thatI have a problem in the SPI command.
Where did i go wrong implementing this command?
Thanks.
Code:
cs=machine.Pin(15,machine.Pin.OUT)
spi=machine.SPI(0,baudrate=1000000,polarity=0,phase=0,bits=8,firstbit=machine.SPI.MSB,
                sck=machine.Pin(14),
                mosi=machine.Pin(13),
                miso=machine.Pin(12))
ERROR:
Traceback (most recent call last):
File "<stdin>", line 10, in <module>
ValueError:
>>>


https://docs.micropython.org/en/latest/esp8266/quickref.html#hardware-spi-bus
https://www.espressif.com/sites/default/files/documentation/0a-esp8266ex_datasheet_en.pdf
1723870325921.png
 
UPDATE:
Hello, I need to send the following command for my DAC8004.
0000 0011 0000 1111 1111 1111 1111 0000
Its 32bit command.So i need to lower CS send 4 times 8 bits and raise CS.
from the manual below I see a sample of command spi.write(b"12345678").
The problem with this command is that its not binary.

In C i have written the following variables.
uint8_t B7_B0=0b11110000; //first 4 are dont care,first 4 bits data
uint8_t B15_B8=0b11111111;//data bits
uint8_t B23_B16=0b00000000;//channel A DATA total 0000 1111 1111 1111
uint8_t B31_B24=0b00000011;//write to buffer and update DAC ,Write /rest dont care
How do i send these variables in micropython?
Thanks.

https://docs.micropython.org/en/latest/library/machine.SPI.html
--- Updated ---

UPDATE:


Hello , I have built the following code and defined hspi.
I defined buf2[0] but as you can see below i cant send it.
Where di i go wrong sending this variable?


*************************************
import machine
from machine import Pin, SPI
from time import sleep
hspi = SPI(1, baudrate=1000000, polarity=0, phase=0)
#hspi = SPI(1) # sck=14 (scl), mosi=13 (sda), miso=12 (unused)
dc = Pin(4) # data/command
rst = Pin(5) # reset
cs = Pin(15) # chip select, some modules do not have a pin for this
cs.value(0)

cs.value(1)



***********************************************
>>> hspi
HSPI(id=1, baudrate=1000000, polarity=0, phase=0)
>>> buf2[0]
3
>>> hspi.write(buf[0])
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: object with buffer protocol required
>>>
 
Last edited:
Hello I wrote the foolowing code to send the following command for setting my dac8004 acording to the datasheet.
Osciloscope photos are attached.
did the command was sent correctly from the HSPI periphery?
Thanks.
0000 0011 0000 1111 1111 1111 1111 0000
MSB*********************************LSB
1723977248158.png


Code:
import machine
from machine import Pin, SPI
from time import sleep

# Initialize SPI (HSPI)
hspi = SPI(1, baudrate=1000000, polarity=0, phase=0)

# Buffer data to send
buf = bytearray(4)
buf[0] = 0b11110000  # B7_B0
buf[1] = 0b11111111  # B15_B8
buf[2] = 0b00000000  # B23_B16
buf[3] = 0b00000011  # B31_B24

# Initialize control pins
dc = Pin(4, Pin.OUT)    # Data/command
rst = Pin(5, Pin.OUT)   # Reset
cs = Pin(15, Pin.OUT)   # Chip select

# Start transmission
cs.value(0)  # Set CS low to enable communication

# Send data over SPI
hspi.write(buf)  # Send all buffer data at once

cs.value(1)  # Set CS high to end communication

1723976936749.png

1723976908979.png
 
I take it that this is a follow-on from your previous post at https://www.edaboard.com/threads/dac8004-spi-settings-options.412057/.
Looking at the diagram that you posted in Post #9 of the other thread, it shows the SCK line as idling high. Therefore, looking at the prototype of the function call you show in Post #1 of this thread, that means the 'polarity' parameter needs to be 1.
As the data is sampled by the slave on the falling clock transition, that would be the first transition after idling and so the phase wil be 0.
You can tell that something is wrong with your settings by looking at the scope trace above - it clearly shows the SCK as idling low when it should idle high.
WIth those scope traces it is hard to see the phase relationship between the clock and the MOSI signal - try to expand the timebase to make sure that the transitions are when the clock goes high and the MOSI line is therefore stable at the falling clock transition.
There is nothing wrong with the general approach to passing the values to the DAC but you need to get a better understanding of the order of the 'buf' array elements are being passed. Have a look at your scope trace. It shows that the first value passed is the b'111000' value which you say you want as the LEAST significant bits. However they are being sent as the first (i.e. MOST) significant bits to the DAC.
Susan
 
Hello,I am not sure if my data on the osciloscope is going left to right or right to left.
we need to send the command MSB first.
So first i send buf[3] then buf[2] then buf[1] then buf[0].
However Python sends each byte in reverse order, So maybe i should try to do LSB first?
How do i cahnge the SPI object hspi = SPI(1, baudrate=1000000, polarity=0, phase=0) to be LSB first?
0000 0011 0000 0000 1111 1111 1111 0000
MSB*********************************LSB
buf[0] = 0b11110000 # B7_B0
buf[1] = 0b11111111 # B15_B8
buf[2] = 0b00000000 # B23_B16
buf[3] = 0b00000011 # B31_B24
 
(BTW, because you have two threads running with basically the same question, you can expect to get things confused. Please stick to one of your threads.)
Hello,I am not sure if my data on the osciloscope is going left to right or right to left.
Every oscilloscope that I've ever come across has the time going left to right. (If you want proof for yours, turn the timebase down to (say) 1 second per division and you will see the trace slowly going left to right.)
we need to send the command MSB first.
So first i send buf[3] then buf[2] then buf[1] then buf[0].
However Python sends each byte in reverse order, So maybe i should try to do LSB first?
NO. You need to understand the order that Micropython will access the elements of the array and set the array values accordingly. As it will send the index '0' first, and you need to send the data with MSB first, then the value for index '0' needs to be the most significant byte, then for index '1' the next 8 bits etc..
How do i cahnge the SPI object hspi = SPI(1, baudrate=1000000, polarity=0, phase=0) to be LSB first?
I don't mean to be rude but you really do need to learn to read and understand the documentation. (Also I thin k you need to stop simply copying code from elsewhere without understanding what is does.) The first figure in your post #2 shows all of the parameters that can be passed to the function - including one called 'firstbit'. Actually you use exactly that parameter in the code in that same post.

HOWEVER DON"T DO THAT. The default is MSB first and that is what you want. Your mistake os elsewhere (see the paragraph above this).
0000 0011 0000 0000 1111 1111 1111 0000
MSB*********************************LSB
buf[0] = 0b11110000 # B7_B0
buf[1] = 0b11111111 # B15_B8
buf[2] = 0b00000000 # B23_B16
buf[3] = 0b00000011 # B31_B24
(See above for how to correct this code.)
Susan
 
Hello, The data is moving left to right as you cam see the CS rises.I have reversed the order of the array as shown in the code below.
The photo i get is right before CS rises i get the 11110000 after that 11111111 after that 00000000 and after that i get 00000011.
Did i made it ok now?
Thanks.

Code:
import machine
from machine import Pin, SPI
from time import sleep

# Initialize SPI (HSPI)
hspi = SPI(1, baudrate=1000000, polarity=0, phase=0)

# Buffer data to send
buf = bytearray(4)
buf[3] = 0b11110000  # B7_B0
buf[2] = 0b11111111  # B15_B8
buf[1] = 0b00000000  # B23_B16
buf[0] = 0b00000011  # B31_B24

# Initialize control pins
dc = Pin(4, Pin.OUT)    # Data/command
rst = Pin(5, Pin.OUT)   # Reset
cs = Pin(15, Pin.OUT)   # Chip select

# Start transmission
cs.value(0)  # Set CS low to enable communication

# Send data over SPI
hspi.write(buf)  # Send all buffer data at once

cs.value(1)  # Set CS high to end communication
1724154781741.png

1724154857200.png

1724154522470.png

1724154211584.png
 
OK - the bottom photo shows that the bits are now being sent in the MSB order correctly.
Lets now go back to the datasheet for the DAC that you posted the link for in your post #4 and look CAREFULLY at Figure 1 on page 8. Look at the the SDIN signal line and note when the data is stable (i.e. a 1 or a 0) and then it changes. Now look at the SCLK signal and what it is doing at those same times.
You will see that the data MUST be stable when the SCLK signal goes from 1 to 0.
Now look at your photos, especially those parts where the MOSI signal changes within a byte.
Note the difference. You are telling the SPI module to change the MOSI value on the wrong SCLK transition.
SAo how to fix this.
For a start, look again at the datasheet Figure 1. When you are NOT performing an exchange, it is telling you that it expects the SCLK signal to be 1. NOw look at your photos again - the SCLK signal is 0 when idling so that is wrong.
To fix that look at the extract you provided in Post #1 for the SPI.Init() function and look at the description for the 'polarity' parameter. To have the clock idle high, the parameter value has to be 1. Look at your code and you will see that it is 0 so that needs to be changed.
Next, the first transition of the SCLK with then be from high to low which is when the data needs to be stable. Look at the function documentation again and see what it says about the 'phase' parameter. It says to sample on the first clock edge the vale should be 0 so you probably have that right. (I say probably because I suspect that this really refers to the sampling of the MISO signal but that is not used in your case.)
So try that and see what happens.
The real test of whether your code is right or not is if the DAC responds -does it?
Susan
(PS: I have no idea what the second line of your post #8 means. The data should be interpreted while the CS line is low.)
(PPS: All of the above is actually answered by @betwixed in your other post - as I've said, creating two or more threads for basically the same question only leads to confusion and is a really bad idea.)
 
Hello Aussie Susan,If i understand you correctly . In the datasheet we are sampling at clock going down.
but my SPI is sampling when clock going up,So polarity needs to be 1 instead of zero.
I put photos called AFTER polarity change.
purely looking at SPI command logic did i succsees sending properly
00000011 00001111 11111111 11110000
?
Thanks.



1724405307108.png

1724405075473.png


before polarity change:

1724404682421.png

1724404808977.png



AFTER polarity change:

1724406732307.png


1724406852734.png
1724407063715.png

00000011 00001111 11111111 11110000
1724407097761.png
 
That looks right to me.
However the real test is whether the DAC understands it. Does the DAC respond when you send this and other sequences that have different data values?
Susan
 

LaTeX Commands Quick-Menu:

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top