|
The Kinks, A Gallon Of Gas:
The Kinks - A Gallon Of Gas - YouTube[^]
[Edit]
I remember my first time in US before about 30 years. We joinend Los Angeles up to San Francisco with a camper. We payed sometething around $1 for one gallon. In my country we received 1L for that cash 
Btw. 1 Gallon is about 3.79L
[Edit]
Currently US (google): $1 per Gallon$3.5 / Gallone
Here about: $2 per Liter
modified 18-Dec-21 15:12pm.
|
|
|
|
|
Yes and before
The less you need, the more you have.
Even a blind squirrel gets a nut...occasionally.
JaxCoder.com
|
|
|
|
|
|
The young ones over here only remember laughing gas 
|
|
|
|
|
I remember gas at major chains being below a dollar a gallon. I also vaguely remember the last time I was at a gas station.
|
|
|
|
|
My first purchase of gas was .34/gal. when I bought my first car in 68.
The less you need, the more you have.
Even a blind squirrel gets a nut...occasionally.
JaxCoder.com
|
|
|
|
|
It is all relative. When I first started driving, gas was less than $0.20 a gallon. I remember disappointment when I no longer got 5 gallons for a dollar.
Gas wars in New Jersey brought it down to $0.11 a gallon at times.
Some stations gave green stamps or a water glass for a fill-up.
OTOH, most entry level jobs paid about $0.65 an hour (my first one paid less).
On the nostalgic side, when I was about 14 I visited my grand father in Canada. Had a cabin in the sticks. Post Office/general store/gas station had one of the old time pumps where you hand pumped the gas up into a jar (held 5 gallons) until you got what you wanted and then released into the tank. Probably imperial gallons, don't remember that far back. I have CRS (can't remember stuff). 
>64
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
|
|
|
|
|
I remember gas in Canada being 49.9c/gallon in 1967. That's an imperial gallon (4.54 liters). I was 10 years old and had started to notice prices.
Today, gas is C$1.39/liter. But a silver 50c piece from 1967, the last year in which Canada issued silver coins, would still buy a gallon of gas, despite all the increases in gas taxes. The price of gas hasn't gone up. Instead, the currency has been debauched.
|
|
|
|
|
Greg Utas wrote: Instead, the currency has been debauched.
COVID: Hold my beer.
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
I remember gasoline for 42 cents a US gallon in 1969.
My friends in Texas said they paid only 25 cents at that time.
|
|
|
|
|
Don't want to give my age away, but I remember when gas was 30 cents per gallon.
Old men don't die. They just fade away...
|
|
|
|
|
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
|
|
|
|
|
Sorry maybe a naiv question. I don't get this part, what about value here:
#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
|
|
|
|
|
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)
{
if (data & (1 << i))
*_port |= (1 <<_mosi);
else
*_port &= ~(1 << _mosi);
*_port |= (1 << _clk);
asm volatile ("nop");
if (*_pin & (1 << _miso))
result |= (1 << i);
else
result &= ~(1 << i);
*_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
|
|
|
|
|
I think, You should wait until you can fix the SPI problems and save other people's patience.
|
|
|
|
|
Not necessarily a common thing, but I've grabbed at least 4 different projects over the years that were partially working. Typically I've fixed only the components that were problematic for me but it saved me time to stand on the shoulders of others rather than having to build everything from scratch.
|
|
|
|
|
Well,
When users encounter a library that doesn't work they tend to toss it into the bin and never look back. I'd recommend holding off a bit until you understand the nature of the timing issue.
Best Wishes,
-David Delaune
|
|
|
|
|
The suits say: "ship it, we need the money" 
>64
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
|
|
|
|
|
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
|
|
|
|
|
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. 
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
