-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to use SPI #10
Comments
zeptoforth does not do I2C yet but I plan on adding support in the near future. |
Thanks Travis. I look forward to trying it. |
Hey @ctrilsbach - I now have working I2C support for the Raspberry Pi Pico. Note that the latest build does not include slave-receiver NACK generation, while the repository includes it. I highly recommend building a new build (mind you this currently requires a Unix-like OS, Python 3, and pySerial - and note that people have reported issues with pySerial installation on xBSD), if you feel up to it, so not only you can have not only slave-receiver NACK generation, but also has a significant performance optimization with regard to compilation. |
Hi Travis, |
Chris, Don't worry about the slave-receiver NACK for what you are doing, as it is only relevant if you are implementing a slave device. Also, if you are using GP4 and GP5 you will want I2C peripheral 0. For sending an individual block of data to the display I would use Travis |
Chris, One note - don't try to use Picocom for building zeptoforth on the Pico - it just won't work because Picocom doesn't have line synchronization. For building images, first flash the UF2 image for the kernel with the BOOTSEL-USB Mass Storage Device mechanism, and then use make_uf2_image.sh (but mind you, because it is designed to build multiple images in a row it automatically erases everything but the kernel when it is done) or codeload3.py (which loads the code but does not in itself build an image, or erase anything). You could try using zeptocom.js, which is at https://tabemann.github.io/zeptocomjs/zeptocom.html to upload code, but that requires Chrome or Chromium or Opera and I don't know how well those will work on a RPi 4. Travis |
Chris, I have just made a new release, 0.46.1, which includes these changes, so there is no need for you to build zeptoforth from scratch just for them. Travis |
Great thanks Travis, downloading it now. |
Just a note - don't use [if] [else] [then] inside EVALUATE'd code, including code loaded from a FAT32 filesystem - it will break badly; I'm working on fixing that now. |
Travis, If I try the following, Forth locks up and has to be re-booted. i2c import I notice in the test directory your i2c code doesn't seem to use enable-i2c Chris |
Chris, Thanks for catching that for me! I did not catch that bug because I always ran it as:
Travis |
Chris, I just have made a new patch-level release, 0.46.3, which fixes this issue amongst other issues. Travis |
Travis, Thanks for fixing the bug. I am now getting an error "I2C target address not acknowledged" after running >i2c-stop . My code so far to initialise a SSD1306 display is :- i2c import create init_display 0 master-i2c 0 7-bit-i2c-addr init_display 17 0 >i2c-stop Thanks for your help Chris ps I have been using zeptocom.js to upload. Should you be able to type in the terminal window ? |
Chris, Thanks a lot for trying out my I2C layer for the Raspberry Pi Pico. This is a bug I didn't catch because the address I was using ($55) for some reason just happened to not catch where bit patterns for target addresses were not being set properly (which is strange, as from looking back at the code it should never have worked for that value in the first place). I have now made a new patch-level release, 0.46.3.1, that fixes this issue. Note that for zeptocom.js you are not supposed to be able to edit the terminal window; it is solely output alone, because it is showing what is being echoed by the MCU along with advisory messages from zeptocom.js itself. Travis |
Chris, BTW, apparently you probably want to use separate pull-up resistors (I use 4K7 ohm resistors) rather than using the built-in pull-up resistors, even though I have also heard that in many applications the built-in pull-up resistors work okay anyways. Travis |
Chris, I just ran your code, and while it did not have any obvious failures (didn't crash, didn't raise an exception, etc.), I should note that Travis |
I am going to investigate this issue more, as it ought to be failing right away rather than having to send more data for it to fail in this case. |
Travis, Glad that I could be of some help finding these bugs. The display does work fine with the internal pull ups but I have taken your advice and used some external resistors just in case. The display is working now, but not displaying correctly. I know the data is fine as I have already had it working but need to check my code to see if I have done something stupid. I cannot get the dump word to work for some reason ? On other Forths I have used the syntax is dump ( addr u -- ) where u is the number of bytes. I wrote my own but wondered what I was doing wrong. Chris |
Chris, If it works fine with internal resistors, I would just use those. One way or another I probably would not combine internal resistors with external ones. I would be really interested in seeing your Mecrisp/Tachyon code alongside your current zeptoforth code for this to see what's different (to see if you're using them differently or to see if there's a bug in my code). BTW, Travis |
Travis, Yes, I wasn't going to use the internal pull ups as well. Peter's i2c code is a bit bang interface so you have to start a stream write bytes and send stop. So the main difference is that with his code I wrote directly to the display and with your layer I have to construct a buffer each time and then pass the address of it. This is an example of using Tachyon that Peter sent me :- MECRISP --- select SSD1306 --- SOME SHORTCUTS FOR TESTING --- AUTO UPDATE IN THE BACKGROUND This my code so far to hopefully put digit 0 on the display. It is working but only clearing half the display and the zero is not right. i2c import variable bytecntr create i2c-buf 1024 allot \ buffer for display create digit0 create init-display 0 master-i2c 0 7-bit-i2c-addr : dmp 20 0 do dup I + c@ . loop ; : setup-display ( -- ) : store-char ( c -- ) \ put chars in array : clear-screen
; : load-digit
; : main This is my first project in Forth so it probably looks a bit long winded. Chris |
Chris, It turns out that there might be a bug in the STOP generation where it's generating the STOP too soon, which I am working on fixing at the moment. Travis |
Chris, I have made a new release, 0.46.3.2, which should fix the STOP issue. Try it out and let me know how it works out. Travis |
Travis, All working ok thanks. The screen fully clears now and I found a small bug in my code as well that was missing off the first byte of digit 0's data which wasn't helping. Now I can change my rest of the code in my project to use Zeptoforth. It controls a stepper motor to move a camera and activates the shutter as well to do focus stacking. The display is needed to show information on the shoot. When it is finished I intend to publish the design on line and would rather the instructions on how to install Forth and the code to be straight forward and well documented rather then having to load Mecrisp then Tachyon which is not. Hopefully I won't have to bother you any more for a while. Thanks again. Chris |
Chris, Oh, I don't consider it a bother — I would much rather have feedback about zeptoforth (and would like bugs others find being reported) than not have any feedback, and I like hearing that you are using zeptoforth for an actual project (and would like to hear about your future progress with it). Please keep me informed about what you are doing and how things are going. You're welcome, Travis |
Hi Travis,
I have changed this comment because I have just realised that I have confused I2C with SPI. Does Zeptoforth do I2C as well as I am trying to connect to an OLED display ?
Chris Trilsbach
The text was updated successfully, but these errors were encountered: