Would you release this or not?
-
Sorry, I'm not sure where to put this question, but I'd like opinions. I have a graphics library, primarily targeting IoT devices. It has drivers for several displays. The drivers could be faster, tbh. All of these drivers communicate over SPI (well there are I2C ones too but forget those for now). For those of you that don't know, SPI is a serial wire protocol that came about in like the 1980s or something. Your SD cards are SPI "slave devices" I wrote a parallel driver for displays that support it. That means 8 data lines instead of one. It's not 8 times as fast, for hardware reasons, but it's much faster. Anyway, I also refactored my new driver code so that it's layered, separating the concerns of driving the bus (either parallel or spi) and operating the specific display chip (like an ILI9341 or an ST7789) The problem is this: I've optimized the SPI code in this new version and it only works on certain boards. There are timing issues. It's probably too fast, but I've had no luck getting it to work reliably. It only displays part of the tests, and then it freezes on most displays. As far as too fast, maybe the CS line control is too fast - it's not simply the SPI rate. I've tried changing that. For example, there's something called VDI rail that somehow needs more time to register a line change. I don't know more about it, it was just from sifting through Bodmer's code comments in TFT_eSPI, which I've been using as a guide. So to recap, in the old code, it's all unoptimized SPI, but it works. In the new code, there's also parallel support, and the unoptimized SPI works but the optimized SPI does not. I *could* release it disabling the SPI optimizations, and keeping the parallel support and refactored code, but this release would have breaking changes - people would need to change existing code to use it. I have no idea how long it will take me to fix the SPI. It vexes me. My question is, should I release it, or should I wait until I can fix the SPI problems especially since it's a change that is disruptive to people's codebases?
Real programmers use butterflies
-
Sorry, I'm not sure where to put this question, but I'd like opinions. I have a graphics library, primarily targeting IoT devices. It has drivers for several displays. The drivers could be faster, tbh. All of these drivers communicate over SPI (well there are I2C ones too but forget those for now). For those of you that don't know, SPI is a serial wire protocol that came about in like the 1980s or something. Your SD cards are SPI "slave devices" I wrote a parallel driver for displays that support it. That means 8 data lines instead of one. It's not 8 times as fast, for hardware reasons, but it's much faster. Anyway, I also refactored my new driver code so that it's layered, separating the concerns of driving the bus (either parallel or spi) and operating the specific display chip (like an ILI9341 or an ST7789) The problem is this: I've optimized the SPI code in this new version and it only works on certain boards. There are timing issues. It's probably too fast, but I've had no luck getting it to work reliably. It only displays part of the tests, and then it freezes on most displays. As far as too fast, maybe the CS line control is too fast - it's not simply the SPI rate. I've tried changing that. For example, there's something called VDI rail that somehow needs more time to register a line change. I don't know more about it, it was just from sifting through Bodmer's code comments in TFT_eSPI, which I've been using as a guide. So to recap, in the old code, it's all unoptimized SPI, but it works. In the new code, there's also parallel support, and the unoptimized SPI works but the optimized SPI does not. I *could* release it disabling the SPI optimizations, and keeping the parallel support and refactored code, but this release would have breaking changes - people would need to change existing code to use it. I have no idea how long it will take me to fix the SPI. It vexes me. My question is, should I release it, or should I wait until I can fix the SPI problems especially since it's a change that is disruptive to people's codebases?
Real programmers use butterflies
-
Very Crazy Stoned Idea: Is there a way to measure the SPI capabilities (e.g. at startup)? I mean, you write something onto the display and read it back (if possible) and compare that to what it should be. If it fails you lower the speed until it works...
It's not a matter of finding the right speed unfortunately. It's a matter of finding *where* it's too fast. I have no idea what needs to be slowed down. I've tried slowing down the CS line change and DC line changes, but no dice. It's bizarre. I'm not really sure what else to try. I've also tried disabling these particular optimizations by themselves:
inline static void write_raw8(uint8_t value) FORCE_INLINE {
#ifdef OPTIMIZE_ESP32
*_spi_mosi_dlen = 7;
*_spi_w = value;
*_spi_cmd = SPI_USR;
while (*_spi_cmd & SPI_USR);
#elif defined(OPTIMIZE_AVR)
SPDR=(C);
while (!(SPSR&_BV(SPIF)));
#else // !OPTIMIZE_ESP32
spi.transfer(value);
#endif // !OPTIMIZE_ESP32
}When I do that, but I keep the optimized line changes, I get the same problem. When I unoptimize the line changes, but keep this optimized, same problem. Only when I unoptimize both does the problem go away. The thing to remember, is this optimized code works on boards that are well constructed.
Real programmers use butterflies
-
It's not a matter of finding the right speed unfortunately. It's a matter of finding *where* it's too fast. I have no idea what needs to be slowed down. I've tried slowing down the CS line change and DC line changes, but no dice. It's bizarre. I'm not really sure what else to try. I've also tried disabling these particular optimizations by themselves:
inline static void write_raw8(uint8_t value) FORCE_INLINE {
#ifdef OPTIMIZE_ESP32
*_spi_mosi_dlen = 7;
*_spi_w = value;
*_spi_cmd = SPI_USR;
while (*_spi_cmd & SPI_USR);
#elif defined(OPTIMIZE_AVR)
SPDR=(C);
while (!(SPSR&_BV(SPIF)));
#else // !OPTIMIZE_ESP32
spi.transfer(value);
#endif // !OPTIMIZE_ESP32
}When I do that, but I keep the optimized line changes, I get the same problem. When I unoptimize the line changes, but keep this optimized, same problem. Only when I unoptimize both does the problem go away. The thing to remember, is this optimized code works on boards that are well constructed.
Real programmers use butterflies
-
Sorry, I'm not sure where to put this question, but I'd like opinions. I have a graphics library, primarily targeting IoT devices. It has drivers for several displays. The drivers could be faster, tbh. All of these drivers communicate over SPI (well there are I2C ones too but forget those for now). For those of you that don't know, SPI is a serial wire protocol that came about in like the 1980s or something. Your SD cards are SPI "slave devices" I wrote a parallel driver for displays that support it. That means 8 data lines instead of one. It's not 8 times as fast, for hardware reasons, but it's much faster. Anyway, I also refactored my new driver code so that it's layered, separating the concerns of driving the bus (either parallel or spi) and operating the specific display chip (like an ILI9341 or an ST7789) The problem is this: I've optimized the SPI code in this new version and it only works on certain boards. There are timing issues. It's probably too fast, but I've had no luck getting it to work reliably. It only displays part of the tests, and then it freezes on most displays. As far as too fast, maybe the CS line control is too fast - it's not simply the SPI rate. I've tried changing that. For example, there's something called VDI rail that somehow needs more time to register a line change. I don't know more about it, it was just from sifting through Bodmer's code comments in TFT_eSPI, which I've been using as a guide. So to recap, in the old code, it's all unoptimized SPI, but it works. In the new code, there's also parallel support, and the unoptimized SPI works but the optimized SPI does not. I *could* release it disabling the SPI optimizations, and keeping the parallel support and refactored code, but this release would have breaking changes - people would need to change existing code to use it. I have no idea how long it will take me to fix the SPI. It vexes me. My question is, should I release it, or should I wait until I can fix the SPI problems especially since it's a change that is disruptive to people's codebases?
Real programmers use butterflies
I would take the case were it works with the old and not the optimized and put a scope or analyzer on it and see what the difference is. In my SPI lib code I had to add nop's to give time for transition, could be as simple as that?
uint8_t CSpiBB::TransferData(uint8_t data)
{
volatile uint8_t result = 0;volatile uint8\_t start = 7; volatile int8\_t step = -1; if (\_dir == LSB) { start = 0; step = 1; } for (volatile uint8\_t i = start, cnt = 0; cnt < 8; cnt++, i = i + step) { //Set the MOSI bit appropriately if (data & (1 << i)) \*\_port |= (1 <<\_mosi); else \*\_port &= ~(1 << \_mosi); //Low to high transition to allow data to be transferred to/from device. \*\_port |= (1 << \_clk); asm volatile ("nop"); //Grab the data that has been shifted in. if (\*\_pin & (1 << \_miso)) result |= (1 << i); else result &= ~(1 << i); //High to low transition to complete clocking \*\_port &= ~(1 << \_clk); asm volatile ("nop"); } return result;}
The less you need, the more you have. Even a blind squirrel gets a nut...occasionally. JaxCoder.com
-
Sorry, I'm not sure where to put this question, but I'd like opinions. I have a graphics library, primarily targeting IoT devices. It has drivers for several displays. The drivers could be faster, tbh. All of these drivers communicate over SPI (well there are I2C ones too but forget those for now). For those of you that don't know, SPI is a serial wire protocol that came about in like the 1980s or something. Your SD cards are SPI "slave devices" I wrote a parallel driver for displays that support it. That means 8 data lines instead of one. It's not 8 times as fast, for hardware reasons, but it's much faster. Anyway, I also refactored my new driver code so that it's layered, separating the concerns of driving the bus (either parallel or spi) and operating the specific display chip (like an ILI9341 or an ST7789) The problem is this: I've optimized the SPI code in this new version and it only works on certain boards. There are timing issues. It's probably too fast, but I've had no luck getting it to work reliably. It only displays part of the tests, and then it freezes on most displays. As far as too fast, maybe the CS line control is too fast - it's not simply the SPI rate. I've tried changing that. For example, there's something called VDI rail that somehow needs more time to register a line change. I don't know more about it, it was just from sifting through Bodmer's code comments in TFT_eSPI, which I've been using as a guide. So to recap, in the old code, it's all unoptimized SPI, but it works. In the new code, there's also parallel support, and the unoptimized SPI works but the optimized SPI does not. I *could* release it disabling the SPI optimizations, and keeping the parallel support and refactored code, but this release would have breaking changes - people would need to change existing code to use it. I have no idea how long it will take me to fix the SPI. It vexes me. My question is, should I release it, or should I wait until I can fix the SPI problems especially since it's a change that is disruptive to people's codebases?
Real programmers use butterflies
-
Sorry, I'm not sure where to put this question, but I'd like opinions. I have a graphics library, primarily targeting IoT devices. It has drivers for several displays. The drivers could be faster, tbh. All of these drivers communicate over SPI (well there are I2C ones too but forget those for now). For those of you that don't know, SPI is a serial wire protocol that came about in like the 1980s or something. Your SD cards are SPI "slave devices" I wrote a parallel driver for displays that support it. That means 8 data lines instead of one. It's not 8 times as fast, for hardware reasons, but it's much faster. Anyway, I also refactored my new driver code so that it's layered, separating the concerns of driving the bus (either parallel or spi) and operating the specific display chip (like an ILI9341 or an ST7789) The problem is this: I've optimized the SPI code in this new version and it only works on certain boards. There are timing issues. It's probably too fast, but I've had no luck getting it to work reliably. It only displays part of the tests, and then it freezes on most displays. As far as too fast, maybe the CS line control is too fast - it's not simply the SPI rate. I've tried changing that. For example, there's something called VDI rail that somehow needs more time to register a line change. I don't know more about it, it was just from sifting through Bodmer's code comments in TFT_eSPI, which I've been using as a guide. So to recap, in the old code, it's all unoptimized SPI, but it works. In the new code, there's also parallel support, and the unoptimized SPI works but the optimized SPI does not. I *could* release it disabling the SPI optimizations, and keeping the parallel support and refactored code, but this release would have breaking changes - people would need to change existing code to use it. I have no idea how long it will take me to fix the SPI. It vexes me. My question is, should I release it, or should I wait until I can fix the SPI problems especially since it's a change that is disruptive to people's codebases?
Real programmers use butterflies
-
Sorry, I'm not sure where to put this question, but I'd like opinions. I have a graphics library, primarily targeting IoT devices. It has drivers for several displays. The drivers could be faster, tbh. All of these drivers communicate over SPI (well there are I2C ones too but forget those for now). For those of you that don't know, SPI is a serial wire protocol that came about in like the 1980s or something. Your SD cards are SPI "slave devices" I wrote a parallel driver for displays that support it. That means 8 data lines instead of one. It's not 8 times as fast, for hardware reasons, but it's much faster. Anyway, I also refactored my new driver code so that it's layered, separating the concerns of driving the bus (either parallel or spi) and operating the specific display chip (like an ILI9341 or an ST7789) The problem is this: I've optimized the SPI code in this new version and it only works on certain boards. There are timing issues. It's probably too fast, but I've had no luck getting it to work reliably. It only displays part of the tests, and then it freezes on most displays. As far as too fast, maybe the CS line control is too fast - it's not simply the SPI rate. I've tried changing that. For example, there's something called VDI rail that somehow needs more time to register a line change. I don't know more about it, it was just from sifting through Bodmer's code comments in TFT_eSPI, which I've been using as a guide. So to recap, in the old code, it's all unoptimized SPI, but it works. In the new code, there's also parallel support, and the unoptimized SPI works but the optimized SPI does not. I *could* release it disabling the SPI optimizations, and keeping the parallel support and refactored code, but this release would have breaking changes - people would need to change existing code to use it. I have no idea how long it will take me to fix the SPI. It vexes me. My question is, should I release it, or should I wait until I can fix the SPI problems especially since it's a change that is disruptive to people's codebases?
Real programmers use butterflies
The suits say: "ship it, we need the money" :-D
>64 If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
-
I would take the case were it works with the old and not the optimized and put a scope or analyzer on it and see what the difference is. In my SPI lib code I had to add nop's to give time for transition, could be as simple as that?
uint8_t CSpiBB::TransferData(uint8_t data)
{
volatile uint8_t result = 0;volatile uint8\_t start = 7; volatile int8\_t step = -1; if (\_dir == LSB) { start = 0; step = 1; } for (volatile uint8\_t i = start, cnt = 0; cnt < 8; cnt++, i = i + step) { //Set the MOSI bit appropriately if (data & (1 << i)) \*\_port |= (1 <<\_mosi); else \*\_port &= ~(1 << \_mosi); //Low to high transition to allow data to be transferred to/from device. \*\_port |= (1 << \_clk); asm volatile ("nop"); //Grab the data that has been shifted in. if (\*\_pin & (1 << \_miso)) result |= (1 << i); else result &= ~(1 << i); //High to low transition to complete clocking \*\_port &= ~(1 << \_clk); asm volatile ("nop"); } return result;}
The less you need, the more you have. Even a blind squirrel gets a nut...occasionally. JaxCoder.com
Might be but the TFT_eSPI code I'm using as a guide doesn't need it, and I am loathe to put assembly in my C++. I'll try it though and see if it helps. Thanks!
Real programmers use butterflies
-
Sorry maybe a naiv question. I don't get this part, what about
valuehere:#elif defined(OPTIMIZE_AVR)
SPDR=(C);
while (!(SPSR&_BV(SPIF)));I believe _BV is an internal macro that points to a volatile SPI "register" on the AVR machines I copied this code from TFT_eSPI and haven't tested it yet though.
Real programmers use butterflies
-
Sorry, I'm not sure where to put this question, but I'd like opinions. I have a graphics library, primarily targeting IoT devices. It has drivers for several displays. The drivers could be faster, tbh. All of these drivers communicate over SPI (well there are I2C ones too but forget those for now). For those of you that don't know, SPI is a serial wire protocol that came about in like the 1980s or something. Your SD cards are SPI "slave devices" I wrote a parallel driver for displays that support it. That means 8 data lines instead of one. It's not 8 times as fast, for hardware reasons, but it's much faster. Anyway, I also refactored my new driver code so that it's layered, separating the concerns of driving the bus (either parallel or spi) and operating the specific display chip (like an ILI9341 or an ST7789) The problem is this: I've optimized the SPI code in this new version and it only works on certain boards. There are timing issues. It's probably too fast, but I've had no luck getting it to work reliably. It only displays part of the tests, and then it freezes on most displays. As far as too fast, maybe the CS line control is too fast - it's not simply the SPI rate. I've tried changing that. For example, there's something called VDI rail that somehow needs more time to register a line change. I don't know more about it, it was just from sifting through Bodmer's code comments in TFT_eSPI, which I've been using as a guide. So to recap, in the old code, it's all unoptimized SPI, but it works. In the new code, there's also parallel support, and the unoptimized SPI works but the optimized SPI does not. I *could* release it disabling the SPI optimizations, and keeping the parallel support and refactored code, but this release would have breaking changes - people would need to change existing code to use it. I have no idea how long it will take me to fix the SPI. It vexes me. My question is, should I release it, or should I wait until I can fix the SPI problems especially since it's a change that is disruptive to people's codebases?
Real programmers use butterflies
I assume developers are consumers of your library. My extremely naïve take on what you've described: Can you not let those developers supply some sort of sleep value, and, if provided, use it, and if not, let 'er rip as fast as it can? Then document the living crap out of it. Share the results from your test matrix, and let those developers make their own choices. Maybe supply "known good defaults" for different chips. I realize I'm talking in very broad terms. But I'm very much aware of what happens when you become so intimately familiar with details that you lose sight of the broader picture. If that's a viable solution, go for that...
-
I assume developers are consumers of your library. My extremely naïve take on what you've described: Can you not let those developers supply some sort of sleep value, and, if provided, use it, and if not, let 'er rip as fast as it can? Then document the living crap out of it. Share the results from your test matrix, and let those developers make their own choices. Maybe supply "known good defaults" for different chips. I realize I'm talking in very broad terms. But I'm very much aware of what happens when you become so intimately familiar with details that you lose sight of the broader picture. If that's a viable solution, go for that...
I actually considered that but the optimized code only works on one board I tried, and I'd at least like to try it on another of the same model to see if it's a fluke. With something like this, you never know.
Real programmers use butterflies
-
Sorry, I'm not sure where to put this question, but I'd like opinions. I have a graphics library, primarily targeting IoT devices. It has drivers for several displays. The drivers could be faster, tbh. All of these drivers communicate over SPI (well there are I2C ones too but forget those for now). For those of you that don't know, SPI is a serial wire protocol that came about in like the 1980s or something. Your SD cards are SPI "slave devices" I wrote a parallel driver for displays that support it. That means 8 data lines instead of one. It's not 8 times as fast, for hardware reasons, but it's much faster. Anyway, I also refactored my new driver code so that it's layered, separating the concerns of driving the bus (either parallel or spi) and operating the specific display chip (like an ILI9341 or an ST7789) The problem is this: I've optimized the SPI code in this new version and it only works on certain boards. There are timing issues. It's probably too fast, but I've had no luck getting it to work reliably. It only displays part of the tests, and then it freezes on most displays. As far as too fast, maybe the CS line control is too fast - it's not simply the SPI rate. I've tried changing that. For example, there's something called VDI rail that somehow needs more time to register a line change. I don't know more about it, it was just from sifting through Bodmer's code comments in TFT_eSPI, which I've been using as a guide. So to recap, in the old code, it's all unoptimized SPI, but it works. In the new code, there's also parallel support, and the unoptimized SPI works but the optimized SPI does not. I *could* release it disabling the SPI optimizations, and keeping the parallel support and refactored code, but this release would have breaking changes - people would need to change existing code to use it. I have no idea how long it will take me to fix the SPI. It vexes me. My question is, should I release it, or should I wait until I can fix the SPI problems especially since it's a change that is disruptive to people's codebases?
Real programmers use butterflies
-
Reading the other replies, I think you might be rushing it. IMHO, it needs more testing. Knowing you, you will likely keep at it and finally have an 'aha' moment. :thumbsup:
"Go forth into the source" - Neal Morse "Hope is contagious"
Yeah that's kind of where I'm at now too.
Real programmers use butterflies
-
Sorry, I'm not sure where to put this question, but I'd like opinions. I have a graphics library, primarily targeting IoT devices. It has drivers for several displays. The drivers could be faster, tbh. All of these drivers communicate over SPI (well there are I2C ones too but forget those for now). For those of you that don't know, SPI is a serial wire protocol that came about in like the 1980s or something. Your SD cards are SPI "slave devices" I wrote a parallel driver for displays that support it. That means 8 data lines instead of one. It's not 8 times as fast, for hardware reasons, but it's much faster. Anyway, I also refactored my new driver code so that it's layered, separating the concerns of driving the bus (either parallel or spi) and operating the specific display chip (like an ILI9341 or an ST7789) The problem is this: I've optimized the SPI code in this new version and it only works on certain boards. There are timing issues. It's probably too fast, but I've had no luck getting it to work reliably. It only displays part of the tests, and then it freezes on most displays. As far as too fast, maybe the CS line control is too fast - it's not simply the SPI rate. I've tried changing that. For example, there's something called VDI rail that somehow needs more time to register a line change. I don't know more about it, it was just from sifting through Bodmer's code comments in TFT_eSPI, which I've been using as a guide. So to recap, in the old code, it's all unoptimized SPI, but it works. In the new code, there's also parallel support, and the unoptimized SPI works but the optimized SPI does not. I *could* release it disabling the SPI optimizations, and keeping the parallel support and refactored code, but this release would have breaking changes - people would need to change existing code to use it. I have no idea how long it will take me to fix the SPI. It vexes me. My question is, should I release it, or should I wait until I can fix the SPI problems especially since it's a change that is disruptive to people's codebases?
Real programmers use butterflies
What does your Marketing guy say?
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
What does your Marketing guy say?
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
I'm the only marketer. The product is free, but in use by people.
Real programmers use butterflies
-
I'm the only marketer. The product is free, but in use by people.
Real programmers use butterflies
Marketing is always overly optimistic. Your question should be, if I release, will it make me look bad; and is that worse than being late; which is easier to fix. If the simple version worked, I would have gotten simple to work, then added the advanced functions, in parallel, and turned off the others when the new ones worked.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
Marketing is always overly optimistic. Your question should be, if I release, will it make me look bad; and is that worse than being late; which is easier to fix. If the simple version worked, I would have gotten simple to work, then added the advanced functions, in parallel, and turned off the others when the new ones worked.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
I've already done that though. It doesn't fix it. Only when all optimizations are turned off does it all work. If I turn on any of the optimizations I wrote, it fails on certain devices. However, the reference code I used, which contains these optimizations works on those devices. Hence my problem.
Real programmers use butterflies
-
Sorry, I'm not sure where to put this question, but I'd like opinions. I have a graphics library, primarily targeting IoT devices. It has drivers for several displays. The drivers could be faster, tbh. All of these drivers communicate over SPI (well there are I2C ones too but forget those for now). For those of you that don't know, SPI is a serial wire protocol that came about in like the 1980s or something. Your SD cards are SPI "slave devices" I wrote a parallel driver for displays that support it. That means 8 data lines instead of one. It's not 8 times as fast, for hardware reasons, but it's much faster. Anyway, I also refactored my new driver code so that it's layered, separating the concerns of driving the bus (either parallel or spi) and operating the specific display chip (like an ILI9341 or an ST7789) The problem is this: I've optimized the SPI code in this new version and it only works on certain boards. There are timing issues. It's probably too fast, but I've had no luck getting it to work reliably. It only displays part of the tests, and then it freezes on most displays. As far as too fast, maybe the CS line control is too fast - it's not simply the SPI rate. I've tried changing that. For example, there's something called VDI rail that somehow needs more time to register a line change. I don't know more about it, it was just from sifting through Bodmer's code comments in TFT_eSPI, which I've been using as a guide. So to recap, in the old code, it's all unoptimized SPI, but it works. In the new code, there's also parallel support, and the unoptimized SPI works but the optimized SPI does not. I *could* release it disabling the SPI optimizations, and keeping the parallel support and refactored code, but this release would have breaking changes - people would need to change existing code to use it. I have no idea how long it will take me to fix the SPI. It vexes me. My question is, should I release it, or should I wait until I can fix the SPI problems especially since it's a change that is disruptive to people's codebases?
Real programmers use butterflies
No. You shouldn't release some design when you know it malfunctions under some circumstances, especially when you don't know exactly when and why it does. FYI: electronic devices have lots of detailed specs, things like minimum pulse width, minimum set-up time (data valid before clocked/latched), minimum hold time (data valid after clocked/latched), etc. It is up to the system designer to make sure each and every one of those requirements is met. As most of these specs are minimum values, optimizing code can easily cause the timing requirements being violated. NOP instructions are not uncommon in low-level code, and then "smart" tools should be kept from eliminating them... :)
Luc Pattyn [My Articles] The Windows 11 "taskbar" is disgusting. It should be at the left of the screen, with real icons, with text, progress, etc. They downgraded my developer PC to a bloody iPhone.
-
No. You shouldn't release some design when you know it malfunctions under some circumstances, especially when you don't know exactly when and why it does. FYI: electronic devices have lots of detailed specs, things like minimum pulse width, minimum set-up time (data valid before clocked/latched), minimum hold time (data valid after clocked/latched), etc. It is up to the system designer to make sure each and every one of those requirements is met. As most of these specs are minimum values, optimizing code can easily cause the timing requirements being violated. NOP instructions are not uncommon in low-level code, and then "smart" tools should be kept from eliminating them... :)
Luc Pattyn [My Articles] The Windows 11 "taskbar" is disgusting. It should be at the left of the screen, with real icons, with text, progress, etc. They downgraded my developer PC to a bloody iPhone.
I was talking about taking the optimizations out. But anyway I don't think I'm going to release it without them. I'll get it working first. As far as your FYI, yeah, I'll use my logic analyzer and datasheets if it comes to that, but that's a last resort. To say it's laborious is a huge understatement.
Real programmers use butterflies
