Author Topic: Fast unsigned integer multiply by x100 on 8bit AVR?  (Read 5840 times)

0 Members and 1 Guest are viewing this topic.

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 2116
  • Country: ca
Re: Fast unsigned integer multiply by x100 on 8bit AVR?
« Reply #75 on: January 29, 2019, 11:47:06 pm »
That process is "starting" for 30 something years that free/open source software exists. That's eternity in IT.

If you remember, 30 years ago there was time when people were willing to pay for the software. There were lots of vendors, some of them very useful. Today, most people expect the software to be free. Some even get upset when someone ask them to pay for software. The trend is likely to continue.

If I compare LLVM (or even GCC) to any of the proprietary (and expensive) compilers I had to deal with in the past, jeeze, give me LLVM any day! Most of that proprietary stuff was utter crap compared to LLVM or GCC. In fact, recommendation to install/compile GCC and GNU tools was usually the first thing anyone who had to deal with commercial Unix saw, because the vendor-supplied compilers were buggy and supported only obsolete C/C++ versions.

IMHO, GCC  which existed 20 years ago was perfectly fine. Moreover, Microsoft VC++ for Windows was fine too. I also remember Borland C. They all worked about the same.

Today, I use what comes with the platform. It's GCC on Linux (and GCC-based on most embedded things), VC++ on Windows, LLVM on Mac. I cannot tell the difference.

People who develop LLVM do so because they like it. They like how any language can be compiled in, optimized within the same framework, then the assembler produced for any CPU. May be it is fascinating to the LLVM developers, but it doesn't looks particularly fascinating to me, and I do not see any benefits for myself.

Free software made some things into commodities. But that doesn't mean the paid-for tools ceased to exist. E.g. Microsoft still sells their compiler and tools. Only the Community edition of Visual Studio is free, which has severe licensing restrictions. If you have more than 5 users or make more than $100k annually you have to buy the commercial version.

They cell their C# tools. I don't know if there are any open source substitutes.

Their C/C++ compiler is free download which comes with Platform SDK and doesn't even require opt-in for spying. 20 years ago I had to pay for it.

Riiight ...  GCC alone is more than 30 years old. And we still have proprietary compilers (e.g. IAR) and some vendors even repackage and sell GCC-based toolchains (Microchip). Heck, some people prefer to use the expensive IAR compilers even where free GCC-based tools exist. Could it be that GCC simply doesn't (and cannot) cover all the market needs?

For a while. But not forever. We're now in money printing era. When it turns towards austerity there will be huge pull towards money savings and everything free.

Right now, Altium is considered better choice than KiCAD, but I wouldn't bet that it stays this way forever.

I am certainly not worried about lack of work, if anything, there will be more of it in the future because everything is moving from hardware to software due to lower costs of changes and faster time to market.

Of course there always be custom work for programmers ... or for programming AI robots :)

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 1846
  • Country: fi
    • My home page and email address
Re: Fast unsigned integer multiply by x100 on 8bit AVR?
« Reply #76 on: January 30, 2019, 04:36:17 am »
Today, most people expect the software to be free.  Some even get upset when someone ask them to pay for software.
The unwillingness to pay for something they believe is free, is real.

However, I see much more frustration about the black box nature of proprietary software. (Which is why in the past ten years or so, I've looked at how to provide the best of both worlds, especially for "cottage industry" software: having the UI part open source, because that's where the problems that irritate devusers tend to be in; and the proprietary secret-sauce work horse part as a closed library.)

It is all a cultural issue, and cultural trends do shift.  I think we (as in software engineers and product designers) can push a shift to the better, by doing it ourselves. Leading via example.

I just don't want engineers and scientists to recommend against doing that; to claim that it is somehow better to just throw more money and hardware at every problem.

As to future austerity or long-term post-scarcity plans, I'd say that it is a question if/when we realize that in a closed economy, neither the amount of debt or the amount of money/capital can act as the primus motor for growth, only better circulation and flow of resources can. If we do not work that out, we're fuckered. At the global scale, we're definitely a closed economy, unless we meet some Ferengi right quick.  Thus far, we've coasted on the hardware ignoring the software: made the markets and economies larger, not better.

Offline LapTop006

  • Supporter
  • ****
  • Posts: 460
  • Country: au
Re: Fast unsigned integer multiply by x100 on 8bit AVR?
« Reply #77 on: January 30, 2019, 04:58:06 am »
LLVM is a huge ecosystem and huge effort, and people use it, but did it really make any difference in software development? Is today's LLVMed software any less buggy or less bloated than the software before LLVM? I don't think so.

I'd say it has hugely helped, with much better warning output to make fixing them easier, the various sanitizers (ASAN, TSAN, UBSAN, etc.) only some of which were available in GCC.

All of that has helped to make software less buggy.

Offline beduino

  • Regular Contributor
  • *
  • Posts: 137
  • Country: 00
Re: Fast unsigned integer multiply by x100 on 8bit AVR?
« Reply #78 on: March 30, 2019, 11:08:03 pm »
I wouldn't bother with that patent as it doesn't work  :--

It seems that what you are trying to do is:
When added at the begining of avr_time_us_get() wait for OCF0A cleared in TIFR by ISR during its execution, since OCF0A is set when TCNT0 is reset to 0 in CTC
Sorry, for long delay but a few projects at the same time ;)

How did you know that it doesn't work?
I will take closer look at this code, but I've sucessfully used ideas above to keep timing home roof LED lights so this code works now 24h/day and no problem what so ever.

Patent pending markings was made (for fun), while I'm not a fan of patenting anything - I believe in patents are bad for innovation - Instead I simply didn't showed C source for this critical part, but it was smart enougth I think, since now when I'm back to this project I do not remember how I've did it  :-DD

Anyway, optimized ISR using inline AVR assembler code incrementing only given number of bytes in unsigned number of microseconds is perfectly fine.
Tricky part is in functions which can be hit by this ISR timer code running at 100kHz frequency, and this part of code will be now very carefully tested - I've showed only assembler code, because of I really think that it is very smart way to do it and it should work - proof is proper timing of home light trigered by PIR sensor module and additional modules like magnetic transducers to detect noisy dog or radio for remote controll.

I'll use logic analyser to debug this tricky part of code in realtime, to ensure it runs as expected.

« Last Edit: March 30, 2019, 11:34:18 pm by beduino »

Offline beduino

  • Regular Contributor
  • *
  • Posts: 137
  • Country: 00
Re: Fast unsigned integer multiply by x100 on 8bit AVR?
« Reply #79 on: March 30, 2019, 11:30:25 pm »
I *am* assuming ATtiny85 here. They happen to be quite cheap, but interestingly powerful microcontrollers.
Yep, I've used sucessfully ATTiny85 in many projects since it fits my performance requirements and has very small footprint on PCB.
Now, I'm working on project where this tiny AVR with additional opamp (the same footprint SO8) will make complete speed/cadence sensor for road cycling power meter.
At 5VCC I can run ATTiny85 at 16MHz internall clock according to it's specs, while at 3.3Vcc easily at 8MHz.

The same 100kHz timer ISR will be used in those sensors and additionally at the same time output data on 1 wire custom protocol with a few bytes messages with priority based on sensor IDs.

So, now imagine tens of such small but quite powerfull AVRs running in parallel, catching I/O interrupts, processing, easy to scale just by adding another sensor - something like distributed multiprocessor system with decent processing power and what is most important all sensors running in parallel at 8Mhz/16Mhz at the size of SO8 footprint!

It is amazing that such small thing can run so many RISC operations per second and with a little help of manually guided optimized inline AVR assembler code can be very powerfull and small at the same time- we are talking about a few miliamps of current needed to make quite complicated computations but in parallel  8)

Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo