Back
[00:57:10] <Jartza> https://www.youtube.com/watch?v=FWhk8lHQefw
[01:04:32] <carabia> is it just me or does the b/g blend fire too early
[01:05:07] <carabia> and it's so off that personally i would have left it out. :D i know, the lack of colors, which boils down to the idiocy in the first place \:D/
[01:06:14] <Jartza> https://hackaday.io/project/19248-512-byte-8-color-vga-demo-with-attiny5
[01:07:47] <Jartza> carabia: "whatever" :)
[01:07:56] <Jartza> you can always make it better, code is in bitbucket
[01:09:30] <sabor> Jartza: wow, nice piece of work :)
[01:11:32] <Jartza> thx :)
[03:59:22] <skz81> <Vikinger> does it make any diference if i declare the clock speed on in the header file or the makefile ? >> if your code is generic enough to be reused on different hardware, it should not mention the frequency. If your code is higly specific, as you'll be the only one to use it, do what you feel best comfortable with.
[04:11:36] <Emil> Vikinger: F_CPU needs to be declared before any other things that use it. Otherwise you are free to do whatever
[04:12:24] <twnqx> skz81: delay.h from avr libc uses the frequency
[04:12:54] <Haohmaru> anything that is supposed to deal with time too
[04:15:08] <skz81> Huh ? I didn't say it has not to be defined at compile time, I told about WHERE it should be defined. IMHO, at Makefile level is often smarter.
[04:15:48] <twnqx> i misunderstood you then. i took it as "should not be used at all"
[04:16:06] <skz81> But sure if done in source code file, you have to #define it BEFORE some #includes, Lambda_Aurigae stated it yet
[04:16:34] <skz81> k, no prob :)
[04:23:26] <Haohmaru> #defining it causes problems..
[04:23:39] <Haohmaru> -D is a better option
[04:26:59] <skz81> I see no big fundamental difference between -D and #define (you can #undefine both). -D as a bigger scope, though
[04:27:05] <skz81> has*
[04:28:14] <Haohmaru> maybe my code is not structured well
[04:29:19] <Haohmaru> but i have some classes i've made for wrapping up USARTs and stuff, and i use those between projects, so they are in a parent directory to all the projects
[04:29:57] <Haohmaru> i just include ..\my_usart.h and use it
[04:30:13] <Haohmaru> however, there's also my_usart.cpp there
[04:30:17] <skz81> '\' ??? srly ?
[04:30:28] <Haohmaru> no, not exactly
[04:31:19] <Haohmaru> so if i #define F_CPU, and then #include my_usart.h, what happens is i get complains that F_CPU is not define, when the compiler is compiling my_usart.cpp, which also includes my_usart.h
[04:31:29] <Haohmaru> -D solves that
[04:31:47] <Haohmaru> but maybe i'm doing it wrong
[04:31:49] <twnqx> your .c should always include the matching .h
[04:31:58] <Haohmaru> it does
[04:32:48] <Haohmaru> the problem is that the compiler starts compiling my_usart.cpp, and F_CPU is not defined yet, it will be defined later when it reaches main.cpp for example
[04:32:53] <Haohmaru> but it's kinda too late then
[04:33:18] <twnqx> sounds like your building way is strange, but yes, generally I pass it via -D from the Makefile too
[04:33:33] <Haohmaru> i'm building from the IDE
[04:33:45] <Haohmaru> i'm no command line h4x0r
[04:33:53] <twnqx> i have never seen an IDE for linux that works
[04:34:01] <Haohmaru> code::blocks
[04:34:18] <twnqx> tried it, almost had to throw up, uninstalled it
[04:34:40] <skz81> Haohmaru, the "solution" here for a hardcore #definer would be to put it in say "hardware_config.h", included from main AND my_usart.cpp
[04:35:00] <Haohmaru> i've seen this sort of thing
[04:35:04] <Haohmaru> i don't like it
[04:35:23] <skz81> but if my_usart.cpp is not hardware specific, it should NOT mention anything about actual hardware, for the sake of reuse
[04:35:24] <twnqx> i use that, but don't put my clockspeed there :P
[04:35:31] <skz81> => back to my first sentence
[04:35:43] <skz81> if your code is generic enough to be reused on different hardware, it should not mention the frequency.
[04:35:50] <twnqx> you can't cacluclate baud rates without knowing the cpu speed
[04:36:06] <Haohmaru> skz81 it's as generic as possible on xmega
[04:36:07] <skz81> anyway, I highly encourage -D
[04:36:37] <skz81> it's a very good practice :)
[04:36:44] <Haohmaru> F_CPU is used by the method which takes a bitrate argument and does the ugly calculations to find the optimum usart settings for it
[04:37:53] <Haohmaru> it works for all USARTs of the xmegas on that datasheet, since each USART is exactly the same, stored as an USART_t struct in RAM
[04:38:12] <skz81> Haohmaru, also you still can include your .cpp directly, but... Just ignore me, i'm crazy
[04:38:29] <Haohmaru> include a cpp file?
[04:38:42] <twnqx> it's just textual
[04:38:47] <skz81> or a .wav, but it compiles hardly
[04:38:48] <twnqx> of course you can #include it
[04:39:26] <Haohmaru> anyways, my point was.. -D "just works"
[04:41:52] <twnqx> the generic makefile i have been using since i started with AVR has that...
[04:42:26] <Haohmaru> makefiles make me cry
[04:42:40] * Haohmaru hugs the IDE
[04:42:40] <twnqx> i have one makefile that makes me cry every now and then
[04:42:50] <twnqx> but i am abusing make far too much in that
[04:45:11] <twnqx> i really should factor out all the inline awk...
[06:30:05] <Vikinger> Thank you guys, -D it is
[06:30:09] <Vikinger> :)
[06:34:31] <Lambda_Aurigae> putting it in the makefile also can make for building multiple versions a bit easier.
[06:34:55] <Lambda_Aurigae> you can make up a makefile that changes the frequency and builds different versions for different clock sources all at once.
[06:34:59] <Lambda_Aurigae> but that's a bit complex.
[06:50:44] <Lambda_Aurigae> http://digg.com/video/spool-on-the-loose
[06:50:46] <Lambda_Aurigae> OOPS
[07:02:58] <Vikinger> also after reading all
[07:03:26] <Vikinger> between having something that can go round in one place and several places, the choice is obvious
[07:09:38] <Vikinger> plus portability
[07:51:41] <Emil> makefiles are cancer imho
[07:51:54] <Emil> The concept they should solve is very simple
[07:52:28] <Emil> but they are constructed in a way that is described as climbing a tree feet first
[08:02:37] <Vikinger> depends how you use them
[08:02:47] <Vikinger> i have seen what you mean
[08:03:00] <Vikinger> you can keep them simple thought
[08:29:48] <Jartza> wassup?
[08:35:27] <Vikinger> all down
[08:35:36] <Vikinger> nothing is up
[08:53:00] <Chillum> clouds
[09:25:26] <Jartza> mmkay
[09:25:48] <Jartza> I'm just watching my attiny5 vga, mesmerized :)
[10:40:08] <_ami_> has any of you worked on i2c drivers for linux before?
[10:57:41] <theBear> not drivers, worked with the userspace a lot over various drivers
[10:59:32] <_ami_> theBear: is there any way to know the bus no of i2c device automatically?
[10:59:58] <Chillum> _ami_: you can scan
[11:00:07] <_ami_> theBear:
https://github.com/amitesh-singh/ldd/blob/master/i2c/i2c-adapter/basic/i2c-client-driver.c#L72 ->
[11:00:16] <theBear> _ami_, i dunno bout automatically, that could mean a lotta things, but what chillum said
[11:01:01] <_ami_> how to you get i2c_adapter pointer in i2c_driver code? i know i can do i2c_get_adapter(bus_no), but i don't have info about bus_no.
[11:01:11] <theBear> i'm probly a bit drunk tgo read that.... you know they ARE assigned automatically by the wait, client driver ?
[11:01:29] <_ami_> like it would fail on different system where i2c bus is not present at 8
[11:01:55] * theBear grew up in an age before os's... he is way better at programming something like a micro than understanding c omplex kernel stuffs
[11:02:10] <_ami_> :)
[11:03:15] <_ami_> theBear: To call i2c_driver probe, i need to add i2c_client to it by using i2c_new_device(). this function needs i2c_adapter *
[11:03:26] <theBear> but why would you wanna/need to know in kernel land ? you would use the userspace to workout which adapter is attached to which devnocde
[11:03:55] <_ami_> theBear:
https://github.com/amitesh-singh/usb-gpio-board - writing i2c driver for this board.
[11:04:22] <_ami_> its a fun activity to learn almost all basic serial protocols (at mcu level as well as driver level)
[11:04:39] <theBear> but, to present as an i2c driver you can't use the gpio driver
[11:05:05] <theBear> unless you were doing a pure soft/userspace gpio<>i2c in which case you wouldn't be in the kernel code
[11:05:52] <theBear> you'd be bangin' in userspace
[11:05:57] <_ami_> MFD kernel framework comes to rescue this.
[11:06:04] <theBear> i dunno what that means
[11:06:19] <_ami_> sorry, its MDF*
[11:06:25] <_ami_> multi-device framework
[11:06:59] <theBear> hmm.... too drunk, if yer still stuck ask me tomorrow :) good lucks
[11:07:49] <_ami_> http://events.linuxfoundation.org/sites/events/files/slides/belloni-mfd-regmap-syscon_0.pdf
[11:08:00] <_ami_> theBear: sure, enjoy ! :)
[11:46:21] <Jymmm> ATmega329v in a Honeywell TH6220D residential thermostat - is it possible to reverse engineer? I'd like to change the delta it uses for aux heat.
[11:55:24] <Jymmm> rue_shop3: Would you recommend?
https://www.aliexpress.com/item/AVR-JTAG-ICE-USB-Download-Programmer-Emulator-Aluminum-Shell-Over-Current-Protection-Wide-Voltage-Buffer-Chip/32345324024.html
[11:56:36] <hypermagic> hi guys
[11:56:45] <aczid> Jymmm: any good manufacturer that uses AVR would try to lock the flash from readout
[11:56:49] <hypermagic> Happy new year
[11:56:54] <aczid> hi hypermagic you too
[11:57:16] <hypermagic> I have a question i have not found the answer to in the manufacturur pdf datasheet
[11:57:56] <Jymmm> aczid: I realize that, but I'm hoping they're being dumbasses (crosses fingers), I have a call into them =)
[11:58:29] <Emil> aczid: depensa
[11:58:31] <Tigzee> aczid, how much would you trust a lock on an atmel device?
[11:58:53] <aczid> as far as I understand, they are among the best in the business when it comes to that
[11:58:59] <hypermagic> Can i use 100mV external voltage reference in an ATMEGA168 device for the successive approximation 10 bit ADC to get increased resolution?
[11:59:01] <Emil> if it is trivial why bother, it is an additional step in manufacturing
[11:59:18] <Emil> Tigzee: you dont?
[11:59:32] <Emil> hypermagic: yes
[11:59:56] <Emil> hypermagic: I don't actually know what's the minimum it goes down to is, though
[12:00:04] <hypermagic> Emil, so i can get full 10 bit resolution with a signal source that outputs 100mV max?
[12:00:07] <Emil> but 100mV should be fine
[12:00:11] <Emil> hypermagic: yes
[12:00:18] <Tigzee> Emil, I don't know...I was curious. I read about people freezing memory and then xraying it...I just wonder how difficult it is to bypass
[12:00:22] <hypermagic> Thanks, i will give it a try then
[12:00:30] <Emil> Tigzee: you can do that to any uc
[12:00:48] <hypermagic> Internal reference is 1.1V and datasheet only says 1V-Vcc
[12:01:13] <Emil> Tigzee: once people enter the realm of thoseside channel attacks it becomes infeasible to prevent them form doing their thing
[12:02:11] <Emil> hypermagic: if datasheet says that the externa reference can be 1V min then that's the way it is
[12:02:20] <Tigzee> Emil, I am not familiar with "those sides" so I don't know if there is a nice way to stop that
[12:02:34] <aczid> there are companies that will remove chip protections for you
[12:02:36] <Tigzee> Emil, or if avr becomes super easy at that point
[12:02:40] <hypermagic> It does not say ;) it is just specified as operating condition
[12:02:54] <aczid> of course they don't reveal their methods ;P
[12:02:57] <Emil> Tigzee: those side channel*
[12:03:49] <Emil> Tigzee: and then you are up to encryption and obfuscation
[12:04:02] <Tigzee> Emil, but I don't think avr does encryption
[12:04:09] <hypermagic> Can you see any reason why the successive approximation ADC could not operate with less than 1V reference voltage?
[12:04:30] <Emil> Tigzee: it costs a fuckton to enter the realm you are talking about and nothing can prptect against it
[12:04:41] <hypermagic> Bilateral switches cannot turn on-off?
[12:04:47] <Emil> hypermagic: well, there could be some minimum reference
[12:04:56] <Emil> hypermagic: switches get power from vcc
[12:05:00] <aczid> Tigzee: bootloaders can do crypto when updating fw, but the code is always in 'normal' form on the flash
[12:05:12] <Emil> aczid: not mecessarily
[12:05:20] <aczid> well, like AVR cryptomemory?
[12:05:22] <aczid> or what
[12:05:33] <Emil> aczid: you can interpret :D
[12:05:38] <aczid> haha yes okay
[12:05:48] <aczid> you can run a java vm on avr
[12:05:49] <aczid> ofc :P
[12:06:11] <Emil> aczid: small assembly interpreter and then rest of flash you just read bytes from
[12:06:18] <aczid> fair enough
[12:06:21] <Emil> aczid: link to that?
[12:06:34] <aczid> hmm I think most SIMs are javacards on avr
[12:06:42] <aczid> but I don't have a good reference for it, sorry
[12:07:11] <aczid> I think that extra layer would incur quite a slowdown
[12:07:17] <Emil> I have been thinking about building yon pseudolanguage that is interpreted and you can save to eeprom
[12:07:21] <aczid> especially since you cannot easily do JIT
[12:07:28] <aczid> because of the harvard arch
[12:07:58] <Emil> aczid: an assembly interpreter could reach 1/8, 1/16 performance
[12:08:18] <Emil> hmm, 1/16 muh closer
[12:08:21] <aczid> yeah sounds about right
[12:08:56] <aczid> but when you are constrained for size/speed, pretty much nobody does that ever
[12:08:59] <Emil> hypermagic: try it
[12:09:13] <Emil> hypermagic: or ask Atmel, they answer quite quickly
[12:09:14] <aczid> it's extra engineering dollars
[12:09:23] <aczid> and chip dollars
[12:09:47] <Emil> Yeah I mean
[12:09:52] <Jymmm> Ask any china chip cloner company =)
[12:10:00] <Emil> If you want secure
[12:10:08] <Emil> and youbare talking about it here
[12:10:16] <aczid> this doesn't sound all that more secure
[12:10:17] <Emil> chances are you cant make it secure
[12:10:50] <aczid> I think all avrs are still susceptible to glitching attacks and power analysis
[12:11:13] <aczid> like most chips...
[12:11:39] <Emil> hmm
[12:11:50] <Emil> profiling that could be a bachelors
[12:11:53] <Emil> or a masters
[12:12:04] <aczid> or a business :P
[12:12:10] <Jymmm> This is only a thermostat, I highly doubt that they would go thru all that trouble. Especially if they need to on-the-fly update firmware on the production line
[12:12:14] <Emil> I should pitch it for the profs at uni
[12:12:16] <aczid> best you can do is tamper detection / tamper resistance
[12:12:34] <Emil> aczid: one can protect against power analysis
[12:12:35] <aczid> and there are ways to code crypto algos so they don't leak power information
[12:12:46] <aczid> right
[12:12:47] <Emil> yeah
[12:12:53] <aczid> but it's not trivial
[12:12:55] <Jymmm> aczid: This aint the NSA ;)
[12:13:06] <aczid> Jymmm: we're just theorising here :)
[12:13:11] <Emil> Jymmm: thats's what the NSA would say
[12:13:17] <aczid> lol spot on
[12:13:25] <Jymmm> aczid: Well, maybe Emil is
[12:13:50] <Emil> Jymmm: nice reverse, I should recommend you for full time, _intern_
[12:13:53] <aczid> brb checking my tin foil hat for power information leaks
[12:13:54] <Emil> Wait
[12:14:04] <Emil> ;D
[12:14:11] <Jymmm> Cause the nsa would say that someone else is't the nsa when they themselves are the nsa, you know three way plausable denability
[12:14:13] <APic> l/g 23
[12:14:16] <APic> Sorry, ww
[12:14:30] <Jymmm> aczid: LICK IT
[12:14:54] <Emil> Jymmm: but the NSA would know that
[12:14:59] <Emil> so thwy dont say it
[12:15:03] <aczid> Emil: there's quite a bit of research (programs) at uni's which have done such analysis - mostly in the context of embedded crypto
[12:15:09] <Jymmm> Emil: You in Utah, aren't you?
[12:15:27] <Emil> Jymmm: ...perhaps, why?
[12:15:36] <Jymmm> BUSTED!
[12:15:54] <aczid> Jymmm: does the thing have an ISP header? it's worth a shot
[12:16:03] <aczid> next best thing would be to snoop on the update process I guess
[12:16:21] <aczid> does it update in the field?
[12:16:38] <Jymmm> aczid: It has six (2x3) "test points"m then another one I think is for suppling power.
[12:16:56] <Emil> Jymmm: the isp header has vcc already
[12:17:01] <aczid> yeah, that is most likely ISP Jymmm
[12:17:02] <Jymmm> Emil works here -->
https://nsa.gov1.info/utah-data-center/
[12:17:07] <aczid> but I'm sure you guessed that too
[12:17:25] <Jymmm> Cool, but the 7th TP I think is part of an automated test
[12:17:29] <hypermagic> Emil, so i could use an opamp gain stage but that would introduce additional components, complexity, so i am hoping i could improve the resolution by only decreasing the external reference by a factor of 10
[12:17:48] <aczid> Jymmm: you can find out with a multimeter what pin it connects to
[12:17:59] <Jymmm> aczid: ISP works for me, especially sonce I dont have an JTAG =)
[12:18:06] <Emil> hypermagic: I know what you want :D But you could consider a small single supply rail to rail opamp here
[12:18:10] <aczid> ain't nobody got cash for that :)
[12:18:16] <Jymmm> aczid: Not right now I can't, it's 28F outside =)
[12:18:29] <aczid> haha, about the same here
[12:18:32] <aczid> -3C
[12:18:33] <hypermagic> Nah, precision resistors and low offset opamps are rare
[12:18:44] <Emil> hypermagic: but imho it should work with 1mmV rwference
[12:18:57] <hypermagic> :)
[12:19:06] <Emil> hypermagic: the AVR ADC isnt exactly good
[12:19:36] <Jymmm> aczid: It's sad that one has to go thru so much drama just to adjust the aux heat delta from 2 to 4 or 5
[12:20:04] <hypermagic> If i take into account that the successive approximation adc looks like this
http://patentimages.storage.googleapis.com/US20130162454A1/US20130162454A1-20130627-D00003.png then we see that the comparator has certain limits :)
[12:20:12] <aczid> Jymmm: if you think this is bad, try jailbreaking a phone :P
[12:20:31] <Emil> Jymmm: mate, stop doxxing me pls (suddenly realizes I'm not irkin from the uni shell so joke about checking my gateway goes out of the window but Im still going to say it)
[12:20:51] <Jymmm> aczid: No need to, I have he bootloader coe straight fromt he factory =)
[12:20:57] <Emil> Jymmm: I mean, you blew my perfect cover, even had my shell placed in "Finland"
[12:21:36] <Jymmm> Emil: Cux yer dumbz.... NOBODY actualyl lives in finland <rolls eyes>
[12:22:03] <Emil> Jymmm: ikr
[12:22:09] <Jymmm> Silly nsa creeper
[12:22:18] <Jymmm> ;)
[12:22:19] <Emil> Jymmm: and you blew it, gonna make sure they never promote you at Langley
[12:23:07] <Jymmm> Emil: That's due to the fact that I would never even visit the south, way too humid
[12:23:38] <Emil> Psh
[12:23:47] <Emil> Everyone know about the Canadian one
[12:23:55] <Emil> I mean, we are the NSA
[12:24:06] * Jymmm could never work for the gubermint
[12:25:01] <hypermagic> Emil, yeah, but if i would use the 1.1V ref with a maximum 110mV input source than i would have 102 datapoint at 110mV approximately 1mV/step from the 10 bit ADC
[12:25:51] <hypermagic> *then
[12:26:19] <Emil> hypermagic: try it
[12:26:31] <Emil> I think it should work with 100mV reference
[12:26:42] <hypermagic> Will do :)
[12:26:43] <Jymmm> oh Damnnnnn, I JUSt saw the header on Emil's workpalace website. thats fucked up
[12:27:25] <Jymmm> "...Securing the Citizens"
[12:27:43] <Emil_> Hey guise
[12:27:51] <Emil_> Totalöy not irkin from Finland
[12:27:56] <Jymmm> It should be followed up with "Your papers pleeease!"
[12:28:22] <Emil> Hi Emil_! How you doiiiiinnn fine ass ;);)
[12:30:29] <Jymmm> Haha, this is funny... nsa is re-publishing leaked content...
https://nsa.gov1.info/dni/
[12:30:47] <Emil> Did the diversion work? Jymm went awfully quiet, didnthe assassins altey arrive
[12:30:50] <Emil> Oh there he is
[12:31:28] <Jymmm> They arrrived, out back with a beer
[12:31:59] <Emil> Nice
[12:32:10] <Emil> And that toolbox is filled with malware
[12:32:23] <Emil> Joonas from downstairs made sure of that
[12:33:10] <Emil> I was just actually watching the Netflix show Travellers (was thay its name?)
[12:33:31] <Emil> And thinking about trying to run a fake counter op on fake messages
[12:34:03] <Emil> Anycase
[12:34:19] <Emil> I'll sleep for the rest of the bus trip
[12:34:44] <Emil> Jymmm: keep the reapers away, you know I'll just send them yoir way if you try something
[20:25:15] <Jartza> oh
[20:25:32] <Jartza> I was scrolled back in irc
[20:26:50] <Tom_L> don't ya just hate it when that happens..
[20:27:04] <Emil> da
[20:32:59] <carabia> okay let's check makeraday
[20:37:08] <carabia> the entries for this 1 kB thing seem retarded for the most part. Then again it's arduinoday, I don't know why I was expecting anything less
[20:38:00] <carabia> most of these things seem retardedly simple and completely missing the (apparent?) point of the whole "challenge"
[20:38:28] <carabia> as in someone was already making a thingamabob, wowzers it fits under 1k, wowzers i'll just submit this.
[20:39:09] <carabia> actually, expecting anything more, should I say
[20:41:39] <Jartza> carabia: well, I submitted yet another retarded thing to that challenge ;)
[20:42:11] <carabia> then there's
https://hackaday.io/project/13100-ocmid this
[20:42:38] <Jartza> https://youtu.be/kUYDQ30lnT4
[20:42:45] <carabia> really using an interpreted language and on fucking x86 or armca, who the fuck gives two shits?
[20:43:10] <Snert> yea. No shits given
[20:43:36] <carabia> Jartza: i'll have to check backlog for something, sec
[20:43:53] <Jartza> carabia: lol... counting all OS functions.... maybe that won't even fit in 1GB :D
[20:44:08] <carabia> yes
[20:45:03] <Jartza> mine is 394 bytes.
[20:45:12] <carabia> and it's an interpreted language in any case, the "application size" seems ambiguous at best.
[20:45:22] <carabia> I think he means the script file is ~1k
[20:45:31] <Jartza> yea
[20:45:39] <Jartza> didn't read the rules, I bet
[20:45:44] <carabia> is a retard, I bet
[20:45:52] <Jartza> :D
[20:45:57] <carabia> Jartza: and nice, the b/g crossover has been solved!
[20:46:00] <carabia> ;D
[20:46:29] <Jartza> yeah
[20:47:01] <carabia> seriously a lot of the entries are something along the lines of "battery charger" "stepper driver"??
[20:47:16] <carabia> it seriously misses the whole god damn point of the competition
[20:47:21] <Jartza> indeed
[20:47:47] <Jartza> I tried something fun, but useless
[20:48:26] <Emil> Jartza: the rules are hand wavy
[20:48:30] <carabia> off a quick glance, my humble opinion is that your submission is one of the few that actually embrace the spirit of the competition
[20:48:46] <Jartza> I already have 2 3d-printers, so my entry wasn't because of prices :)
[20:49:00] <FL4SHK> print out an AVR
[20:49:08] <Emil> The original rules are thay everything must fit into 1k
[20:49:09] <Jartza> hehe
[20:49:29] <Emil> But they are blatantly advertising things that are not 1k
[20:50:24] <oscillo> can you give a link to this competition?
[20:50:53] <carabia> https://hackaday.io/submissions/the-1kb-challenge/list
[20:50:59] <oscillo> ty
[20:52:02] <carabia> Jartza: the competition just should have been 512k, would eliminate a lot of the retards and you would have been a clear winner
[20:52:02] <oscillo> (the openMV on hackaday is very cool)
[20:52:09] <Jartza> oscillo:
https://hackaday.io/project/19248-394-byte-8-color-vga-demo-with-attiny5
[20:52:15] <Jartza> that's my entry :)
[20:52:26] <oscillo> i ll check that ;)
[20:52:27] <carabia> 512b, even.
[20:52:33] <Jartza> hehe
[20:52:38] <carabia> B, even.
[20:52:45] <carabia> even.
[20:53:10] <oscillo> I m a simple man, I see FFT, I upvote
[20:53:12] <carabia> but i guess the built-in arduino stuff probably takes up the majority of that so, can't have that.
[20:53:21] <Jartza> today I looked at the code. it's not even very optimized, could be made smaller
[20:53:36] <Jartza> I might extend that demo later, just for fun
[20:54:15] <carabia> oscillo: yeah the fft was borderline interesting but i didn't check it as the output was like 3 leds, boring
[20:54:54] <Emil> where is fft?
[20:55:20] <oscillo> Emil :
https://hackaday.io/project/18855-attiny13-dance-lights-with-fft
[20:55:50] <oscillo> carabia : indeed the ouput is not that exciting :)
[20:57:07] <Emil> aww
[20:57:11] <Emil> just dft
[20:57:55] <Emil> and using modulo?
[20:57:58] <Emil> That's bad
[20:58:05] <Emil> could shave bytes
[20:58:06] <oscillo> Emil : well...fft is a dft implementation no?
[20:58:33] <oscillo> Jartza : I ve never seen an avr used like that :) gj!
[20:59:16] <Emil> and why is delay included
[20:59:41] <Emil> oscillo: fft and dft are different and only a fool would call dft fft
[21:00:08] <Emil> Hmm
[21:00:17] <Emil> I should adapt the code
[21:00:42] <oscillo> Emil . sorry then I m a fool. I thought FFT was an implementation of DFT
[21:01:40] <Emil> Yes, the end result is the same
[21:01:56] <Emil> oscillo: but if you call dft fft then please out
[21:02:11] <oscillo> Emil : we are talking about fast fourrier transform vs discret fourrier transform right?
[21:02:53] <Emil> yed
[21:02:54] <Jartza> oscillo: thanks :)
[21:02:57] <Emil> yes
[21:03:02] <Emil> and using those bit shifts
[21:03:15] <Emil> I hope the compiler optimises them out
[21:03:31] <oscillo> Emil : then FFT is an algorithm to calculate the DFT no? Could you explain me how this is wrong
[21:04:40] <Emil> oscillo: how can you fail to see thay you can't just call dft fft
[21:05:00] <Emil> if you want to be silly you can call fft dft
[21:05:08] <Emil> but not the other way around
[21:05:17] <oscillo> Emil : not thanks to your explanation :(
[21:06:14] <Emil> oscillo: read on the wiki, gives better and less disgruntled response
[21:06:40] <oscillo> Emil . will do
[21:09:07] <oscillo> Emil: is your all point about the fact that the code is calculating the dft without using fft?
[21:10:48] <Emil> oscillo: well, it is named dft
[21:10:56] <Emil> and it is used like dft
[21:11:21] <Emil> so yeah, it calculates the dft without fft
[21:11:29] <oscillo> yes ok
[21:11:45] <Emil> but that's okay if you only care about some frequencies
[21:12:09] <oscillo> so I didn t totally misunderstood.
[21:15:06] <oscillo> Emil : also, would you have a link explaining this more in depth please?
[21:15:15] <Emil> oscillo: but you now understand that you cant call dft fft
[21:15:22] <Emil> oscillo: just google fft
[21:15:25] <Emil> and take wiki
[21:16:12] <oscillo> Emil : dft != fft this I already understood.
[21:17:24] <oscillo> Emil : I never said they were the same. Only said fft was a dft implementation
[21:18:16] <oscillo> Emil : anyway :) have fun reworking the code from the dancing led author
[21:22:09] <Jartza> I should extend the demo some
[21:24:46] <Jartza> maybe that curvy wave could have short scrolling text
