one way to solve this would be a P1 emulator on the P2 running P1 pasm as a XBYTE code interpreter. Simulating the counters and Video hardware might be tricky.
But basically the P2 is a different beast. A conversion of P1 objects makes no sense. As Jon stated a I2C object does not need a COG anymore, just a smart pin.
This is like 800xl vs MegaST or C64 vs Amiga. It simply makes no sense to translate P1 to P2.
OBEX seems to be closed anyways, the new GIT thing is not ready, we all can just post here and search here to do our experiments, but it is good like it is. We all together do the final testing, things are coming together, @rogloh with his video and hyperram driver, @Rayman with his tiled GUI, @garryj with USB, we are getting there.
And we have also the not infamous but famous @JonnyMac pushing out stuff faster then I can look thru it...
I have not started playing with any of these C compilers, yet. Ken is thinking it might be good to get a few significant objects done, first. I will be getting the documentation done soon.
I have been converting Kye's FAT32 spin code to spin2.
The good news is it is now compiling but no testing yet.
FWIW by far the biggest bugbear is the adding of () to method calls.
All PUB and PRI now have () added when no parameters were passed, and all have a return parameter "result" declared.
eg PUB anexampleroutine() : result | anylocalvars
I came across these errors. Is the spin2 compiler meant to support these "constant" structures?
readWriteAppend := ("R" + (constant("W" - "R") & (findNumber(mode, "W", "w") or findNumber(mode, "A", "a"))))
if( (fileOpenCloseFlag and (currentByte < 0)) or (not(fileOpenCloseFlag or (currentByte < constant(65_536 * 32)))) or .....
BTW there are only a couple so I have made a CON equate for them. If it's a bug, no hurry for a fix.
I have been converting Kye's FAT32 spin code to spin2.
The good news is it is now compiling but no testing yet.
FWIW by far the biggest bugbear is the adding of () to method calls.
All PUB and PRI now have () added when no parameters were passed, and all have a return parameter "result" declared.
eg PUB anexampleroutine() : result | anylocalvars
I came across these errors. Is the spin2 compiler meant to support these "constant" structures?
readWriteAppend := ("R" + (constant("W" - "R") & (findNumber(mode, "W", "w") or findNumber(mode, "A", "a"))))
if( (fileOpenCloseFlag and (currentByte < 0)) or (not(fileOpenCloseFlag or (currentByte < constant(65_536 * 32)))) or .....
BTW there are only a couple so I have made a CON equate for them. If it's a bug, no hurry for a fix.
No more need for CONSTANT, since the compiler figures it out automatically now.
I have not started playing with any of these C compilers, yet. Ken is thinking it might be good to get a few significant objects done, first. I will be getting the documentation done soon.
Chip, I thought the plan was to make Spin2 self-hosting on the P2. So wouldn't it make more sense to re-write the compiler in Spin2 rather than in C?
If you stick to the subset of Spin2 that fastspin/spin2cpp support then you could run the result through spin2cpp to get a C version. (Of course to make it work cross-platform you'd then have to re-write any PASM code in C, but it might be a way of killing two birds with one stone.)
Chip, I thought the plan was to make Spin2 self-hosting on the P2. So wouldn't it make more sense to re-write the compiler in Spin2 rather than in C?
Ideally one day we would have both options, but commercial developers may not want to only develop on the P2 board itself - which will of course be slower to build and likely a little harder to share online code vs a PC. A general purpose SPIN compiler tool written in C should be very portable and enable development on the widest range of systems, Linux/Mac/Windows/RasPi etc. Being a command line tool it really needs a filesystem however so if this C codebase is ever ported over to a P2 its environment will need that capability built into it as well, perhaps using p2gcc + filesystem extensions and an SD card, or your flexC if that suits, or some other future C compiler for the P2.
If the compiler is written using the more common functions/calls/language then conversion to other languages (spin2, python, etc) might be done more easily. Indentation (not mandatory in C) would help in any conversion.
Chip, I thought the plan was to make Spin2 self-hosting on the P2. So wouldn't it make more sense to re-write the compiler in Spin2 rather than in C?
Ideally one day we would have both options, but commercial developers may not want to only develop on the P2 board itself - which will of course be slower to build and likely a little harder to share online code vs a PC. A general purpose SPIN compiler tool written in C should be very portable and enable development on the widest range of systems, Linux/Mac/Windows/RasPi etc. Being a command line tool it really needs a filesystem however so if this C codebase is ever ported over to a P2 its environment will need that capability built into it as well, perhaps using p2gcc + filesystem extensions and an SD card, or your flexC if that suits, or some other future C compiler for the P2.
I think Eric was trying to say that Chip could develop his Spin2 compiler using FastSpin and compile it to run on either the P2 or on a PC under Windows, Linux, or Mac. The FastSpin compiler can translate Chip's Spin2 code into C code that can be compiled on any platform that supports C. That is, if it is pure Spin2 without any PASM. So Chip can write his compiler in Spin2 and it can still be run on the PC for those commercial developers who would not want to run it on a P2.
I think Eric was trying to say that Chip could develop his Spin2 compiler using FastSpin and compile it to run on either the P2 or on a PC under Windows, Linux, or Mac. The FastSpin compiler can translate Chip's Spin2 code into C code that can be compiled on any platform that supports C. That is, if it is purse Spin2 without any PASM. So Chip can write his compiler in Spin2 and it can still be run on the PC for those commercial developers who would not want to run it on a P2.
I see. Possibly one could go down that route. It wouldn't be my first thought of how to approach it but it could save time if it worked and if there was a good way to deal with file handling requirements. That latter part would be a key problem to resolve.
I think Eric was trying to say that Chip could develop his Spin2 compiler using FastSpin and compile it to run on either the P2 or on a PC under Windows, Linux, or Mac. The FastSpin compiler can translate Chip's Spin2 code into C code that can be compiled on any platform that supports C. That is, if it is purse Spin2 without any PASM. So Chip can write his compiler in Spin2 and it can still be run on the PC for those commercial developers who would not want to run it on a P2.
I see. Possibly one could go down that route. It wouldn't be my first thought of how to approach it but it could save time if it worked and if there was a good way to deal with file handling requirements. That latter part would be a key problem to resolve.
Actually, equally possible would be for Chip to write his compiler in C and use FastSpin to compile that to run on the P2. I'm doing that now with a BASIC interpreter that I'm writing. It works fine on either a PC or on a P2. I use Xcode to compile it for the Mac and FastSpin to compile it for the P2. Any ANSI C compiler would work for PC platforms. You have to make sure you only use standard library functions though. Don't get sucked into the MS world!
This idea is the same thing Eric proposed a while ago, that took a few bites for us and Chip to understand, wasn't it? It does seem to make sense to use the available tools even if slightly unconventional
I have not started playing with any of these C compilers, yet. Ken is thinking it might be good to get a few significant objects done, first. I will be getting the documentation done soon.
Chip, I thought the plan was to make Spin2 self-hosting on the P2. So wouldn't it make more sense to re-write the compiler in Spin2 rather than in C?
If you stick to the subset of Spin2 that fastspin/spin2cpp support then you could run the result through spin2cpp to get a C version. (Of course to make it work cross-platform you'd then have to re-write any PASM code in C, but it might be a way of killing two birds with one stone.)
My thinking was to have the P2 self-hosting, but of late I'm wondering if people really want to dedicate a monitor, keyboard, and mouse to a P2. I kind of imagine they want to stay on whatever platform they have that provides those things, already. So, self-hosting is kind of morphing into quasi-self hosting, where maybe the tools are running on the chip, but the interface is whatever they've already got that they would like to keep using. It's for this reason that I've been looking into what it would take for the P2 to present a web-page interface to ANY host. Things are in flux at the moment because of this.
I have not started playing with any of these C compilers, yet. Ken is thinking it might be good to get a few significant objects done, first. I will be getting the documentation done soon.
Chip, I thought the plan was to make Spin2 self-hosting on the P2. So wouldn't it make more sense to re-write the compiler in Spin2 rather than in C?
If you stick to the subset of Spin2 that fastspin/spin2cpp support then you could run the result through spin2cpp to get a C version. (Of course to make it work cross-platform you'd then have to re-write any PASM code in C, but it might be a way of killing two birds with one stone.)
My thinking was to have the P2 self-hosting, but of late I'm wondering if people really want to dedicate a monitor, keyboard, and mouse to a P2. I kind of imagine they want to stay on whatever platform they have that provides those things, already. So, self-hosting is kind of morphing into quasi-self hosting, where maybe the tools are running on the chip, but the interface is whatever they've already got that they would like to keep using. It's for this reason that I've been looking into what it would take for the P2 to present a web-page interface to ANY host. Things are in flux at the moment because of this.
Chip,
If you use a standard I/O routine (via hub) for your compiler, then another cog(s) can take this I/O and, either use a serial port to a PC/etc, or a VGA/HDMI with USB/PS2 keyboard. If you use simple cursor controls (cls, home, crlf) you have removed any complication. Then it's a simple matter to substitute the other cog code to drive the keyboard/screen wherever it may be. I did this in my P1 OS quite successfully.
I have not started playing with any of these C compilers, yet. Ken is thinking it might be good to get a few significant objects done, first. I will be getting the documentation done soon.
Chip, I thought the plan was to make Spin2 self-hosting on the P2. So wouldn't it make more sense to re-write the compiler in Spin2 rather than in C?
If you stick to the subset of Spin2 that fastspin/spin2cpp support then you could run the result through spin2cpp to get a C version. (Of course to make it work cross-platform you'd then have to re-write any PASM code in C, but it might be a way of killing two birds with one stone.)
My thinking was to have the P2 self-hosting, but of late I'm wondering if people really want to dedicate a monitor, keyboard, and mouse to a P2. I kind of imagine they want to stay on whatever platform they have that provides those things, already. So, self-hosting is kind of morphing into quasi-self hosting, where maybe the tools are running on the chip, but the interface is whatever they've already got that they would like to keep using. It's for this reason that I've been looking into what it would take for the P2 to present a web-page interface to ANY host. Things are in flux at the moment because of this.
I have a dedicated monitor (actually a 19" lcd tv), keyboard, and mouse with an Odroid and P1 mounted on the back of it. The Odroid and P1 are connected serially, and the keyboard/mouse and video can be independently switched between the two boards. Works really well for debugging master/slave code. A self hosted P2 master and P1 slave would be a great combo imho.
@JonnyMac
Hi Jon,
I am trying to use your code jm_i2c-7bit_scan.spin2
I think the printing is missing every second column in the table. There are three sensors on a GY-85 module and the adxl345 should show A6. See attached file: I have forced the A6 to print to proved that it is detected but in the original code it does not appear in the table. I just cant see the source of the error.
Kevin.
It's not, Kevin -- let me explain. I am displaying the slave ids of the found devices in hex format. The device slave id is built-up like this:
%DDDD_AAA_X
...using binary notation, where DDDD is the device type (e.g. $Ax for EEPROM), AAA is the device address (%000..%111) -- this is where we get the 7 bits. The slave id also has a Read/Write bit (X), which is always treated as 0 in this scan.
Here's the working code:
repeat device from $01 to $0E ' loop through device types
term.fhex(device << 4, 2) ' print at start of line
term.tx(" ")
repeat addr from 0 to 7 ' loop through addresses
slaveid := (device << 4) | (addr << 1) ' build slave id
if (i2c.present(slaveid)) ' ping the device
term.fhex(slaveid, 2) ' if found, print slave id
term.tx(" ")
else
term.str(string(".. ")) ' nothing at this slave id
Note that device types %0000 and %1111 are not valid, so the scan goes from $01 (%0001) to $0E (%1110). An inner loop iterates the address of each device from 0 (%000) to 7 (%111). This line is key:
slaveid := (device << 4) | (addr << 1)
...as it builds the slave id as up above -- what we get is %DDDD_AAA_0. This is the format required for my I2C objects (and will be found in most I2C documenation). When you want to read from a device you OR the slave id with 1 to set it into Read mode.
If you've come from the Arduino world, they do things differently. That system truncates the RW bit and uses the 7-bit value directly. Under the hood, they shift that value left by one bit to make room for the RW bit. I always strive for obvious code, and most data sheets that I've encountered use the %DDDDAAAX format (the ADXL345 docs show both).
I had to reread you post to see that you spoofed the $A6 -- bad idea to do that with code you didn't write yourself; it doesn't prove anything and, for a moment, I thought your device was working (though I thought the dots at the end of the line were odd).
You have two devices on the I2C bus -- do they match your expectations? If yes, I think you have a connection problem or bad device (I just went through that the other day with an I2C pulse/ox sensor).
Edit: Since my name has been sullied (grin), I did a bit of research. It looks like the GY-85 module has the ADXL345 and an ITG-3200. According to the docs, the default slave ID for the ITG-3200 is $D0 which shows in your scan. I wonder if the $3C that is showing is your ADXL345? According to its docs, it should be fine with 400kHz, but maybe that device is having a problem.
Do me a favor: Put my code back the way you found it, and then change the I2C bus frequency to 100kHz (standard) to see if that makes a difference. You need to change this line in the setup() method:
i2c.setup(SCL1, SDA1, 100, P_HIGH_15K)
The 3rd argument is the bus speed in kHz. You may need to experiment with the pull-up setting (4th argument) as well.
Thank you Jon for your help. There are 3 sensors in the GY-85 (ADXL345 accelerometer, ITG3200 gyroscope and HMC5883L magnetometer) and the 8 bit values are $A6, $D0 and $3C. If I change the code to use:
pub wait(slaveid) : result | ackbit, num
'' Waits for device to be ready for new command.
num := 0
repeat
++num
start()
ackbit := write(slaveid)
until (ackbit == ACK || num == 2)
result := (ackbit == ACK)
which does two writes for each slaveid (perhaps wakes up the ADXL345) it gives the output as attached consistently::
I will assume the ADXL345 is faulty and find an alternative to experiment with.
I was not trying to find fault in your code. I really should have found a schema for the GY-85 as I could not follow:
With CS tied high to VDD I/O, the ADXL345 is in I2C mode,
requiring a simple 2-wire connection as shown in Figure 8.
It supports standard (100 kHz) and fast (400 kHz)
data transfer modes if the timing parameters given in Table 11
and Figure 10 are met. Single- or multiple-byte reads/writes are
supported, as shown in Figure 9. With the SDO/ALT ADDRESS
pin high, the 7-bit I2C address for the device is 0x1D, followed by
the R/W bit. This translates to 0x3A for a write and 0x3B for a read.
An alternate I2C address of 0x53 (followed by the R/W bit) can
be chosen by grounding the SDO/ALT ADDRESS pin (Pin 12).
This translates to 0xA6 for a write and 0xA7 for a read.
Okay, but put yourself in my shoes for a moment. Twice now you have come back with changes to my code instead of assuming you have a dodgy device, or your application of my code has a problem. I don't mean to be harsh, but changing a library is a bit cavalier; the point of using libraries is that we don't have to modify them for our particular situation. I have been using the P1 version of my I2C library for 10+ years in a number of commercial applications without issue. I sincerely believe that the P2 version is a reliable translation that you do not need to modify. If there is an actual bug, I will happily fix it -- that has not been the case thus far with your GY-85 module (I believe, anyway).
Did you try 100kHz? Yes, I have seen the docs that the device supports 400kHz -- but I'm betting your connections between the P2 and the device are less than perfect; this is why I suggested the slow down. If that works, then you can bump the speed until you find the limit of your setup. Remember, I2C is synchronous so it doesn't have to be 100 or 400, you can set it to anything you want.
It seems completely illogical that an IMU device would require two queries to get it going -- this defeats the point of the device providing positional data for a real-time system. It doesn't happen often, but sometimes we get bad devices. A little over a week ago my friend Rick dropped off a pulse/ox sensor for me to play with. I connected it to a P1 (his target) and it didn't show up, even though the P1 EEPROM did. Under I microscope I found all kinds of problems with bad solder joints and components that were touching each other (this appeared to have been assembled by hand). We exchanged it with Amazon and now have a working device.
Note that there is a method called present() in the I2C object. The point of this method is to detect a device, after which the wait() method (which has no timeout) is useful.
The 7-bit vs 8-bit address thing seems to be troublesome for you, so I have attached another version of my I2C scanner -- it shows the detected devices and their addresses in both formats. It also allows each device to be pinged more than once (though I think this is unnecessary). In the screen shot you can see it detects two chips on the same PCB; $AE is an EEPROM, and $D0 is an RTC.
Note, too, that I've made updates to my serial library so you should replace what you have with what's attached (2 files associated with serial).
using 100, PU_3k3 as parameters still no go. Earlier providing two writes did bring up $A6. Possibly the ADXL345 needs something else included in the start(). The ITG3200 gyroscope and HMC5883L magnetometer are ok so the wiring is ok?
Please do not be concerned. I do not wish you to lose time re your work. Studying your code is a great help for me to learn SPIN2.
Many thanks,
Kevin.
Kevin, do you have another system (e.g. Arduino board) you can sanity-check your setup?
Referencing a guide (e.g. from Adafruit or SparkFun) might be a good, quick, tested way to get the module running. The library may also be a good reference for any power-up procedure gotchas (https://github.com/adafruit/Adafruit_ADXL345)
@kg1,
You're welcome, glad it worked. I have to nail down why the driver doesn't work with either of the faster SPI engines I have (after looking at it, I remembered that's why I hadn't used something faster with the adxl345 driver).
Spin to Spin2 conversion for PNut: in Spin:
Function1(para1=5)
In Spin2 compile error:
Expected "," or ")"
May I have default value for a function parameter in Spin2?
Comments
one way to solve this would be a P1 emulator on the P2 running P1 pasm as a XBYTE code interpreter. Simulating the counters and Video hardware might be tricky.
But basically the P2 is a different beast. A conversion of P1 objects makes no sense. As Jon stated a I2C object does not need a COG anymore, just a smart pin.
This is like 800xl vs MegaST or C64 vs Amiga. It simply makes no sense to translate P1 to P2.
OBEX seems to be closed anyways, the new GIT thing is not ready, we all can just post here and search here to do our experiments, but it is good like it is. We all together do the final testing, things are coming together, @rogloh with his video and hyperram driver, @Rayman with his tiled GUI, @garryj with USB, we are getting there.
And we have also the not infamous but famous @JonnyMac pushing out stuff faster then I can look thru it...
Mike
The good news is it is now compiling
FWIW by far the biggest bugbear is the adding of () to method calls.
All PUB and PRI now have () added when no parameters were passed, and all have a return parameter "result" declared.
eg PUB anexampleroutine() : result | anylocalvars
I came across these errors. Is the spin2 compiler meant to support these "constant" structures?
readWriteAppend := ("R" + (constant("W" - "R") & (findNumber(mode, "W", "w") or findNumber(mode, "A", "a")))) if( (fileOpenCloseFlag and (currentByte < 0)) or (not(fileOpenCloseFlag or (currentByte < constant(65_536 * 32)))) or .....BTW there are only a couple so I have made a CON equate for them. If it's a bug, no hurry for a fix.@Rayman SpinEdit? Please explain:
Will fastspin process and compile:
digits := ((encod value6) >> 2) + 1
error unexpected identifier "value6"
No more need for CONSTANT, since the compiler figures it out automatically now.
Chip, I thought the plan was to make Spin2 self-hosting on the P2. So wouldn't it make more sense to re-write the compiler in Spin2 rather than in C?
If you stick to the subset of Spin2 that fastspin/spin2cpp support then you could run the result through spin2cpp to get a C version. (Of course to make it work cross-platform you'd then have to re-write any PASM code in C, but it might be a way of killing two birds with one stone.)
Ideally one day we would have both options, but commercial developers may not want to only develop on the P2 board itself - which will of course be slower to build and likely a little harder to share online code vs a PC. A general purpose SPIN compiler tool written in C should be very portable and enable development on the widest range of systems, Linux/Mac/Windows/RasPi etc. Being a command line tool it really needs a filesystem however so if this C codebase is ever ported over to a P2 its environment will need that capability built into it as well, perhaps using p2gcc + filesystem extensions and an SD card, or your flexC if that suits, or some other future C compiler for the P2.
just my 2c
My thinking was to have the P2 self-hosting, but of late I'm wondering if people really want to dedicate a monitor, keyboard, and mouse to a P2. I kind of imagine they want to stay on whatever platform they have that provides those things, already. So, self-hosting is kind of morphing into quasi-self hosting, where maybe the tools are running on the chip, but the interface is whatever they've already got that they would like to keep using. It's for this reason that I've been looking into what it would take for the P2 to present a web-page interface to ANY host. Things are in flux at the moment because of this.
Chip,
If you use a standard I/O routine (via hub) for your compiler, then another cog(s) can take this I/O and, either use a serial port to a PC/etc, or a VGA/HDMI with USB/PS2 keyboard. If you use simple cursor controls (cls, home, crlf) you have removed any complication. Then it's a simple matter to substitute the other cog code to drive the keyboard/screen wherever it may be. I did this in my P1 OS quite successfully.
I have a dedicated monitor (actually a 19" lcd tv), keyboard, and mouse with an Odroid and P1 mounted on the back of it. The Odroid and P1 are connected serially, and the keyboard/mouse and video can be independently switched between the two boards. Works really well for debugging master/slave code. A self hosted P2 master and P1 slave would be a great combo imho.
Hi Jon,
I am trying to use your code jm_i2c-7bit_scan.spin2
I think the printing is missing every second column in the table. There are three sensors on a GY-85 module and the adxl345 should show A6. See attached file: I have forced the A6 to print to proved that it is detected but in the original code it does not appear in the table. I just cant see the source of the error.
Kevin.
%DDDD_AAA_X
...using binary notation, where DDDD is the device type (e.g. $Ax for EEPROM), AAA is the device address (%000..%111) -- this is where we get the 7 bits. The slave id also has a Read/Write bit (X), which is always treated as 0 in this scan.
Here's the working code:
repeat device from $01 to $0E ' loop through device types term.fhex(device << 4, 2) ' print at start of line term.tx(" ") repeat addr from 0 to 7 ' loop through addresses slaveid := (device << 4) | (addr << 1) ' build slave id if (i2c.present(slaveid)) ' ping the device term.fhex(slaveid, 2) ' if found, print slave id term.tx(" ") else term.str(string(".. ")) ' nothing at this slave idNote that device types %0000 and %1111 are not valid, so the scan goes from $01 (%0001) to $0E (%1110). An inner loop iterates the address of each device from 0 (%000) to 7 (%111). This line is key: ...as it builds the slave id as up above -- what we get is %DDDD_AAA_0. This is the format required for my I2C objects (and will be found in most I2C documenation). When you want to read from a device you OR the slave id with 1 to set it into Read mode.If you've come from the Arduino world, they do things differently. That system truncates the RW bit and uses the 7-bit value directly. Under the hood, they shift that value left by one bit to make room for the RW bit. I always strive for obvious code, and most data sheets that I've encountered use the %DDDDAAAX format (the ADXL345 docs show both).
You have two devices on the I2C bus -- do they match your expectations? If yes, I think you have a connection problem or bad device (I just went through that the other day with an I2C pulse/ox sensor).
Edit: Since my name has been sullied (grin), I did a bit of research. It looks like the GY-85 module has the ADXL345 and an ITG-3200. According to the docs, the default slave ID for the ITG-3200 is $D0 which shows in your scan. I wonder if the $3C that is showing is your ADXL345? According to its docs, it should be fine with 400kHz, but maybe that device is having a problem.
Do me a favor: Put my code back the way you found it, and then change the I2C bus frequency to 100kHz (standard) to see if that makes a difference. You need to change this line in the setup() method: The 3rd argument is the bus speed in kHz. You may need to experiment with the pull-up setting (4th argument) as well.
pub wait(slaveid) : result | ackbit, num '' Waits for device to be ready for new command. num := 0 repeat ++num start() ackbit := write(slaveid) until (ackbit == ACK || num == 2) result := (ackbit == ACK)which does two writes for each slaveid (perhaps wakes up the ADXL345) it gives the output as attached consistently::I will assume the ADXL345 is faulty and find an alternative to experiment with.
I was not trying to find fault in your code. I really should have found a schema for the GY-85 as I could not follow: Kevin.
Did you try 100kHz? Yes, I have seen the docs that the device supports 400kHz -- but I'm betting your connections between the P2 and the device are less than perfect; this is why I suggested the slow down. If that works, then you can bump the speed until you find the limit of your setup. Remember, I2C is synchronous so it doesn't have to be 100 or 400, you can set it to anything you want.
It seems completely illogical that an IMU device would require two queries to get it going -- this defeats the point of the device providing positional data for a real-time system. It doesn't happen often, but sometimes we get bad devices. A little over a week ago my friend Rick dropped off a pulse/ox sensor for me to play with. I connected it to a P1 (his target) and it didn't show up, even though the P1 EEPROM did. Under I microscope I found all kinds of problems with bad solder joints and components that were touching each other (this appeared to have been assembled by hand). We exchanged it with Amazon and now have a working device.
Note that there is a method called present() in the I2C object. The point of this method is to detect a device, after which the wait() method (which has no timeout) is useful.
The 7-bit vs 8-bit address thing seems to be troublesome for you, so I have attached another version of my I2C scanner -- it shows the detected devices and their addresses in both formats. It also allows each device to be pinged more than once (though I think this is unnecessary). In the screen shot you can see it detects two chips on the same PCB; $AE is an EEPROM, and $D0 is an RTC.
Note, too, that I've made updates to my serial library so you should replace what you have with what's attached (2 files associated with serial).
Please do not be concerned. I do not wish you to lose time re your work. Studying your code is a great help for me to learn SPIN2.
Many thanks,
Kevin.
Referencing a guide (e.g. from Adafruit or SparkFun) might be a good, quick, tested way to get the module running. The library may also be a good reference for any power-up procedure gotchas (https://github.com/adafruit/Adafruit_ADXL345)
Thank you Jesse.
You're welcome, glad it worked. I have to nail down why the driver doesn't work with either of the faster SPI engines I have (after looking at it, I remembered that's why I hadn't used something faster with the adxl345 driver).
Function1(para1=5)
In Spin2 compile error:
Expected "," or ")"
May I have default value for a function parameter in Spin2?