-
But in any case, sorry for bringing that up again, but relying on a specific execution time on modern CPUs is something to be avoided. At worst, it won't work, and at best, it will just look like tinkering. If all you need is some *minimum* delay, then sure, it's fine (as long as you don't rely on instructions that may never get executed...
) But anything accurate and reproducible? Use appropriate resources in your MCU, such as timers, or other peripherals - if you typically need to bit bang GPIOs with accurate timings, there's usually a peripheral that will do this for you. If there isn't anything that quite fits (for instance, because you need to toggle some GPIOs with a specific timing relationship relative to, say, some SPI peripheral), there are now many MCUs out there that have a peripheral chaining ability (called in various ways, usually under the name of "trigger" something), with which you can trigger a peripheral from another one. So for instance, you can configure your MCU to trigger a SPI transfer from a PWM output, for instance, which you could use in a single-shot mode. Read datasheets, and use hardware features as much as you can when accurate timings are involved. Or use an old 8-bitter with 100% predictable and reproducible timings down to the cycle for any operation. Your pick. =)
-
When counting clock cycles and proving cycle accuracy, we often fail to see the forest from the trees: the fact that actual time, in seconds and not clock cycles, is all that matters, and in physical world, jitter and uncertainty is always there, we just need to define what we can accept. Even XMOS has jitter, just maybe ~2-3 orders of magnitude less than a bare metal Cortex M7 application, which again has maybe ~2-3 orders of magnitude less jitter than one written by inexperienced trainee using example codes and libraries.
There are two fundamental granularities of jitter relevant here:- algorithms with variable execution times, e.g. think malloc/free
- variable numbers of instructions/clocks, e.g. due to data variability, caches, or interrupts
- jitter in the clock period
You are less likely to get algorithm problems with a hardware implementation, but it can be acheived!
Jitter in the clock period is often introduced intentionally, to minimise EMI problems.
The XMOS xCORE xC devices avoid the cache/interrupt/data problems, by apprropriate architecture and implementation. Hence they can be regarded as:- showing what mainstream technologies fail to achieve
- offering some of the advantages of traditional software and hardware technologies
-
Well they do go all out to make it confusing, having declared the minimum low time to be 80µs when checking the busy flag they then state that the clock cycle is to be 1.2µs so it's also a 2 speed clock based on what you are doing.
I agree it seems confusing. I've only had a relaitively quick look at the datasheet, so could easily be confused/wrong, myself. But I attempt to explain why there are fast, around 1MHz/1µs elements, and much slower 80µs/1ms/100's of ms timing things.
The 'fast' (if you call 1MHz/1µs fast these days!) timings are the actual hardware interface timings itself. Which seems to prefer to have a clock which is regularly active. I.e. some kind of low level serial/parallel etc, hardware peripheral chips.
The much slower timings, such as the 80µs, for the busy flag to be active. Are probably the (worst case scenario, with suitable active clock(s) and active enable signals) time the displays internal MCU and/or graphics cpu/hardware takes (via software/microcode/hardwired-graphics/character-functions), to perform the requested tasks.
E.g. 80µs to set/reset the busy flag, or many milliseconds (and much, much longer) to perform more complicated display functions.
Originally I thought I would have to run a display update every so often but I had not realized that the enable is a clock ani may just run, I thought it was just an enable to signal that the but had valid data. If the clock is to just run then the timing is not an issue anymore as I just send a PWM signal that is only fast enough to achieve the required refresh rate. Given the slow speed the bus needs to work at the time taken to run it is minimal to the overall program so it can run continually. I can of course run in bursts by disabling the counter between refreshes. -
what is confusing is pages 27 and 28 versus page 30. 27 is the 4 bit mode, very clearly the clock is shown to be unequal in high/low with emphasis on the low time after the display has started executing the instruction so that the data is asserted and the busy flag returned. In the 8 bit mode it shows equal high/low periods with again emphasis on the time to wait for a valid busy flag. this delay is a whopping 80µs, but coincidentally the data setup time to read data is 80ns which I assume is what you would call this period. the data is accepted and the bus interface sets the busy flag.
The issue would be that if the busy flag is checked less than the 80µ/ns later it would not yet be asserted so the MPU would think the display is clear to take more data when it is just starting to respond to the instruction.
Then going to page 30 you have the diagram of timing of sending data with the timings table on page 32. This is where the data hold time is shown in ns and the whole clock cycle is said to be 1.2µs. It really feels like there is an error.
assuming these displays were meant to work on a standard bus with other devices surely the Bus master cannot be expected to change the clock just to suit the display. I take this to mean that the clock must have a cycle time of at least 1.2µs or no more than 800kHz.
What is also evident is that the clock being the enable cannot be free running to every device on this bus so presumably and given it's name "enable" the clock was akin to the CS pin on SPI devices but it doubled up as the clock. I assume there was some address multiplexer in the system that the bus master would put an address to and that would route the clock to the desired device.
Is there a standard anywhere for this bus? -
what is confusing is pages 27 and 28 versus page 30. 27 is the 4 bit mode, very clearly the clock is shown to be unequal in high/low with emphasis on the low time after the display has started executing the instruction so that the data is asserted and the busy flag returned. In the 8 bit mode it shows equal high/low periods with again emphasis on the time to wait for a valid busy flag. this delay is a whopping 80µs, but coincidentally the data setup time to read data is 80ns which I assume is what you would call this period. the data is accepted and the bus interface sets the busy flag.
The issue would be that if the busy flag is checked less than the 80µ/ns later it would not yet be asserted so the MPU would think the display is clear to take more data when it is just starting to respond to the instruction.
Then going to page 30 you have the diagram of timing of sending data with the timings table on page 32. This is where the data hold time is shown in ns and the whole clock cycle is said to be 1.2µs. It really feels like there is an error.
assuming these displays were meant to work on a standard bus with other devices surely the Bus master cannot be expected to change the clock just to suit the display. I take this to mean that the clock must have a cycle time of at least 1.2µs or no more than 800kHz.
What is also evident is that the clock being the enable cannot be free running to every device on this bus so presumably and given it's name "enable" the clock was akin to the CS pin on SPI devices but it doubled up as the clock. I assume there was some address multiplexer in the system that the bus master would put an address to and that would route the clock to the desired device.
Is there a standard anywhere for this bus?
I think what is causing confusion, is the fact that the E clock, is performing TWO roles here. One role is that it needs to be pulsed/clocked, to 'clock' the data into the chip(s)/display. Which for 4 bits, seems to require, two complete (high/low) clock cycles, so that it receives the entire 8 bits.
But for 8 bit interfacing, it only needs one such high/low E clock cycle.
Then it moves into the, what they call/show as INTERNAL OPERATION - FUNCTIONING part of the datasheet timing diagram (but which I have been calling the displays MCU/GPUs internal software/microcode part of the delays).
The other E clock function, is that it mostly needs to be kept low, while the (displays software) INTERNAL OPERATION - FUNCTIONING, is running. With the exception that in order to check the busy flag status, you need to send further commands into the display, in order to determine when it has finished its internal processing (software).
tl;dr
So yes, the E clock does need to be mostly low, while the INTERNAL OPERATION - FUNCTIONING (I'm intentionally trying to use the same terms as the datasheet, as if I keep on calling it internal software operations, I might also cause confusion). Except when you are clocking the E line, to check for the busy flag to eventually become clear (finished, ready for more commands).
I don't think there are errors in that datasheet. It is just that it gets rather confusing, because some of the timings are about physically getting the 8 bits of command data (which needs a pair of 4 bit operations, in 4 bit communication methods), into its internal peripheral chips/registers etc, and so are fairly quick, such as 450ns or 1.2µs. But, it then goes into (what they are calling the) INTERNAL OPERATION - FUNCTIONING bits. The timings become considerably longer, because you are waiting for the internal mechanisms inside the display (mcu(s), simple graphic processors etc, and their internal software), to process the information for you, which can take quite a while, such as 80µs, or many milliseconds. -
No it's not that simple I am afraid. Looking at the busy flag check timings it is clear that as the data goes in on a falling edge it takes time to register in the displays controller. Only once it has registered can the same pins that were just used as inputs now give an output as the data 7 pin sets the flag.
As you can see from the busy flag check diagram the "functioning" starts with the clock/e going low, there is then a minimum delay of 80µ/ns and then it may go high. surely this timeframe is needed for the data on the lines to be transferred into a latch in the display controller to be held onto once the clock goes high and data is then sent to the screen.
As soon as the clock/e goes high again and the data is latched D7 may now be used as the flag output and instantly goes high, I saw somewhere that the flag setup time is "0".
It looks like the flag is asserted when the clock is high but does not read when low so the time to read the busy flag is during the high part of the clock as the flag asserts on it's rising edge, but it has to see a clock rising edge. If you compare the "functioning" to the busy flag you can see that the flag does not change until the rising edge of the clock.
So the real time critical bit is making sure that the clock is low for long enough to latch the data, which I would have thought is the 80ns data setup time in the table on page 32.
The entire instruction is usually executed in 37µs which is why having just one little period of the whole cycle lasting 80µs which is over twice that time seems odd.
Looking at the data transfer diagram the 80ns setup time is the time between the data appearing and the clock going low for it to be latched in. So maybe what they are trying to convey is an 80ns time of valid data before and after the clock falls (which may take 25ns).
Back at the busy flag checking diagram they show multiple clocks happening during a "functioning" period which is usually 37µs, but these are the clocks that have to be something like 160µs but that in the timing table must be at least 1.2µs with at least 460ns of high time but no spec on the low time so if the 80 is ns not µs that could be a 1120ns high time and a 80ns low time which seems silly anyway as I would run on a 50/50 clock.
So i still do not see where the 80µs comes from as it is so much longer than all other timings not to mention equivalent to 6.25kHz when the display controller is working at 270kHz, I think this alone shows that it's an error. In the time to do a 50/50 160µs cycle the display controller has done 43 ticks, if it's going to un-assert a busy flag you would think that would happen well within a couple of ticks. The 37µs instruction execution time is 10 clock cycles of the display controller. -
I thought these displays could all be traced back to the 35+ year old HD44780. I have seen differences in the timing specifications, but such differences were improvements on the original, such that something designed to work with the HD44780 would be guaranteed to function on the look-alike (but not necessarily the other way around). For example the HD44780 setup time for RS and RW to be valid before raising E had to be a minimum of 140ns, while for the later Samsung KS0076 clone, this setup time could be as low as 40ns (and I note that for this ST7066U the figure is 0ns).
So I always thought it safest to design according to the ancient HD44780 specification. However I'm a bit surprised to find now that may not always be a good idea. I see that this ST7066U has minimum E cycle time of 1200ns, while for the HD44780 it was 1000ns.
Unless this display is really totally different to HD44780 (I did not look that closely) then there is no reason to have a continuous signal on E (there is a minimum cycle time, but no maximum). Nor is it necessary for the high and low times of E to be different, so long as the high time is at least 140ns, and the cycle time at least 1200ns. -
The 37µs instruction execution time is 10 clock cycles of the display controller.
Yes, it is, I agree. Now taking some of your other points, one at a time:QuoteNo it's not that simple I am afraid
I agree.QuoteThe entire instruction is usually executed in 37µs
IF the F.osc or F.ext (whichever you are using), is exactly 270KHz, then it is 37µs. But at the minimum allowed F.ext (and clock frequency) on the datasheet, which is shown as 125KHz, datasheet, near top of page 32, then it would be 80µs.QuoteSo i still do not see where the 80µs comes from as it is so much longer than all other timings
Remember the 10 clock cycles you just mentioned (last bit of your post), and the 125KHz minimum external frequency (clock F.ext (look at OSC1, OSC2 pins), NOT to be confused with the E signal). 125KHz = 8µs x 10 clock cycles (see bottom of your own post) = the 80µs minimum time.
Unfortunately (I'd prefer it, if the datasheet was considerably easier for everyone, to understand), many of the timings it mentions, are actually dependent on the actual F.osc or F.ext clock frequency, which has defined min and max limits, page 32 of datasheet. Page 8 seems to mention the OSC1, OSC2 stuff.
Once you have a specific circuit (schematic) defined, and know the component values, you will know what
F.osc or F.ext are and/or can set them by programming (or changing component values) of your unit, to make them what you desire them to be. I haven't looked into that part of the datasheet, have no idea what schematic and/or hardware you are going to be using, so can't really speculate on what OSC1, OSC2, F.osc or F.ext, are going to be for your stuff (unless I've missed it, in the rest of this thread).
There is a 80ns, you keep on referring to, but that is the data setup time, T.DSW, Which is about setting up data, ready to write into the chip, rather than the busy flag timing. -
This chip is used on a display module I am using from newhaven. I'm not actually putting this chip on a PCB myself or making any of the functional choices, but the newhaven datasheet refers to this one.
Yes the datasheet is crap! they talk about a 2MHz MPU bus speed on the first page but then hey that is 500ns, so still this 80µs seems to make no sense other than taking into account the 10 cycles at the lowest theoretical speed. So they don't want the clock to be high all the time but it must not be low too long, it goes round in circles. The 2MHz is clearly bollocks as the timing clearly states a 1.2µs cycle which is 833kHz not to mention the 6.25kHz speed if we use the 80µs figure. The datasheet seems to assume 270kHz as the usual speed. I have been refering to the timings at 2.7V when I am actually using 3.3V, timings at 5V are much faster.
I now question the cycle timing figure that is shown as a minimum, maybe they meant maximum but put it under the slower clock it relates to (time is the inverse of frequency). I just don't get it, they just made this shit up, the clock timings are just totally irrelevant. All they needed to say was that each instruction takes "x" cycles (10) to complete and that this is about the time to clear the busy flag. But they show multiple 80µs cycles so it's all bollocks unless that diagram relates to the couple of instructions that take 1.5ms to complete. but why the need to wait 2 display instruction cycles? if it's busy it's busy, that is the point of the flag, you check as often as you like one the data is latched, this is the only time you need to make sure you don't screw the timings and fail to assert the data. -
The original hitachi driver datasheet: https://www.sparkfun.com/datasheets/LCD/HD44780.pdf does not seem to mention the delay for checking the busy flag. But they mention that for 4 bit operation 2 cycles are needed to check the busy flag.... So this delay may still be a thing but now it is unmentioned, so there is a particular clock cycle that is done one pulse at a time, then there is a delay between pulses, my what a flipping mess this looks like. Now I know why I really wanted the serial displays but they were all sold out.
I take it no one knows if anyone ever wrote a library in C for these displays? you know one that can actually be understood with instructions? -
This chip is used on a display module I am using from newhaven. I'm not actually putting this chip on a PCB myself or making any of the functional choices, but the newhaven datasheet refers to this one.
..
..
<SNIP>
Yes, I agree (with way too many of your points in the full version of the post I said '<SNIP>' to save space, to list them all). Some of the timings do seem to be at a minimum, significantly confusing, or even ambiguous, the longer I think about it.
It does look rather confusing (the datasheet), and makes me suspicious, that they did a rushed job, copy and pasted stuff from other sources (hence the strange references to 2MHz you speak of), and other issues.
I wish they would properly name the multiple clock types (ones related to the E cycle transfers), and ones related to the internal clock (OSC1/2, F.ext etc). Then they could cause less confusion. -
The original hitachi driver datasheet: https://www.sparkfun.com/datasheets/LCD/HD44780.pdf does not seem to mention the delay for checking the busy flag. But they mention that for 4 bit operation 2 cycles are needed to check the busy flag.... So this delay may still be a thing but now it is unmentioned, so there is a particular clock cycle that is done one pulse at a time, then there is a delay between pulses, my what a flipping mess this looks like. Now I know why I really wanted the serial displays but they were all sold out.
I take it no one knows if anyone ever wrote a library in C for these displays? you know one that can actually be understood with instructions?
The problem is that the Hitachi chip was designed to interface to a processor that's no longer used. I don't think Hitachi even makes the chips any more. It's all clones. And it's inertia that keeps these things in production, even though driving them with a modern chip is a pain.
And yeah, I wrote a C library to talk to them, for SiLabs 8-bit parts. Obviously that bit-bang can't be directly translated to an ARM.
You mentioned that you were going to use a display with a serial interface, but those become impossible to find. I think there's a reason why you can still buy the parallel-interface parts ... -
I tried googling for more explanations on the chip, for you. There is not much, but I did find this:
https://electronics.stackexchange.com/questions/535092/programming-an-lcd-interface-with-a-st7066u -
I tried googling for more explanations on the chip, for you. There is not much, but I did find this:
https://electronics.stackexchange.com/questions/535092/programming-an-lcd-interface-with-a-st7066u
The point made in a response to that post about reading the Busy flag is spot on. -
... The 2MHz is clearly bollocks as the timing clearly states a 1.2µs cycle which is 833kHz not to mention the 6.25kHz speed if we use the 80µs figure.
...
Besides the 80µs, which I agree is crazy, I suspect the 2MHz bus cycle claim may be correct, and it is the min cycle time that is bollocks. Probably should be 500ns, as it is for say KS0076. -
... The 2MHz is clearly bollocks as the timing clearly states a 1.2µs cycle which is 833kHz not to mention the 6.25kHz speed if we use the 80µs figure.
...
Besides the 80µs, which I agree is crazy, I suspect the 2MHz bus cycle claim may be correct, and it is the min cycle time that is bollocks. Probably should be 500ns, as it is for say KS0076.
The problem I start to have here is how can the MPU bus be 2MHz when the display controller clock es always 270kHz or there abouts? I can only assume they are trying to say that the chip will tolerate the timings of 2MHz for the sake of other chips on the same bus but in fact if the 80µs is anything like true then unless you want to keep messing about with re-timing the clock cycle by cycle you may as well call it 6.25kHz, but if you have to run the clock at 6.25kHz then that's not 2MHz as nothing else will move any faster than the clock. -
You mentioned that you were going to use a display with a serial interface, but those become impossible to find. I think there's a reason why you can still buy the parallel-interface parts ...
Yes quite. I thought the time to write the parallel interface would be no worse than the hassle in dealing with getting serial stock. I think I need to look for serial stock and get it pre ordered. -
And yeah, I wrote a C library to talk to them, for SiLabs 8-bit parts. Obviously that bit-bang can't be directly translated to an ARM.
You mentioned that you were going to use a display with a serial interface, but those become impossible to find. I think there's a reason why you can still buy the parallel-interface parts ...
Yea I had a go with peter fleury's library having felt rather pleased with myself for adapting it to work on the new mega micro-controllers but arm is totally different and I would rather avoid the delays so it all needs running in an interrupt.
I'm thinking that I I interrupt on the overflow of a counter, have a variable that represents the state I am currently in and therefore directs to the next stage I need to carry out. Yes quite the mess. If I do this rather than do actual PWM for the clock I can adjust the timings to suit. Speed is not really a goal here, as long as I can round robin the display fast enough and the main code will run in between that. -
... The 2MHz is clearly bollocks as the timing clearly states a 1.2µs cycle which is 833kHz not to mention the 6.25kHz speed if we use the 80µs figure.
...
Besides the 80µs, which I agree is crazy, I suspect the 2MHz bus cycle claim may be correct, and it is the min cycle time that is bollocks. Probably should be 500ns, as it is for say KS0076.
The problem I start to have here is how can the MPU bus be 2MHz when the display controller clock es always 270kHz or there abouts? I can only assume they are trying to say that the chip will tolerate the timings of 2MHz for the sake of other chips on the same bus but in fact if the 80µs is anything like true then unless you want to keep messing about with re-timing the clock cycle by cycle you may as well call it 6.25kHz, but if you have to run the clock at 6.25kHz then that's not 2MHz as nothing else will move any faster than the clock.
I'm not sure where the conflict is. Except for the case of reading the busy flag / address, it does not have to do anything at a 2MHz rate. It has only to latch the data (one or two chunks) and then has a leisurely 37µs to complete the operation (or way longer for some instructions). -
there is not much of a conflict width the 2MHz, I just assume it is copy and pasted BS. The enable cycle is said to be at least 1.2µs, that is no more than 833kHz, that is the fastest thing going. Then there is this 80µs wait time but that does not have to affect the overall clock timing for the whole bus as it just means the MPU must not send the clock for 80µs after the data is latched. but still the abs top bus speed here is 833kHz. I will probably run on something like 6.25kHz anyway, even with it taking 2 cycles to put a character on the display that is 78 refreshes a second which is plenty.
-
there is not much of a conflict width the 2MHz, I just assume it is copy and pasted BS. The enable cycle is said to be at least 1.2µs, that is no more than 833kHz, that is the fastest thing going. Then there is this 80µs wait time but that does not have to affect the overall clock timing for the whole bus as it just means the MPU must not send the clock for 80µs after the data is latched. but still the abs top bus speed here is 833kHz. I will probably run on something like 6.25kHz anyway, even with it taking 2 cycles to put a character on the display that is 78 refreshes a second which is plenty.
I agree that the datasheet is full of BS, but I'm still inclined to believe the 2MHz could be correct. That is not out of line with the specifications for other similar chips. The 80µs delay before reading busy is total codswallop imo. I've never seen anything like that specified for similar chips. Also, a perfectly valid, and very common thing with these displays is to not bother with reading the busy flag at all, but to just delay for long enough for the instruction to complete. Which for this chip, would mean either you wait < 40µs (most instructions), or else wait 80µs and then read busy - why on earth would you choose the latter? As for the 1.2µs cycle time, not only is that out of line with the 2MHz claim, it also makes it the slowest chip of this nature that I've encountered.
I'd be inclined to do as I usually do, and follow the original HD44780 timing specification, or if feeling adventurous, go for the 500ns cycle time. -
Well I will probe the one I have on an arduino board just so I know what definitely works. It's not a major issue but it's annoying. I would not provide data like this.