just load Tachyon.spin and Extend.fth into your favorite editor and use SEARCH.
I am sure you can read some PASM plus the inline documentation.
A good place to start understanding.
And internally it obviously just is using WAITPEQ and WAITPNE and WAITCNT as you know them from PASM.

caskaz - As MJB said, look at the source. Since there are no conversion steps in creating the kernel you have access to all there is in basically two documents, TACHYON.SPIN and EXTEND.FTH. If you are looking for WAITCNT in the TACHYON.SPIN source you may search for "WAITCNT" in the dictionary and find its code name WAITCNTS and then search for that etc.

There are also the new help files being constructed for loading onto an SD card but are also handy for reference from your PC. Look in V4/HELP. If you open WAIT.TXT in the HELP folder you will see that DELTA is used to setup WAITCNT but often just perusing both sources gives you a good idea on how to use it.

I searched WAITPNE and WAITPNE in EXTEND.FTH.
But nothing except for alias.
[pub WAITPNE] and [pub WAITPNE] also are valid on V4r5?

There is not [pub WAITCNT] in EXTEND.FTH.
Maybe I think (cnt delta -- cnt).

I have the habbit to keep all the Tachyon files (.spin, Extend, File, NW ..) of the actual and some older versions (4.5, 4.4, 4.0, 3) open in NOTEPAD++ at the same time.
Then I do a search in all files.
So I can find hopefully all relevant instances and can easily compare new to old versions. So I see what has been changed by Peter recently.

@mjb - That's the trouble with the I2C standard, it was meant to be a bus to accommodate slower peripherals that might emulate the bus under software but some companies use the "bus" as a dedicated connection. Who would want the bus blocked for up to 15ms? Imagine if the humble I2C EEPROM did that? Thankfully EEPROMs do what you say in that they indicate they are ready when they ack their device address.

caskaz - as MJB pointed out, you don't need clock stretching with this chip, just restart after a read command and keep addressing it until you get an ack back.

No Clock Stretching
When a command without clock stretching has been
issued, the sensor responds to a read header with a not
acknowledge (NACK), if no data is present.

Clock Stretching
When a command with clock stretching has been issued,
the sensor responds to a read header with an ACK and
subsequently pulls down the SCL line. The SCL line is
pulled down until the measurement is complete. As soon
as the measurement is complete, the sensor releases
the SCL line and sends the measurement results.

Of course,I don't think clockstreching must use.
But SHT31's clockstreching cannot use on Tachyon's I2C-specification.
Many I2C-devices operate under current Tachyon.
But maybe I think some devices don't operate.

UM10204 Rev.6 I2C-Bus specification
3.1.1 SDA and SCL signals
When the bus is free, both lines are HIGH.
The output stages of devices connected to the bus must have an open-drain or open-collector to perform the wired-AND function.

caskaz - I've been using I2C ever since it replaced the 3-wire CBUS and it was originally called IIC - the Inter IC bus but later changed to I2C for trademark and IP reasons. Being familiar with how it is used and was intended to be used is helpful and specifications are quite correct when they say "to perform the wired-AND function" that you need open-drain. However most micros don't have true open-drain drivers since they use GPIO but they can simulate open-drain within reason IF they perform the wired-AND function that is. There is however no need for this arbitration if clock stretching and multi-master are not employed, the latter of which I have never seen used but was envisioned by the designers.

The use of clock stretching was not meant for the purpose that some manufacturers have (mis)used it for though, as some early I2C devices were based on slow micros and couldn't always keep up with the timing so in a clever way clock-stretching was specified. A bus implies that this is a common freeway that should not be hogged by one device but for many to use according to the rules. Polling a device until you get an acknowledgement is the proper way to use the bus but I do notice that some processors these days offer a multitude of I2C buses which doesn't make any sense really unless you dedicate the "bus" for single use.

I expect to modify setting to input-mode when SCL/SDA is High.
*SDA HIGH -> *SDA FLOAT
*SCL HIGH -> *SCL FLOAT
Maybe many i2c-devices don't occur trouble.
SHT31's clocksteching should also operate well although I think such function don't need to use.

On some Prop systems the SCL line does not have a pull-up fitted since it is normally driven from the master. I always say a pull-up on SCL isn't necessary but I almost always put one on it if I expect to interface to interface to some unknown chip other than the EEPROM although I have never had occasion to need it either. A pull-up/down in general is useful on Prop I/O because it allows the pin to be floated but still in a known state so that more than one cog can share an output.

btw - modification isn't impossible of course, but is it really necessary? Should we allow for multi-master and arbitration in general? Do we respond to general-call address even as a master? Most of the I2C specification is never needed in practice and seeing we have such limited resources we don't pile on unnecessary baggage unless there is some real advantage. Besides, I normally like to test this out so next time I order some chips I will get a few of these devices and test out the clock stretching mode on them although I probably would never use it in that mode due to the long delay necessary.

The terminal emulators I use support ANSI sequences which I use for some words but I decided to put in a test for ANSI capability at boot time and if there was a response to then allow ANSI. Hopefully simple terminals will only display a couple of garbage characters from the initial ANSI query and suppress everything ANSI thereafter although I encourage anyone using Tachyon to use an ANSI/VT100 capable terminal.

@Peter - you've been really eager so I gave IoT5500 a new try with v4r5. The case sensitivity thing is solved but still I have problems to change IP, SN and GW on the WIZNET 5500 chip.
I set myIP, mySN, myGW before and then I do which gives:

@Peter - you've been really eager so I gave IoT5500 a new try with v4r5. The case sensitivity thing is solved but still I have problems to change IP, SN and GW on the WIZNET 5500 chip.
I set myIP, mySN, myGW before and then I do which gives:

It seems that WCOLD doesn't write to the wiznet chip ?!
PS:
The ethernet connection is up, LED is on, but there is no gateway available

Thanks in advance, best regards,
proplem

could be this:
WCOLD refers to the constants defined in EASYNET.fth
if you define NEW constants, WCOLD still refers to the old ones.
So you need to change the values of the original constants with: AT .... hmmm - seems to be gone.

@proplem - smaller constants are simply symbols with only a header that embed the values into code at compile time so you can't change those ones at runtime but the constants that are great than 15 bits do have a code field that is called so it is possible to change these IP constants. However the default configuration rather than the default values themselves are meant to be overridden by the user application which determines if it needs to do that. My applications simply use SIP and GATEWAY but if you really want to you could change the constant itself. Bear in mind that structure of the constant is:
[CONL] [HIGH] [LOW] where the constant is encoded as 2 words in high low order so you need to split your new value into 2 words and write them to these fields. Otherwise just use SIP and GATEWAY.

However I noticed a bug there, somehow my constant in I2C100 got deleted so switching to this mode could switch to almost any speed. Here is what I think it should be but I will also check the timing at some point.

pub I2C100 CLKMHZ 3 / ~D ;

EDIT: I typed in 48 but what was I thinking .... try a lower value etc. I notice frida has a very long delay in there of 320 which is probably way too slow.

@MJB - I've been labeling private subroutines in the form ~x since V4 allows subroutines to be added and called efficiently. It doesn't matter that there might be routines named the same since it is only the most recent definition that would be referenced anyway. An optional RECLAIM can remove all the private headers to free up some memory without having to compact the dictionary into EEPROM.

@MJB - I've been labeling private subroutines in the form ~x since V4 allows subroutines to be added and called efficiently. It doesn't matter that there might be routines named the same since it is only the most recent definition that would be referenced anyway. An optional RECLAIM can remove all the private headers to free up some memory without having to compact the dictionary into EEPROM.

sure - only the most recent definition will be referenced in new code.

Mjb - last word in any real code is never private but reclaim hangs if it is as in your quick test. There's a bug to fix for sure but neither should it encounter it anyway. Don't forget there is a 3 missing in I2C100 but also that I2CFAST already falls through. Calls become jumps if they are followed by a ; making it faster and also does not compile the otherwise necessary exit opcode.

Mjb - last word in any real code is never private but reclaim hangs if it is as in your quick test. There's a bug to fix for sure but neither should it encounter it anyway. Don't forget there is a 3 missing in I2C100 but also that I2CFAST already falls through. Calls become jumps if they are followed by a ; making it faster and also does not compile the otherwise necessary exit opcode.

yea - missed that I2CFAST fall through ...

your introduction of CLKMHZ gives up resolution in selecting the division factor ...
but will usually be ok.