I2C actually doesn’t work. So it is not a good idea to recommend it. As far as I know SPI also has a bunch of bugs. And since Q2686 has only 2 UART it is useless without external processor in somewhat complex applications.
I don’t know which modules have more than 2 UARTs but I know that every module on market has at least 1 UART and much lower price. If used with external processor cost and extendability of the final device could be reduced dramatically.
My I2C code freezes after 10 minutes of using. The only difference is that on R7 it does not freeze the entire application - multitasking in action.
I’d love to see your I2C code to compare with. Probably wavecom’s I2C just does not work properly with clock stretching mode and the overall result depends on slave. Also I have not seen succesfull using of multiple slaves with wavecom module. Have you tried it?
With SPI I’ve heard rumors about CS problems. But I haven’t tried it.
so did my q2686 in I2C-comm
problems arose indeed with clock-stretching, wrong pullup-resistor values and also with disturbences in the 3v3 pullup voltage. (is still kills the whole processor even on R7.x)
i’m currently using 2 nxp led-dimmers (on th I2C bus).
I’ve only got one I2C slave - a Maxim/Dallas DS2482-100 I2C to One-Wire bridge. Haven’t tried clock streching as I didn’t need to. However, I have my I2C bus running through a bi-directional level shifter (the One-Wire stuff runs off 5V, and won’t quite run down to 2.8V. Sigh!) - so Q26 side of the bus is pulled up to the Q26 supplied 2V8, and the other side of the bus is pulled up (quite hard) to 5V. This may be why I haven’t seen the problems that Madouc is referring to.
My previous experiences with I2C on other micros was not all that great - had lots of problems with choice of pull-ups and track layout - especially with multiple devices, so tended to steer away from it where I could.
I had grief using the ADL_BUS_SPI_ADDR_CS_HARD option and ended up using the ADL_BUS_SPI_ADDR_CS_GPIO option for Chip Select. I then used the GPIO that corresponded to the CS pin on the Q26. Again, I only have a single device on the bus, and aren’t doing any mode or speed switching.
Getting all the bus stuff running was not all that straightforward - especially decoding what Wavecom mean when the API is talking about op-codes and addressing in the adl_busAccess_t structure. I spent a lot of time experimenting by sending data down the bus and staring at CRO screen captures to see what actually was happening.
I need to correct my own statement (since i now own a logic analyser, and i’ve seen clock-stretching happen on the i2c bus)
the current firmware (7.3) no longer freezes when something fales on the i2c bus, it reboots.
and this firmware seems to support clock-stretching (propably up to a limit.)
I’m not sure I understand what you mean with: “USB dies”.
If you “overide” TRACE macro and use an intermediate function that sends text to the USB port when you build as “release” and uses TRACE when build as “debug” it gives you valuable information. Of course you must initialize the USB service aditionally.
The problem of using Terminal Emulator is that some times is not easy to behave manually as the equipment you want to connect to the UART1.
I think USB is good for debugging and it also has enough speed, one advantage is that you can send AT commands as well through USB port.
Regading the USB restart issue. If the module restarts the windows gives a new handle for the device. But in case of a hyperterminal a simple close/reopen sequence is enough for proper working. The Selima and TMT is said to be to detect if the USB device is reconnected so it will able to communicate with device without intervention. Anyway, you can easily hear the USB reconnection because ot the sound produced by windows USB connect/reconnect event.
At least this is the case with the latest USB driver and the firmware 7.3, 7.3a. I have no experince about USB with previous firmwares.