Back
[02:41:54] <dgriffi> sabor: you around?
[02:45:22] <sabor> dgriffi: yes, here :)
[02:45:48] <dgriffi> https://github.com/DavidGriffith/bluebox-avr
[02:50:56] <sabor> wow, looks nice
[02:51:03] <sabor> good work
[02:51:06] <WormFood> agreed, looks cool
[02:51:07] <dgriffi> thanks
[02:52:57] <dgriffi> I'm starting to get glitches in my prototype due to messy soldering on ringed perfboard and green crud
[02:53:35] <dgriffi> the PCB seems mostly solidified
[02:55:20] <sabor> what kind of glitches?
[02:56:04] <dgriffi> sabor: false triggering of key 13
[02:56:56] <dgriffi> if I bang the edge of the board on my bench, it seems to knock it into shape for a while
[02:57:24] <abcminiuser> Nooooo
[02:57:39] <sabor> dgriffi: maybe you could do something with better filtering
[02:57:46] <abcminiuser> Someone make a free service that notifies me if the new EEVBlog uploads has his kids in it
[02:58:06] <dgriffi> sabor: where?
[02:59:07] <sabor> dgriffi: the question is if it is noise at the input and how much
[02:59:25] <sabor> maybe a capacitor helps, or maybe you have to do some filtering in software
[02:59:25] <dgriffi> sabor: I upped the cutoff for the difference between 0V and key 13 because when I was using it with the programmer attached, the programmer emitted slight voltages right into the resistor ladder
[03:01:40] <dgriffi> touching the backside of the board also seems to cause trouble.
[03:02:02] <sabor> yes, it's normal that the programmer does things like that, maybe put a switch between the programmer and that pin so you can quickly switch to "programming mode"
[03:03:58] <sabor> yes, that's also normal, your pull-up has a pretty high value, and humans resistance will then change the voltage of the ADC input
[03:15:29] <megal0maniac> abcminiuser: !
[03:17:58] <megal0maniac> I'm looking at making an SPI flash programmer with an xmega using LUFA. I want to ask you stuff but I haven't done enough actual work to have any questions :P
[05:54:26] <Emil> Hey
[05:54:31] <Emil> If I do UDR0=ADCH;
[05:54:59] <Emil> Is that a single cycle operation which does not affect SREG?
[05:55:24] <Thrashbarg> try compiling it and disassembling it to see
[05:56:14] <Thrashbarg> I suspect it'd need an intermediate register to do it, so probably not
[05:58:12] <Emil> Hmm
[06:07:59] <skz81> with -Os, needs two instructions :
[06:08:02] <skz81> lds r24,121
[06:08:02] <skz81> sts 198,r24
[06:08:47] <Thrashbarg> yea
[06:09:04] <Emil> Damn
[06:09:12] <Emil> That blows
[06:09:23] <Emil> But if I'm not running anything in main loop does it matter?
[06:09:28] <Lambda_Aurigae> so mod it.
[06:09:32] <Thrashbarg> The AVR doesn't really have an I/O to I/O transfer instruction
[06:09:38] <Lambda_Aurigae> true.
[06:09:43] <Emil> Lambda_Aurigae: mod it?
[06:09:54] <Lambda_Aurigae> modify the assembly code to fit what you want.
[06:10:30] <Emil> https://emil.fi/jako/mic.c.txt for what I'm doing
[06:11:20] <Lambda_Aurigae> unfortunately, everything pretty much goes through a register on the AVR
[06:11:44] <Emil> I wonder if this works
[06:11:45] <Thrashbarg> Emil: given the serial port is absolutely going to run slower than the AVR, you're not going to lose out on much by having a 1 cycle delay
[06:12:09] <Emil> Thrashbarg: Point is that ISR_NAKED doesn't generate preamble
[06:12:39] <Emil> Which is good
[06:12:42] <Thrashbarg> okay
[06:12:58] <Emil> If I am forced to use the normal interrupts there's a ~40 cycle overhead
[06:13:04] <Thrashbarg> yeah
[06:13:08] <Emil> because the preamble generator is stupid
[06:13:12] <Emil> and not adaptive
[06:13:22] <Thrashbarg> is there the facility to generate an interrupt when the ADC completes a sample?
[06:13:25] <Lambda_Aurigae> but, why LDS rather than IN ?
[06:13:35] <Emil> Thrashbarg: There is
[06:13:41] <Thrashbarg> Lambda_Aurigae: memory mapped I/O I assume?
[06:14:00] <Emil> Thrashbarg: But that is limited to the granularity of the ADC clock
[06:14:08] <Lambda_Aurigae> IN is specifically for i/o locations
[06:14:39] <Lambda_Aurigae> and OUT is also...rather than sts
[06:14:45] <Lambda_Aurigae> half the cycles too.
[06:14:48] <Thrashbarg> depends if it's I/O mapped or memory mapped
[06:14:52] <Lambda_Aurigae> might not exist on all devices I guess.
[06:14:57] <Thrashbarg> yea
[06:19:39] <skz81> Lambda_Aurigae, you mean, why my disasm code uses LDS/STS instead of IN and OUT ? Dunno why actually
[06:20:12] <skz81> BTW : I compiled with avr-gcc for an atmega328
[06:20:16] <Lambda_Aurigae> skz81, was just thinking, if those commands are supported in your chip, change the assembly and reassemble it.
[06:20:29] <Lambda_Aurigae> save 2 cycles at least if it works.
[06:25:04] <skz81> After some thinking : it is probably related on how register address are declared in <avr/io.h>, and know they are declared as memroy adress (as Trashbag said)
[06:25:23] <Thrashbarg> who?
[06:25:36] <carabia> Trashbag.
[06:26:03] <Thrashbarg> heh
[06:26:12] <skz81> but why -Os is not able to crush on this statement...
[06:26:29] <skz81> Sorry Thrashbarg
[06:26:30] <skz81> misread
[06:26:37] <Thrashbarg> yea
[06:26:39] <skz81> Trashbag is a nice nick too
[06:26:40] <carabia> Trashbag vs sk8rboi. Round 1, go
[06:30:22] <sabor> skz81: the answer is simpel: IN/OUT support only 6 bit address so only the first 64 registers can be read/written
[06:34:43] <skz81> sabor, unsure this is a reason. UDR0, ADCH, and so on ARE addressable from that space IIRC, so gcc should be able to optimize, at least when using a direct value as an address....
[06:38:27] <skz81> sabor, OK you're right
[06:39:29] <skz81> The ATmega328/P is a complex microcontroller with more peripheral units than can be supported within the 64 location reserved in Opcode for the IN and OUT instructions. For the Extended I/O space from 0x60 - 0xFF in SRAM, only the ST/STS/STD and LD/LDS/LDD instructions can be used.
[06:40:31] <skz81> (quoted DS)
[06:46:20] <Emil> avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x41
[06:46:25] <Emil> Should I care about this?
[06:46:33] <Emil> Programming through a serial bootloader
[06:47:52] <Lambda_Aurigae> did it work?
[06:48:02] <Emil> Apparently
[06:48:05] <Emil> But still wondering
[07:11:50] <Emil> Here's final code for 48kHz sampling of adc and pushing it through serial at 0.5Mbaud
https://emil.fi/jako/mic.c.txt
[07:13:21] <Emil> Samplerate is at 23,9774kHz and very stable
[07:13:40] <Emil> Sorry, twice that
[07:15:27] <Emil> Less than 0.1% of difference to 48kHz
[08:59:18] <theBear> 1/5th that :)
[11:25:29] <NicoHood> If i want to write a lib that relies on a compile time constant, how should i define it? via -D compiler switch, via -I compiler include, via include of a general settings file or via extern const int? I tend to use the general settings.h include or -I settings.h include as a #define give more optimization that a fixed integer sometimes, right?
[11:26:16] <LeoNerd> I usually end up with a src/local-config.h that gets pulled in to places
[11:26:30] <LeoNerd> E.g. that contains the port/pin number assignments for my soft-uart implemenation
[11:27:48] <twnqx> i call mine appconfig.h :D
[11:28:36] <twnqx> i just noticed an inconsistency
[11:28:42] <twnqx> #define CTS0_PORT E
[11:28:43] <twnqx> #define CTS0_PIN 2
[11:28:43] <cehteh> i have way too much -D in my makefile config
[11:28:50] <twnqx> but
[11:28:56] <twnqx> #define SJA1000_RST_PORT D
[11:28:56] <twnqx> #define SJA1000_RST_MASK 0x80 /* PD7 */
[11:28:57] <twnqx> >_>
[11:29:31] <cehteh> but, the appconfig.h method has the drawback, that when you only change one little thing, the whole project has to be rebuild because everything depends on the config.h
[11:30:08] <cehteh> usually not a problem with avr programs since they are small and compile very fast, but not exactly elegant either
[11:31:48] <LeoNerd> I rebuild everything all the time anyway
[11:31:54] <LeoNerd> A lot of gcc's -flto only works that way
[11:32:08] <cehteh> huh?
[11:32:22] <cehteh> lto works here with partial recompiles
[11:32:43] <cehteh> well the linker does the big job then
[11:33:05] <LeoNerd> Yeah that *effectively* defers most of the work into the linker anyway
[11:33:37] <LeoNerd> In any case, I find that my AVR burner is slower than the compiler anyway... :)
[11:34:05] <cehteh> yes
[11:35:08] <cehteh> well i used the makefile on mµOS to experiment a bit about some building strategies, and prolly will improve that in future as well
[11:36:37] <cehteh> eventually it should do real minimal builds even with LTO, figuring out what confvars each file needs and depend only on them
[11:36:56] <cehteh> but thats more a makefile excercise than real need
[11:39:07] <NicoHood> cant i pass a file via -Idefined.h?
[11:39:32] <NicoHood> isnt there a compiler switch that a header file gets included in every file?
[11:41:06] <NicoHood> or can i only add folders as include path and still need to include the file defines.h in my library?
[11:41:58] <NicoHood> ah via -include not -I
[11:43:26] <LeoNerd> -include on the commandline will be quite subtle to users reading the source code
[11:43:41] <LeoNerd> #include "local-config.h" or equivalent will be a lot more obvious as to what's going on
[11:43:55] <NicoHood> hm you might be right
[11:44:13] <LeoNerd> Also things like code completion in editors and IDEs and whatnot can often follow #include directives
[11:44:27] <LeoNerd> E.g. the usual "jump to definition" tools that people tend to like
[11:44:34] <NicoHood> is there a defintion for the SPI pins like this? DDR_SPI_USART
[11:46:50] <LeoNerd> SPI_USART ?
[11:47:12] <NicoHood> yes. or normal SPI whatever you like
[11:47:22] <LeoNerd> I'm not sure I understand the question
[11:47:30] <NicoHood> I need PORTB for example for the normal SPI
[11:47:33] <LeoNerd> In fact furthermore, I'm pretty sure that I don't understand the question
[11:47:59] <NicoHood> arduino also adds those definitions. that you have a definition for MOSI on every arduino board
[11:48:12] <NicoHood> but instead of arduino pins i need the DDR and PORT etc
[11:48:26] <NicoHood> isnt there something like that in the avr-libc?
[11:49:09] <LeoNerd> Oh I see.. hrm..
[11:49:11] <LeoNerd> Not aware of one, no
[11:49:58] <LeoNerd> I tend to define them custom each time for various chip tyoes
[11:49:59] <LeoNerd> types
[11:50:12] <LeoNerd> It's far more than just the positions of the IO ports that changes
[11:52:07] <NicoHood> https://github.com/vancegroup-mirrors/avr-libc/blob/06cc6ff5e6120b36f1b246871728addee58d3f87/avr-libc/include/avr/iotn20.h#L680
[11:52:08] <LeoNerd> http://paste.debian.net/856665/ <== e.g. my SPI driver
[11:52:34] <LeoNerd> Oooh.. curious
[11:52:38] <LeoNerd> I didn't realise libc did that
[11:53:05] <LeoNerd> I could probably make use of those instead
[11:53:08] <NicoHood> the question now is, if they also have this for usart
[11:55:44] <NicoHood> but those definitions are not available for every MCU it seems :////
[11:56:07] <LeoNerd> That sounds like more of a bug/oversight in the .h files perhaps. Maybe some bug reports? :)
[12:06:45] <NicoHood> they are missing in lots of files
[12:06:59] <NicoHood> meh
[12:07:08] <NicoHood> that tons of work to add
[12:07:14] <NicoHood> i dont think anyone will do this
[12:08:03] <_ami_> http://www.amazon.in/Motors-Makers-Steppers-Electrical-Machines/dp/9332573689/ref=sr_1_1?ie=UTF8&qid=1475599156&sr=8-1&keywords=motors+for+makers => amazing book! its a godsend
[14:01:43] <WormFood> dgriffi, Are you around? I wanted to ask you a question about your bluebox code.
[14:07:14] <WormFood> The link to the sine table generation is broken (the link itself is good, but the calculator is broken). What exactly is that table doing? I can see the values go up and down, in the pattern of a sine wave, and I think I understand what you're doing with PWM to get the frequency out, but I don't understand how it changes frequency.
[14:13:10] <carabia> Dropped all intentions opening ami's link when i spotted "makers"
[14:15:06] <carabia> well okay, i gave in... author's other works include but are not limited to "Building Web Components with TypeScript and AngularJS 2"
[16:14:52] <NicoHood> would it make sense to check the transmit flag for sending SPI data in this case:
https://gist.github.com/NicoHood/86185ab99a412c6591edf1c41cfb92ed#file-spi-c-L15 ?
[16:15:17] <NicoHood> if you received a byte with SPI the sending should be over too or am i wrong?
[16:15:33] <NicoHood> as the sending is started first. (master mode)
[17:10:29] <anonnumberanon> I need a really quick call to turn off a pin on a certain port. How could I do it??
[17:12:00] <anonnumberanon> This is what I have so far, is this correct?
https://paste.debian.net/hidden/7c5f48c9/
[17:16:34] <NicoHood> anonnumberanon: not sure what the sense of the code is, but that looks like what you want
[17:19:49] <anonnumberanon> NicoHood, Now I want starting at line 47 to turn off the pins as fast as possible, does the if statement and the struct data structure add overhead? I really want this to be almost immediate.
[17:25:01] <NicoHood> if and structs always add overheads
[17:25:15] <NicoHood> but you'd better look at the assembler or use a logic analyzer to verify
[17:25:28] <NicoHood> for such a smaller sketch its possibly optimized away
[17:27:57] <anonnumberanon> I was wondering if there was a better way to toggle on a pin that is in an array. Maybe a low-level macro.
[17:28:05] * anonnumberanon checks his macros file
[17:33:55] <anonnumberanon> ah i found something i may be able to use to reduce binary size
[17:34:01] <anonnumberanon> maybe that will be faster
[17:40:47] <anonnumberanon> In AVR C what is the type of PORTC ? What about a bitmask like B01010101?
[17:50:09] <A124> uint8_t I guess
[17:50:13] <A124> anonnumberanon
[18:00:35] <NicoHood> A124
[18:00:47] <NicoHood> is it: Read into a byte array --> in, to or into?
[18:03:38] <A124> NicoHood into is fine
[18:04:20] <A124> 'To' is correct also I think, but not sure. ##english .. wonder if it exists.
[18:53:35] <theBear> as usual, and forgive me if this is more than just a mild non-chemical flashback, but it depends what yer wanna say.... if you reading a list of somethings "in -> to" an array or a tape recroder you doin in to, two seperate actions.. you can read a value (in <- redundant and arkward withthout more context to cancel them out) and ummm, into... hmmm, is that even a real word ?
[18:53:43] <theBear> i spose
[18:53:47] <theBear> i go into the disco
[18:54:00] <theBear> i go to infinity and into the beyond
[18:54:41] <theBear> into is kinda err, like whom i guess.... which means you needs words i forgot to accurately describe when and where
[18:54:44] <theBear> ☺
[18:54:47] <theBear> wtf !
[18:55:07] <theBear> how the balls did i do a smiley ?
[18:55:28] <Thrashbarg> someone hold him down
[18:55:58] <theBear> is it the late 80s again, and we can all happily do up to and including all 256 visible and not, cool and uncool ansi symbols with the keypad ?
[18:56:30] <theBear> don't panic, i'm halfway thru repairs, i'll be gone any moment
[22:52:41] <dgriffi> WormFood. I fixed that URL. I barely understand PWM myself. I had a lot of help from Sabor here.
[22:52:58] <dgriffi> ugh... wormfood is gone
[22:55:02] <dgriffi> Worm
[22:56:07] <dgriffi> WormFood: the basic thing that's going on there is if you sample the sine table at rate A, you get one frequency. Sample it at a rate of A+B, you end up with a sine wave with a higher frequency
[22:57:04] <dgriffi> WormFood: The business with the SAMPLES_PER_HERTZ_TIMES_256 gives a broad hint of that
[22:57:55] <dgriffi> WormFood: it's a little weird because that computation wound up being computed at runtime if I did it any other way, leading to something overflowing and rolling over
[23:11:36] <rue_house> he trying to generate audio freqs with pwm on an avr?
[23:13:52] <dgriffi> rue_house: he had questions about my bluebox-avr code
[23:14:40] <dgriffi> I was working with Sabor here over the past week to get an approximate sine wave out of an ATtiny85
[23:15:01] <dgriffi> rue_house: the results are here:
https://github.com/DavidGriffith/bluebox-avr
[23:15:07] <rue_house> at what freq tho?
[23:15:24] <rue_house> iirc you cant do 8 bit at 60Hz with 256 samples
[23:15:35] <dgriffi> from about 500 to 1800 hz
[23:15:59] <rue_house> ok, if your down to about 4 or 6 bits I can see it maybe
[23:16:06] <dgriffi> oh, sample freq..
[23:16:23] <rue_house> no, sample resolution
[23:16:27] <dgriffi> it's at 7-bits so that when two sines are added, it all fits in 8 bits
[23:16:43] <dgriffi> I think it's 256khz
[23:16:46] <rue_house> you need atleast 2x the freq your trying to generate, higher if your filtering out the pwm
[23:17:07] <rue_house> you should be using a resistor based dac, not pwm
[23:17:12] <dgriffi> I'll have to ask Sabor again so I can properly document the code
[23:18:09] <rue_house> you know, I'm prettymuch convinced that people cant think
[23:18:19] <rue_house> I'm starting to belive they dont even try
[23:21:25] <rue_house> lots of people, but not all people
[23:21:33] <dgriffi> you're not referring to me, are you?
[23:22:06] <rue_house> dunno, but i fear I'm reduced to exploiting them for money
[23:22:21] <rue_house> its not what I want to do, I just need to accelerate the progress in my life
[23:22:38] <rue_house> but, I'm thinking its really easy
[23:22:47] <rue_house> *sigh*
[23:33:51] <sabor> dgriffi: your timer creates a PWM with 62.5kHz, if you would output eactly 256 samples per sine wave you get a 244Hz sine, for higher frequencies some of the samples are skipped
[23:37:24] <sabor> rue_house: for a resistor dac an attiny doesn't have anough pins, especially when a lot are already used for other things
[23:37:43] <sabor> so much for thinking people...
[23:38:18] <rue_house> I think you will find the challanges when you go to filter out the pwm
[23:38:53] <WormFood> dgriffi, I was here, just not under my normal nick. Thanks for your response.
[23:38:58] <sabor> i think he goes to 3kHz or 3.6kHz max, so the filter shouldn't be a problem
[23:40:22] <WormFood> rue_house, I was just trying to understand how it works, as I'm curious. I can see uses for other projects, and it looks really cool. I understand most things going on there, but I'm missing something.
[23:40:36] <rue_house> http://www.publicsurplus.com/sms/docviewer/aucdoc/101_1614.JPG
[23:40:48] <rue_house> see? its a nortel phone with "bellsouth" on it
[23:41:14] <rue_house> WormFood, do you know about the 3db/decade rule for passive filters?
[23:41:34] <WormFood> I don't think so
[23:42:32] <rue_house> for a 10x in freq, your signal drops by half
[23:43:12] <WormFood> I understand. Wasn't aware of the specific numbers tho
[23:43:28] <rue_house> so, if you have a signal modulated at 1Khz, and you want to attenuate the modulation by 1/4, the highest freq you can get thru it is 10Hz
[23:43:54] <rue_house> pwm isn't sine wave, its square wave
[23:44:12] <rue_house> so the frequncies your trying to filter out are mostly high
[23:44:16] <WormFood> of course, but it's average simulates a sinewave
[23:44:46] <sabor> rue_house:
https://en.wikipedia.org/wiki/Low-pass_filter
[23:44:48] <WormFood> Oh, you're talking about the filter aspect of it. Now what you're saying makes a LOT more sense
[23:45:09] <sabor> rue_house: it's half for double frequency, not 10 times
[23:45:33] <WormFood> Actually, he said 10x, but I was thinking 2x in my mind.
[23:47:41] <sabor> so if you have 62kHz pwm and a filter with cut-off at 6kHz you get only 1/10th of the amplitude of the pwm frequency
[23:47:56] <rue_house> no
[23:48:08] <sabor> though that's still pretty much, i'd recommend a better filter
[23:48:18] <rue_house> -3db is half the signal
[23:48:19] <sabor> rue_house: look at that wikipedia page
[23:48:24] <rue_house> -3db / decade
[23:48:30] <sabor> rue_house: your -2db rule is wrong
[23:48:31] <rue_house> the decade is 10x freq
[23:48:39] <rue_house> its -3db
[23:48:41] <sabor> err -3db rule
[23:48:48] <sabor> it is 20db per decade
[23:48:56] <sabor> read the wikipedia page
[23:49:02] <rue_house> -3db / decade for a signal stage passive filter
[23:49:07] <rue_house> no, I know what I know
[23:49:15] <rue_house> you have something you dont know mixed up
[23:49:20] <sabor> proove it :)
[23:49:22] <rue_house> and I'm gonna leave that as your problem
[23:50:10] <rue_house> I already solved the problem
[23:50:25] <rue_house> I came up with a ROM image that has the pwm raw stored on it
[23:50:55] <dgriffi> sabor: so, what was the PWM frequency that I ended up with?
[23:51:12] <rue_house> when I chug thru it at about 20Mhz, it generates 8 bit, 512sample/cycle sine wave for 60Hz
[23:51:25] <sabor> dgriffi: 62.5kHz, it is 16MHz/256
[23:51:50] * rue_house goes to check that freq
[23:51:54] <dgriffi> clock speed over 256 in other words?
[23:53:37] <dgriffi> WormFood: I started by borrowing code from
https://github.com/occamsshavingkit/port-o-rotary. when that didn't work, I asked about the problem here
[23:54:18] <dgriffi> WormFood: the implementation there was good enough to simulate a dial tone, but at higher frequencies, I'd get that overflow/wraparound problem
[23:55:17] <sabor> rue_house:
https://paste.apache.org/W3pt see it is -20dB :)
[23:55:30] <rue_house> apparently its got an 8Mhz crystal on it
[23:55:55] <rue_house> I think part of the advantage I had was that I was feeding it into a transformer to generate AC power
[23:56:49] <sabor> dgriffi: the timer is counting from 0 to 255, so 256 values, and its prescalre is 1, that's why it is clock speed over 256
