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.
OK so you know the LCD is working.
Have you read the ST95020 data sheet, and in particular the 'Byte Write Operation' section on page 9? It says that you need to send the "WREN" instruction to set the Write Enable latch. This is complete instruction in its own right and so requires that the \CS\...
So how do you know that it is not working?
Have you tried using the debugger?
You really do need to give us the information that will help us actually help you.
Susan
"...don't wanna[sic] work' is not a problem description that we can work with.
Is this in a simulator or a real device?
Show is the SPI code.
Show us the config settings for the PIC.
What have you tried and what was the result?
What should have happened?
Susan
Both are bad choices unless you want to do all of the work yourself. If you do then both have very limited program memory (1K words for the PIC16F676). They are also very old.
Look at something like the PIC18F26K83 which has a CWG module that does what you want.
I'm not sure what you mean by...
As @KlausST has already said - yes
No.
Perhaps I need to explain what is meant by the ISR saving and restoring the context.
When the compiler comes to create the code for an ISR, it 'knows' from your code what internal registers it will use. It has no knowledge of where the ISR might be called...
In some ways the debugger is working the same way as the ISR.
When the operation is transferred to the debugger at the breakpoint, the debugger will go to the variable location to read its value. Therefore it WILL read the updated value from the ISR.
However that is missing the point.
Take the...
Depending on the compiler, they generally will compile each function (including the ISRs) separately. That is because normally the code within a function is executed independently of other functions. Even when a function calls another function, the compiler has no understanding of that the...
It would help if you told us a bit more about the LCD that you are using - they are not all the same. Therefore the following are 'generic' comments.
I would not truest your 'Delay' function to do anything - any half-decent compiler will see that nothing really changes and convert the whole...
Is that the code that actually shows the problem?
Looking at that, there are only 2 places where RE1 changes (via the 'BUZZER_PIN' name) - at least that are not commented out - and they would seem to be far enough away from the references to RE2 to probably not be RWM related.
What I don't see...
A simple flip-flop would do the trick using the pulses as the clock. (I consider things like the 74xx series ICs as 'discrete' components these days.)
Susan
(I originally posted this question on the Espressif support forum a week ago but I've had no response. Looking for better luck here.)
I have an ESP32-H2-DevKitM-1 and the Espressif IDF (V1.6.5) installed on VS Code. Using that I did an 'express' setup about 3 days ago so I should have the...
I woudl certainly NOT call the code in that web page you link to 'correct'. It is open to so many RWM errors that it is not funny.
Also if you look at the comments towards the bottom there are others that say they do not get anything displayed. They also mention that the \RST\ pin is not...
Step 1: understand that I2C (and SPI and UART and similar) transfer/exchange values but put no interpretation on what those values mean. Typically I2C will transfer bytes.
Step 2: you need to determine how you want to use the I2C mechanism to transfer your 'numbers'. Perhaps the numbers are 8...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
