Back
[01:11:30] <rue_bed> brabo,
[01:12:23] <rue_bed> how are you changing hte array
[01:12:28] <rue_bed> how is the array defined
[01:12:36] <rue_bed> how is the array passed around to be used
[05:00:07] <abcminiuser> Well y'all are quiet
[05:16:52] * antto drops a needle on the floor...
[06:01:03] <Lambda_Aurigae> usbasp programmers...gotta love the cheapest possible solution,,,not..
[06:05:18] <JustinN> hey all, I need some help.... I have a few hundred ATMega8A chips (TQFP32) - and basically AVRDude gives me the unable to connected -1 error... I normally use PIC chips so I'm a bit lost. Spent hours upon hours trying to find a solution. Some people said "virgin" chips don't have the fuse settings and I just need to burn those on, other people have said I need to make AVRDude run slower, and some people have said I need a high voltage programmer instead...
[06:05:18] <JustinN> I've tried an USBTinyISP (Adafruit), USBASP and USPISP (v1 and v2) - same results. I'm pulling my hair out and really need help from somebody that knows more than I
[06:08:20] <Lambda_Aurigae> these are virgin chips?
[06:08:40] <Lambda_Aurigae> you are applying power, connecting miso, mosi, sck, and GND ?
[06:09:21] <abcminiuser> And using a ISP clock rate below 250KHz?
[06:10:43] <Lambda_Aurigae> first, I suggest getting a real programmer and not one based on usbasp, which all of those are.
[06:10:47] <JustinN> yes, virgin chips - applying power with the adafruit programmer (the little jumper is in place to do that) - I also have a pull up resistors on reset
[06:11:18] <Lambda_Aurigae> ((forgot reset on the list of things to connect))
[06:11:29] <JustinN> abcminiuser: how do you set the clock rate? Is it something I can do with AVRDude? I tried setting -B switch to values from 3 up to 20 and it made no difference...
[06:12:18] <JustinN> Lambda_Aurigae: what would you consider a real programmer? AVR is quite new to me, and generally I use PICKit2 for my PIC stuff and have never had this type of issue before... but as said, AVR is new to me
[06:12:18] <Lambda_Aurigae> I would think default speed with the default 1MHz internal oscillator speed should work fine,,,but being usbasp based, no clue.
[06:12:49] <Lambda_Aurigae> well, I use an old STK200 clone but Tom_itx's programmer works well too.
[06:13:08] <abcminiuser> Tom_itx's programmer has terrible firmare tho
[06:13:24] <Lambda_Aurigae> usbasp is based on vusb...vusb is a bitbanged usb, not hardware usb interface...it is,,barely functional at best.
[06:13:30] <Lambda_Aurigae> abcminiuser, you say that but you wrote it!
[06:13:59] <abcminiuser> JustinN, it's the -B flag as you've already discovered
[06:14:04] <abcminiuser> Lambda_Aurigae, heh, guilty as charged
[06:15:33] <abcminiuser> JustinN, perhaps type out the actual connections/voltages into the chips first so we can verify
[06:15:41] <abcminiuser> Then the exact avrdude command you are using
[06:16:10] <abcminiuser> I should finish off
https://github.com/abcminiuser/gdp one of these days :(
[06:19:22] <JustinN> abcminiuser: unfortunately that information is not with me right now. I spent ages working on this last night and got no-where, started pulling out my hair and gave up a bit after midnight. I'm at work right now (this is just a hobby of mine), so won't be able to give you the connections/pins/commands until I get back home in 5 hours... but I will make note of all the values and check back here when I do. If anybody is still around, awesome, if not, I'll
[06:19:22] <JustinN> make sure to save the details
[06:21:57] <Lambda_Aurigae> JustinN, you said you have lots of the chips...where did you get them? hopefully not from some chinese dealer on ebay.
[06:22:42] <JustinN> Lambda_Aurigae: Farnell
[06:22:57] <Lambda_Aurigae> ok..then they should be authentic.
[06:23:20] <JustinN> I get LEDs and such from China, but I've heard horror stories about MCUs so I avoid those
[06:23:53] <Lambda_Aurigae> do you have an older computer with a parallel port?
[06:24:35] <Lambda_Aurigae> https://sites.google.com/site/emrirc/isp-adapter-circuit.gif
[06:26:33] <Lambda_Aurigae> this is the first avr programmer I ever built...and it still works today
https://sites.google.com/site/emrirc/avr-ispdongle.pdf
[06:26:48] <Lambda_Aurigae> that first one is similar but based on a smaller chip.
[06:28:43] <JustinN> unfortunately not... the oldest thing in my house is a 2 year old laptop, everything I try to keep up to date
[06:30:19] <Lambda_Aurigae> my newest is a 6 month old quad core athlon and it has a parallel port...sheesh.
[06:30:37] <Lambda_Aurigae> built into the motherboard even.
[06:31:04] <Mr_Sheesh> Be glad, parallel ports are good for embedded stuff, Lambda_Aurigae
[06:31:13] <Lambda_Aurigae> that's why I bought this board.
[06:31:27] <Lambda_Aurigae> although I do keep a few P-4 machines around for interfacing.
[06:33:06] <Lambda_Aurigae> JustinN, just a bit of information...it seems that easily 9 out of 10 people who come here with problems uploading program to their AVRs are using usbasp based programmers. While cheap, they are,,,cheap.
[06:35:15] <Lambda_Aurigae> the vusb software they are based on is a nifty hack, but it is that, a hack, and does not work on all computers. on some it works somewhat, and on some it does not work at all...
[06:35:17] <JustinN> Lambda_Aurigae: well I've tried the adafruit programmer, USBASP and a USPISP thus far...
[06:35:34] <Lambda_Aurigae> adafruit programmer is based on usbasp.
[06:35:41] <JustinN> in which case, ASP and ISP
[06:35:48] <Lambda_Aurigae> and I suspect the uspisp is too but can't find it.
[06:36:59] <Lambda_Aurigae> yup..it is too..
[06:37:13] <Lambda_Aurigae> at least, according to the one reference I found for it.
[06:38:22] <JustinN> right, well I have access to an Atmel AVR Dragon via another friend - worth giving that a try?
[06:38:37] <rewolff1> Jep.
[06:38:46] <Lambda_Aurigae> perfect.
[06:38:51] <Lambda_Aurigae> an official programmer.
[06:39:46] <Mr_Sheesh> Always easiest to beg/borrow/buy an official programmer then use that to get your shadetree programmer working :P
[06:40:12] <JustinN> ahah
[06:40:13] <JustinN> * haha
[06:40:29] <JustinN> so I assume I should be able to "fix" my chips with that and then I can go back to my adafruit programmer?
[06:40:47] <Lambda_Aurigae> shouldn't be anything to fix.
[06:40:54] <Lambda_Aurigae> if they are real virgin chips they should just work.
[06:41:15] <Mr_Sheesh> I bought an AVRISP mkII a while ago, it just works
[06:41:58] <Lambda_Aurigae> the programmer Tom_itx sells uses hardware usb and the firmware was written by an atmel employee.
[06:42:13] <JustinN> Mr_Sheesh: my programmer just works, it's just not working with these chips :)
[06:42:16] <Lambda_Aurigae> it's close to official.
[06:42:25] <Lambda_Aurigae> JustinN, does it work with other chips?
[06:42:54] <Mr_Sheesh> LOL There is that. A good solid programmer's OK, I just find on some things "buy once, cry once", and $45 isn't that much if embedded stuff is what you do work-wise
[06:43:55] <JustinN> Lambda_Aurigae: it works perfectly fine with ATMega168 and 328 chips, just not ATMega8, and having looked at a number of forums and boards online, people kept suggesting there's a number of different things you need to do with these specific chips which I didn't fully understand
[06:44:23] <Lambda_Aurigae> interesting....I have no problem with atmega8 vs atmega328 vs atmega88.
[06:44:40] <Lambda_Aurigae> always hook them up the same way.
[06:45:54] <JustinN> Lambda_Aurigae: around 9/10 things I read suggested the programmer speed, but I had no idea what values to use, so randomly tried 3,4 and 20
[06:46:13] <Lambda_Aurigae> go up to 32
[06:46:35] <JustinN> the main gist was the chips by default are too slow to keep up with the programmer... slow the programmer down to set them and then I'm good to go
[06:46:49] <Lambda_Aurigae> they are the same speed by default as the others.
[06:46:52] <JustinN> I'll give 32 a go once I get home, cheers
[06:47:08] <Lambda_Aurigae> set to 8MHz internal oscillator with div/8 prescaler.
[06:47:12] <Lambda_Aurigae> so, set to 1MHz.
[06:50:17] <JustinN> sounds like a few things for me to try in which case
[06:51:57] <JustinN> once I finally get just one of these working, if the solution is in fact the AVR programmer then I'll buy a proper one. This is all just a hobby for me, but I'm more than happy to invest money into good tools for my hobby if they are needed for me to get the most out of it
[06:52:07] <JustinN> thanks for all the help and suggestions, much appreciated!
[08:23:53] <_mux> abcminiuser, are you there?
[08:24:00] <abcminiuser> Nope, dead
[08:24:07] <_mux> aww man, that's a shame :P
[08:24:44] <_mux> can I ask a question about the MSD bootloader and xmega
[08:24:50] <abcminiuser> Sure
[08:25:31] <_mux> afaict, this has not yet been properly ported to xmega, if I try to compile it I get errors pertaining to wdt.h, which isn't available for xmega
[08:25:52] <_mux> I wanted to check with you if that's actually true or if I'm just being an idiot
[08:27:16] <abcminiuser> Yeah it's not ported
[08:27:31] <abcminiuser> It could be, but the FAT mapping at least would need to be altered
[08:27:40] <abcminiuser> And the XMEGA FLASH write routines implemented
[08:27:52] <_mux> I have an application that would really benefit from an xmega port, and I'm fine with putting in the work
[08:28:29] <_mux> can you expand on what exactly needs to happen
[08:36:24] <abcminiuser> The biggest blocker is a lack of boot.h for XMEGA
[08:36:35] <abcminiuser> The functions to write EEPROM and FLASH words
[08:37:28] <_mux> I'm a bit confused about this, is this implemented in some other way on xmega? because I have had bootloaders on xmega :P
[08:37:39] <_mux> and they definitely write to flash
[08:40:03] <abcminiuser> Of course, but my bootloaders use the avr-libc functions which aren't ported for XMEGA
[08:41:07] <_mux> it doesn't seem like xboot quite uses the same nomenclature internally, so that's not a trivial port
[08:41:21] <_mux> (I realized that the other bootloader projects I used, used xboot)
[08:44:46] <_mux> well, I can kind of try a like-for-like replacement in BootloaderAPI.c with xbootapi-calls
[08:46:36] <_mux> yeah why not, let's just try that, it won't blow anything up I guess
[08:46:51] <twnqx> you could also to a good deed
[08:46:55] <twnqx> and update avrlibc :P
[08:48:24] <_mux> I'm not sure if that would be a good deed, tbh
[08:48:42] <_mux> I don't produce particularly good code for public consumption and I don't do proper doxygen documentation
[08:48:57] <_mux> and of course don't=should, but laziness
[08:49:11] <_mux> people will most likely shout at me
[08:50:03] <_mux> but I'll post my solution somewhere public and open anyway
[08:50:19] <twnqx> you get used to that :P
[08:50:20] * twnqx did with libav...
[08:51:22] <_mux> honestly I didn't think Atmel would take so long to add a boot.h-analog to their toolchain, if they even plan to at all
[08:54:37] <abcminiuser> There are ASF functions for it, but they have license restrictions
[08:54:43] <abcminiuser> I should make my own at some point
[08:55:00] <twnqx> bah asf
[08:55:29] <twnqx> doesn't work great on operating systems :(
[08:56:37] <_mux> ASF is a bit of a mess and I can't use a lot of it for commercial applications
[08:56:59] <abcminiuser> Ah well I only wrote the good parts of it *cough* *cough*
[08:57:01] <abcminiuser> Bed time for me
[08:57:10] <_mux> don't let the bedbugs bite
[09:50:55] <NooM> hm, anyone here build his own ftdi adapter?
[09:52:08] <myself> I modded the crap out of my USB BUB I, why?
[09:52:32] <NooM> somhow i have some problems with my ftdi, it only works half the time
[09:52:53] <NooM> means, i send data with my uc, but putty doesent show anything.. when i disconnect usb a few times it works -.-
[09:53:18] <NooM> i didnt include the 47pF caps on the d+ and d- lines, so iam wondering if thats the problem
[09:53:35] <NooM> or if some solderjoint is bad, iam using a tiny qfn package -.-
[09:56:53] <NooM> damnit i think i found the problem.. i left reset pin floating -..-
[09:57:26] <NooM> wow thats bad
[09:59:06] <woodyj21> for shame, LoL
[09:59:23] <NooM> its the second design i made something wrong
[09:59:28] <NooM> for that stupid ftdi
[09:59:37] <NooM> first i forgot to connect vcc-io -.
[10:01:08] <NooM> hmmm
[11:26:35] <brabo> rue_bed: the influencing array is a pointer defined and used in the subroutine. the array being influenced is a pointer passed on as a argument and returned to the calling function. i think i am not doing the pointers correctly, i am not assigning memory for one
[11:27:23] <brabo> rue_bed: maybe a paste is of use?
[13:18:31] <dkordic> Anybody using Forth?
[13:19:24] <Thrashbarg> I know a bit of Forth, yea
[13:23:00] <dkordic> Thrashbarg: Commercial offers seem awesome. I am more interested in open source. I am noob so any directions are very welcome.
[13:23:38] <Thrashbarg> do you have anything in mind?
[13:23:52] <Thrashbarg> I mean, what Forth system, what computer architecture, etc
[13:25:27] <dkordic> Thrashbarg: AVR or what ever You suggest. Speed is the least of my problems.
[13:25:42] <Thrashbarg> ok sure I think there's a Forth for AVR
[13:25:56] <dkordic> I heard of amforth.
[13:26:00] <Thrashbarg> yeah
[13:26:54] <dkordic> I think some thing with assembler ( word "code") would be best.
[13:27:05] <N1njaneer> What's the motivation for using Fourth?
[13:27:32] <Thrashbarg> heh
[13:27:54] <dkordic> N1njaneer: Easy to use and understand.
[13:28:13] <Thrashbarg> I like Forth myself but I'd hesitate to use it for anything substantial
[13:28:33] <dkordic> Thrashbarg: Why???
[13:28:42] <Thrashbarg> dkordic: it has a reputation of being a 'write only' language :P
[13:29:13] <Thrashbarg> I think the problem is the stack is directly exposed to the programmer, so you have to be constantly aware of what's going on on it
[13:29:18] <N1njaneer> I didn't know if there was a deeper motivation for using Forth because you needed to create a VM inside of an AVR or such.
[13:30:09] <Thrashbarg> I think Forth for Harvard architectures can be useful because you can execute code in RAM
[13:30:25] <Thrashbarg> whether that's implemented or not is something else
[13:34:08] <Thrashbarg> I've not investigated it
[13:34:21] <dkordic> Oh yes, I am a mere amateur. But I am very interested in professional aspects.
[13:34:46] <dkordic> Thrashbarg: Yes, tethered Forth is so awesome.
[13:34:53] <Thrashbarg> hehe
[13:34:55] <dkordic> N1njaneer: ???
[13:36:04] <Thrashbarg> on the stack juggling issue, I've seen implementations of local variables but they've always looked a little ugly frankly
[13:36:27] <N1njaneer> hmm?
[13:42:38] <dkordic> Thrashbarg: Maybe. I think ": swap { a b } b a ;" will be more than enoug for micros.
[13:46:09] <Thrashbarg> for two local variables
[13:48:19] <dkordic> Just as an example (I couldn't find better one :) ). It doesn't seem problematic for simple tasks of uCs.
[13:48:26] <Thrashbarg> sure
[13:49:33] <Thrashbarg> dkordic: I must admit I love the speed and simplicity of Forth
[13:50:08] <Thrashbarg> just when I go to program something in it I always get bogged down in tedium
[13:52:09] <dkordic> Thrashbarg: I have 0 expirience :) . Some challenge would be appreciated.
[13:52:33] <Thrashbarg> dkordic: heh I'd like to have a play with a sort of virtual packet switched forth. The interpreter is like a DNS server and the words are hosts which perform specific functions and spit out packets requesting or responding to other hosts...
[13:52:48] <Thrashbarg> that might solve a lot of parallel computing issues
[13:53:24] <N1njaneer> Thrashbarg: At that point just compress it all down to Forth running in an FPGA :)
[13:53:33] <Thrashbarg> yup
[13:55:38] <Thrashbarg> N1njaneer: my reasoning is when a program is developed on such a system, it's inherently distributable across different physical processors... meh I don't know
[13:56:12] <N1njaneer> All comes down to the details. :)
[13:56:18] <Thrashbarg> yup
[13:59:13] <dkordic> So multiple VMs that can send byte code to each other?
[13:59:53] <Thrashbarg> just I've been pondering to myself for a bit, if programming was arranged a little like a packet switched network, with each function or object acting as a 'host' with the equivalent of a switch in the centre of each physical processor... something like that
[14:01:21] <Thrashbarg> the ability to break up a program into distributable parts would be simplified
[14:01:58] <Thrashbarg> currently with programs they're still effectively single tasking, just doing things really fast to blur it together
[14:02:04] <N1njaneer> Yes, but the trick you have is dealing with state-machines and series-of-operations-oriented problems.
[14:02:59] <Thrashbarg> N1njaneer: yes true. I was thinking of the ability of packets to be reogranised at the destination in correct order even if they've been received out of order
[14:03:16] <Thrashbarg> but yea there'd be a lot of things that'd need solving, and would probably be quite inefficient
[14:03:25] <N1njaneer> Nodal or flow-based works fantastic when you can think of the data as propogating through the elements for every tick or instruction clock or such, or thinking of the system computing once for each piece of data provided, but it gets very tricky when you need to make the parallel system start computing certain operations with non-linear sequential operations.
[14:04:11] <N1njaneer> It's actually the exact strength-or-weakess comparison between FPGA and MCU architectures. You can make each perform parts as the other, but it's not inherent to what the base fabric does. :)
[14:04:40] <Thrashbarg> yeah
[14:05:29] <Thrashbarg> I'd like to have a poke at it, see what it does...
[14:05:35] <N1njaneer> I've spent the past 6-7 years doing a lot of intensive development work on real-time nodal flows and have been thinking about much of the same ideas that you're proposing, so I totally know where you're coming from. :)
[14:05:47] <Thrashbarg> cool
[14:06:12] <N1njaneer> The nodal flows work absolutely amazing for what we use them for, but they break down in to horrible complexity when you have to start getting state-machine behaviour out of them. :)
[14:06:32] <Thrashbarg> I bet yeah
[14:07:21] <Thrashbarg> I was thinking more making a state machine as a node and having instances of nodes if you need more than one of the same type of state machine
[14:07:36] <Thrashbarg> rather than trying to distribute a state machine, which is silly
[14:08:22] <N1njaneer> https://www.dropbox.com/s/2s14plidxb6czcz/DSPatchBig.png for some possible inspiration!
[14:08:54] <Thrashbarg> hehe this is why icon based programming hasn't taken off :P
[14:09:10] <Thrashbarg> how big is that image?
[14:09:50] <Thrashbarg> rather what's the resolution of the machine you're on
[14:10:19] <N1njaneer> My main monitor is 2560x1600 :)
[14:10:23] <Thrashbarg> nice
[14:10:33] <N1njaneer> The view is also significantly zoomed out.
[14:10:38] <Thrashbarg> yeah I see that
[14:11:09] * Tom_itx steals N1njaneer's monitor
[14:11:27] <Thrashbarg> N1njaneer: btw, don't mind me I like stuffing around with weird ideas :P
[14:12:11] <Tom_itx> Thrashbarg, check out classicladder
[14:12:21] <Tom_itx> it's pure state machine
[14:12:37] <dkordic> XS1 core (Transputer2) comes to mind. And Berkeley Orders Of Magnitute (BOOM) project (
http://boom.cs.berkeley.edu/).
[14:12:53] <Thrashbarg> yup
[14:13:40] <dkordic> Thrashbarg: Heard of BOOM?
[14:13:49] <Thrashbarg> no, but I've heard of the Transputer
[14:14:40] <dkordic> Check it out. They say chaos is default and sequential dependencies must be explicitly defined.
[14:14:52] <Thrashbarg> cool
[14:15:27] <Thrashbarg> "One key to our approach is that everything is data" <-- paradigm philosophies heh
[14:15:30] <dkordic> XS1 has nothing to do with BOOM.
[14:15:33] <Thrashbarg> yea
[14:16:10] <Thrashbarg> I remember saying to a friend of mine Perl's philosophy is "everything's a colossal mess"
[14:17:55] <Thrashbarg> dkordic: BOOM
http://www.hardcoregaming101.net/spacequest/sq4-box2.png
[14:22:12] <N1njaneer> Tom_itx:
https://www.dropbox.com/s/rbx7xgyyemjxucw/workdesk.jpg I need an updated picture, but that's generally what the desk looks like. VoIP phone now, though! And more under-monitor USB lighting!
[14:22:45] <N1njaneer> Couch in the back is key!
[14:23:33] <N1njaneer> I also have the skins from an SGI Onyx Deskside sitting here that need to still be mounted to an appropriate-sized minifridge so I can keep cold beer in my office
[14:23:51] <N1njaneer> And be a nice-looking endtable!
[14:28:24] <dkordic> Thrashbarg: I don't understand.
[14:32:52] <Thrashbarg> dkordic: never mind, it's from a game called Space Quest
[14:33:15] <N1njaneer> Space Quest was awesome.
[14:33:20] <Thrashbarg> BOOM is a parody of Loom
[14:33:25] <Thrashbarg> damn right
[14:34:02] <N1njaneer> I know Loom...... WAAAY too well.
[14:34:06] <N1njaneer> Like....
[14:34:24] <N1njaneer> I have chunks of dialog from that stuck in my head from years ago
[14:34:30] <Thrashbarg> hehe
[14:34:33] <dkordic> I followed the link, did not understand anything.
[14:35:09] <N1njaneer> Thrashbarg: So tell me... does "How appropriate, you fight light a cow!" ring a bell for you? :D
[14:35:19] <N1njaneer> +like
[14:35:42] <Thrashbarg> no :P
[14:35:58] <N1njaneer> Not a Monkey Island fan? :D
[14:37:05] <Thrashbarg> no sorry I never got into it
[14:37:23] <N1njaneer> Awww, good stuff.
[14:37:29] <Thrashbarg> yeah I've heard
[14:38:08] <Thrashbarg> I played Beneath a Steel Sky on my Amiga however
[14:38:35] <N1njaneer> <3 Amiga
[14:38:40] <Thrashbarg> hehe
[15:10:19] <N1njaneer> Thrashbarg: Damnit, now I'm running a Let's Play of the VGA reboot of SQ1 right now in the background :D
[15:18:34] * myself grabs a banana and goes looking for orats
[15:20:59] <ambro718> under what conditions will avr-gcc put code beyond 128K flash? I want to use the ijmp instruction in some inline assembly, but I'm afraid it might get put beyond 128K where ijmp doesn't work.
[15:21:58] <N1njaneer> ambro718: If you write 127K too much of it? :)
[15:23:50] <ambro718> ok this compiles: static_assert(sizeof(void(*)(void)) == 2, "");
[15:24:13] <ambro718> so surely it will not put functions addressed by function pointers there
[15:24:39] <N1njaneer> There are some odd things that happen at the memory boundaries, yeah.
[15:24:56] <ambro718> Is there any way to force my inline asm not be put beyond 128K?
[15:27:00] <N1njaneer> Might be some preprocessor directives that can be used for the source file that contains your asm, but you'd have to look it up.
[15:27:14] <N1njaneer> Do you have enough code that you are worried about it happening?
[15:28:50] <ambro718> yeah I do have more than 128k
[15:30:18] <Casper> you might want to look for avr attribute
[15:36:30] <N1njaneer> Why not just write it as inline assembler in the C file and see if the compiler deals with it all automatically?
[15:41:41] <RikusW> use code sections ?
[15:41:57] <RikusW> .code .asm etc
[15:42:04] <RikusW> .text
[15:42:53] <vsync_> .porn
[15:43:02] <vsync_> .reddit
[15:43:06] <vsync_> and .twitter
[15:43:13] <vsync_> for social media revolution
[15:43:16] <vsync_> 11!11oneone
[15:50:54] <Casper> you forgot .facebook and .google+
[19:26:50] <rue_bed> brabo, I'm back in a while if you want to go over it
[19:34:07] <brabo> rue_bed: yeah that'd be nice
[19:34:19] <brabo> i'll try to stay up late enough ;)
[19:38:01] <ambro718> So I wrote my own float->integer rounding function.
https://github.com/ambrop72/aprinter/blob/master/aprinter/avr-asm-ops/fpround.h
[19:38:11] <ambro718> It's very faster than lround :D
[19:38:31] <ambro718> can even saturate the result to any number of bits
