Comments (10)
Hi,
the bsim_qemu
use only the bitbang_i2c_ctrl (I2C Controller/Master). The "datas" (data to send) is not used in the controller implementation. The "datas" is only used by I2C peripherals (bitbang_i2c).
The "datar" means data received. With your modification, the examples and tests that use I2C don´t work anymore.
To implement your display communication you should add an I2C peripheral or check the I2C address of the picsimlab_i2c_event
callback and do the communication directly without using the I2C controller (and bit-bang), implementing your own switch/case for the address of your display.
I know that Qemu now supports async I2C, but the Espressif ESP32 doesn´t yet. I believe that adding this support to Qemu/PICSimLab will not improve the simulation speed significantly.
from picsimlab.
oh, so I misunderstood then how to do it.
What I've done is create an i2c device, and call bitbang_i2c from it from a function named (xxx_io) (bitbang_i2c_io, bitbang_i2c_send and bitbang_i2c_get_status) (I basically copied the behavior of rtc_pfc8563)
This xxx_io function is called by my board from inside Run_CPU_ns...
What I noticed is that the bitbang_i2c_send call was never received by my firmware application. After changing the bitbang_i2c_ctrl, it started to work. (I was confused by the fact that datas is not used anywhere except as a return status in bitbang_i2c... so I don't understand how this send function can work)
here is the modification I've done. What example are you talking about? (because I checked all the qemu boards and I didn't see any breakage, but they do not use i2c)
index 941e74f7..1007fab7 100644
--- a/src/boards/bsim_qemu.cc
+++ b/src/boards/bsim_qemu.cc
@@ -160,7 +160,7 @@ static int picsimlab_i2c_event(const uint8_t id, const uint8_t addr, const uint1
g_board->timer.last += 72000;
g_board->Run_CPU_ns(72000);
dprintf("<== recv addr=0x%02x value=0x%02x\n", addr, g_board->master_i2c[id].datar);
- return g_board->master_i2c[id].datar;
+ return g_board->master_i2c[id].datas;
break;
}
return 0;
from picsimlab.
From the description you are on the correct path, but from your result you must be using just one bitbang_i2c_t object shared between the controller and peripheral (which doesn't work) or you are using two bitbang_i2c_t objects but passing one as an exchanged parameter in the I2C functions.
Are you using one structure like the board K16F uses for PCF8563? Note that pre-treatment must be done on the pins used for I2C for the bus to work. (You can use VCD dump with pulseview I2C decoder to verify)
Theoretically, placing the I2C peripheral update at the end of the if
that contains the MStep
method call (which updates the I2C controller) should work.
The example is for BM280. The automated tests (in folder tests) uses the BM280 for test I2C of ESP32 too. With your modification, the example and test failed to read data from BM280.
from picsimlab.
Observs that in the code of pre-treatment when the pins are accessed directly from pins
array the index is subtracted from one. For example, pin number 3 is accessed as pins[2]
, and the functions use the number 3 directly.
from picsimlab.
Yes, I've noticed the minus one when accessing the pins directly.
About my device, yes it has its own bitbang_i2c_t struct. And the bsim_qemu has an array of bitbang_i2c_t named master_i2c[]
I've used vcdump and pulseview and I did see the I2C signal.
I will check the example to understand how it's done.
Since my device is directly used inside my board, I may have overlooked something. Most likely the access to the pins (however, I know that the pin values are correctly reflecting the I2C transfert since I'm using MGetPin(scl-1) and MGetPin(sda-1) in my device Io function)
I will also push my code in my fork too very soon.
from picsimlab.
Hi @fariouche ,
I have implemented a simple test adding a bmp280 I2C sensor to the devkit board. It works without problems.
The modified code and one workspace to test are in the annexed zip file. (It uses the same code as the original bm280 example).
You can use it as a base to discover the problem in your implementation.
from picsimlab.
Hi @lcgamboa ,
Thanks for the sample. I know understand why my modification was wrong and also why it worked by chance in my use case.
I've found the reason my send was not working....
I had to do something similar than SpareParts.SetPullupBus, like so:
pins[22 - 1].value &= io_axp192_io(&axp192, MGetPin(23)/scl/, MGetPin(22)/sda/);
It's a bit ugly, as I was not able to use the SpareParts function. Most likely because my device is not a spare part but directly called from inside my board?
from picsimlab.
For historical reasons, the spare parts simulation is isolated from the board simulation. In the beginning, there was only the board simulation. Spare parts are created after. In the future, perhaps the board could become one spare part.
But now I believe you are on the right path.
from picsimlab.
it does not shock me to have them separate. One evolution that would be helpful is to hide this "pullup" code so that it is transparent. Maybe inside bitbang_i2c_io?
from picsimlab.
I'll put this on the to-do list. Lately, I haven't had time to work on PICSimLab.
from picsimlab.
Related Issues (20)
- issue loading esp32 firmware HOT 37
- crash when selecting open hex file HOT 4
- Can't run it in Manjaro (Arch) Linux HOT 4
- Is it possible to separate the backend simulator/emulator when compile the full package? HOT 3
- Can't set LCD1602 R/W pin to GND in gpboard. HOT 6
- gpboard isn't fast as other boards; like, Mclab2 and PICGenios. HOT 4
- PICGenios board with PIC18F4580, crash upon invoking TIMER2. HOT 3
- Impossible to install picsimlab on debain 12 with latest .deb HOT 3
- PICGenios with PIC18F4580 analog pins improperly configured. HOT 2
- Gpboard simulation failed HOT 6
- Simulator for PIC18F87J60 (PIC18F97J60) HOT 2
- [Question] Weird Servo Motor Movement HOT 3
- Gpboard crash on loading hex HOT 3
- Gpboard simulation speed issue HOT 4
- MCP23S17 not working as inpurs HOT 14
- RTC ds1307 HOT 14
- PICSimLab Not responding HOT 3
- Starting QEMU with -S to await a GDB connection HOT 8
- No way to customize qemu efuse and bin file paths? HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from picsimlab.