I2C bus speeds and the P2D2's UB3
Peter Jakacki
Posts: 10,193
This post is for those who are interested about I2C speeds. jmg has been incorporating the I2C slave function into the EFM8UB micro that I use for USB serial, but that I also want for support functions. To make it flexible enough, the P2 needs to be able to send it commands, and since I already have the UB3 connected to P56/57 as the I2C bus to configure the clock generator chip on power-up, it seems like the best way to communicate to the UB3. The master function at power-up is simple bit-bashed code, but a slave function needs to use the hardware and interrupts.
For testing, the UB3 I2C slave echos a pair of bytes it receives back onto its serial TXD which is connected to the P2 RXD as part of the USB<>serial operation. But will it work and how well and at what speed?
Normally 1MHz bus speed is considered fast and is what modern EEPROMs support, although standard speed is 400kHz, which was faster than the original 100kHz.
There is a 3.2MHz high-speed I2C bus speed but I haven't seen any chips use that yet.
Here are the scope captures of the P2 writing the two characters A and Z to the UB3 in an echo to serial test.
In one of the captures you can see it responding on the TXD trace #3 and it looks normal enough until you realize that the bus frequency is over 4MHz and very asymmetrical, with a SCL high of 50ns!
For testing, the UB3 I2C slave echos a pair of bytes it receives back onto its serial TXD which is connected to the P2 RXD as part of the USB<>serial operation. But will it work and how well and at what speed?
Normally 1MHz bus speed is considered fast and is what modern EEPROMs support, although standard speed is 400kHz, which was faster than the original 100kHz.
There is a 3.2MHz high-speed I2C bus speed but I haven't seen any chips use that yet.
Here are the scope captures of the P2 writing the two characters A and Z to the UB3 in an echo to serial test.
In one of the captures you can see it responding on the TXD trace #3 and it looks normal enough until you realize that the bus frequency is over 4MHz and very asymmetrical, with a SCL high of 50ns!
641 x 480 - 34K
640 x 480 - 34K
Comments
In another thread you mentioned the following commands, but it didn't include the EFM8UB flash writes. Is that even possible/useful? I'm thinking perhaps it could be useful if the P2D2 is already embedded in the field and needs a remote EFM8UB update for a bug fix etc and without needing human interaction by doing it over USB.
SERIAL COMS FROM P2 COMMANDS:
- RESET P2
- SD POWER ON
- SD POWER OFF
- SD POWER RESET
- READ VDD VOLTAGE (1.8V)
- READ TEMPERATURE
- READ VREF
- RETRIG/START WATCHDOG (off at reset)
(optional but easy to do)
- READ/WRITE SPI FLASH
- READ/WRITE SD FLASH
- READ/WRITE I2C
The P2PAL module is incorporating an XMC1100 chip that can take over from the UB3 support functions seamlessly if need be, at least for experimenting with anyway. But if UB3 can do everything we need or mostly need, then why complicate it.
All it takes to use these chips in P2 or P1 designs is the 2 pins for programming the chip which you could do from a cheap Silabs Thunderboard or similar, or from the P2 itself very easily.
I think the temperature sensing and SD power on/off are going to be pretty handy options, plus the controlled master reset out.
The UB3 temp sensing may come in handy with HyperRAM delay profiles when running in extreme temperature ranges. Even though it's separate to the P2 and HyperRAM at least it may give some chance of measuring something approaching ambient in the hope to compensate the timing...certainly much better than nothing at all.
There are no plans for flash writes in the near term, first objective is to get the simple stuff working reliably
The UB3 is also intended to be a stable USB-Serial support platform, so unlikely to need remote 'hands off' updates.
The UB3 ships with a USB Bootloader, (tie pin low to boot) and that should be enough to update firmware, plus it has C2D ISP on all parts.
The bootloader has a special vector support, which allows you to erase and pgm the lower flash, whilst any user-pgm-flash has risks you erase that code and brick the part. Best avoided.
If someone really wanted P2 managed remote firmware updates there is an i2c boot option order code for the (non USB) EFM8LB1, so it may be possible to swap out USB boot code for that i2c boot code, but doing that would need a C2D programmer pass to erase/replace the bootloader areas.
The watchdog in the UB3 for the P2 is one of the more important commands that I wanted the I2C slave for (but it was missing in the list I posted). Normally it would not be operating but as soon as an application writes a value to it, it must continue to be retriggered to prevent a reset. In that event the UB3 would also maintain a status that can be read by the P2 to indicate that there was a watchdog reset. The watchdog timer can also be read which is useful for diagnostics and in determining an optimum timeout value.
I've already put clock stretching in place in the primitive that generates and times the SCL. It will still drive the SCL high for speed, but float it immediately afterwards to allow the pull-up and contention logic to do its work.
Close, but not quite 'hit 3.2MHz'. Certainly, small MCUs are cheaper than many peripherals these days.
The UB3 has a newer, improved i2c peripheral, which is spec'd to 1MHz and seems to go above 3MHz
The older & simpler EFM8BBx series have a slower i2c block, which the data specs to 256kHz max to strictly meet timing specs on 400kHz parts.
Perhaps, but the prices are about the same. Take your pick
There is also this available in UB3, which may be useful ? :
"A 128-bit universally unique identifier (UUID) is pre-programmed into all devices. The UUID resides in the read-only area of flash memory which cannot be erased or written in the end application."
cool.
Mike
The MCP3208 costs around $3, the EFM8UB3 costs less than half of that and is also available in a QSOP24.
For A/D work I find it is easier to program these chips to do continuous conversation so that the host only needs to issues reads. With the UB3 that can be read via the I2C in this application but in other applications I would program it to send the data continuously over the serial so that the P1/P2 would only need to listen on a single line.
I just tested the updated I2C routines, those are not working with my sensor and they're missing a timeout @ the clock stretching phase so if nothing is present on the I2c line and there are no pullups (that of course depend on the design) the driver stalls. Do you prefer to move these discussions somewhere else?
Thanks anyway for the updated code, I'm checking out your Dropbox folder on a regular basis
If your SCL is P56 try this:
56 PIN 1K5 SOURCE FAST SINK 0 WRFNC
or if P56 and P57 are I2C then:
56 2 PINS 1K5 SOURCE FAST SINK 0 WRFNC
Maybe it won't work when the code goes to float it, but I will update the code shortly.
I was actually in the process of enhancing all these pin config functions to make them even easier and so the I2C routines will incorporate pullups in the code that will also switch to 1k5 at high speeds and always have some pullup there in addition to any external pullups.
The new code lets you config a pin this way:
56 2 PINS 1K5 PU CMOS SINK SETPIN
May I interrupt this P2 discussion for a P1 question? Could your UB3 version be used as a USB port and A/D converter for a P1?
Jim
Absolutely, this chip is available in QSOP24 as well as QFN so it can even be hand soldered if need be. I have used Silabs C2 2-wire programming interface with the Prop chip since the early days and have used Silabs chips for A/D mainly. I will probably make a small USB serial board with this chip as well that can connect like a Prop Plug.
The problem with the simple 4-pin Prop Plug connection is that it doesn't allow for +5V or other signals but what I do besides having an extra pin in that row anyway, is to have another row of 4 pins which I normally use for +5V and I2C. Most of my pcbs don't have dedicated USB serial, they simply have this 4x2 right-angle header that I can plug a serial cable into and also power the board, or run a cable from the board to a I2C front-panel plus coms.
sounds fantastisk, would the board then have solder points to connect the analog inputs?
Jim
UUID via i2c is in testing ...
The i2c Analog read now supports an address parameter, so reads eg Temperature at =16, and various other pins/ internal rails / VREGIN etc over the ~30 possible values UB3 supports.
Then jmg spotted some level contention on the clock line, the P2 was fighting the UB3, but the P2 has fairly strong drive, so it was barely noticeable (I didn't notice it at first), but it was there. Just a few more I2C commands to go now that these bugs have been sorted out. (It had been too slow going working back and forth with emails all this time, the google doc made it short work and fun)
This is the console interacting with the UB3 hardware as well as listing all "32" A/D channels along with labels and actual voltages.
I wanted to at least use a chat window but jmg likes emails, but they are like posting little letters, and then when you need to add something, you post another letter and so on. Plus it is really hard to see the flow of the conversation. Then I figured I could do up a Google doc to document the UB3 commands etc and at the same time turn it into a chat page as I have done in the past. I think we got more done in a day then we did in months of emails.
The trouble with video and voice is that you aren't as free to go and check something etc and can sometimes spend a long time chatting, as you and I well know with the long nights during ROM development with Chip on Skype
The UB3 loads the Si5351A clock generator during P2 reset and now supports multiple tables that can be selected with an option byte in the firmware. The default is to generate a 20MHz clock from a 25MHz but a second table is for 26MHz oscillator to 20MHz use, and other tables can be added. Of course, the Si5351A can be loaded during runtime as well which is already supported in TAQOZ.
The I2C watchdog is working well and starts up inactive but once loaded with a timeout value it will count down every 5.12ms and reset the P2 unless reloaded or if the firmware option is set, you can disable it again by writing a zero. You can also read the watchdog timer which is handy for measuring timing limits within code and determining a more secure or optimum timeout.
There are a lot of other features and for now I will be wrapping up the hardware side with fairly minor changes after this whole exercise. The main thing is that the UB3 is up to the task, and the I2C bus runs very fast, as does the USB serial at 8Mbd. The artworks are finally getting away this week and I will be pushing for a speedy turn-around. Normally the pcbs would be delivered within days, and hopefully I won't have to wait too long.
But while I was busy testing things I also took some time off in the past 24 hours and wrote DASM51, a disassembler for the 8051 core of the UB3 in the hope that I can modify and reassemble this listing on the P2 itself. The disassembler is written in TAQOZ and despite the fact that it has a huge table of SFR adresses and names, still only takes up about 3.5kB of code and only a handful of bytes in the dictionary. It tracks references and generates labels accordingly and has some basic data area recognition as well. This is still a fairly basic version but very handy and much better than all the many disassemblers I've tried on the PC, including Ghidra (well, at least for this purpose).
BTW, DASM51 is reading the code directly from the UB3 via the I2C bus!
Here's a sample of the output of the 8051 disassembler at the end of the main code section in the UB3. The listing has the PC and machine code turned off so that it produces a clean source ready for modifying and assembling again.
_28F0: MOV WDTCN, #$DE MOV WDTCN, #$AD RET _28F7: MOV R0, #$7E MOV A, @R0 MOV R7, A LJMP _22EB _28FE: MOV SFRPAGE, #$10 MOV A, EIE2 RRC A _2904: RET _2905: DB $1A, $03 DW "Silicon LaBS" DB $4C, $03 DW "EFM8UB3 P2D2v4 USB Bridge UB3_2.5.6 " DB $0A, $03 DW "0005" ENDand this section which is checking for an I2C command of $C0 and selecting an ADC channel to read
_1D6D: CLR $20.6 CJNE R7, #$C0, _1D7B _1D72: MOV A, $67 ANL A, #$1F MOV ADC0MX, A SETB ADC0CN0.4 _1D7A: RETYes, I have a more detailed reply I am sending to ErNa shortly.
I've updated DASM to handle input from any source, specifying the source the same as we do for DUMP. Still only 3.5k code. Obviously the RTC is not a good source, but SD or Flash or RAM is.
TAQOZ# FOPEN UB3.ROM Opened @125452 --- ok TAQOZ# 0 10 SD DASM --- RESET: _0000: LJMP _187E TIMER0_INT: _0003: MOV DPTR, #2 MOVX A, @DPTR ORL A, #1 MOVX @DPTR, A _000A: RET AJMP _01B0 _000D: MOV DPL, R5 MOV DPH, R4 _0011: MOV R6, $07 END ok TAQOZ#But I've lost the schedule now. When do you think the P2D2 will be available in Europe?