#avr Logs
Apr 13 2018
#avr Calendar
12:01 AM _ami_: i know, its crazy.
12:04 AM _ami_: its just an experiment on how stable output i can get from a low pass filter without using DAC IC. :D
12:08 AM rue_mohr: did you consider just using 1 bit dac
12:09 AM _ami_: on-off you meant? :)
12:19 AM _ami_: rue_mohr, as you know those cheap buck boost converter chips have a feedback pin.
12:26 AM _ami_: ah
12:26 AM _ami_: did not know.
12:26 AM * _ami_ googles
12:27 AM rue_mohr: http://ruemohr.org/~ircjunk/tutorials/elex/1bitanalog/p1080671.jpg
12:27 AM rue_mohr: http://ruemohr.org/~ircjunk/tutorials/elex/1bitanalog/p1080670.jpg
12:27 AM rue_mohr: http://ruemohr.org/~ircjunk/tutorials/elex/1bitanalog/
12:27 AM rue_mohr: you can see the performance as I dial up the clock rate
11:50 AM dStruct: what would be the best recommended way to store and parse a 16-bit word on a 328p? byte or word array?
11:51 AM dStruct: polprog: btw I got it sorted out
11:51 AM polprog: Nice
11:52 AM polprog: I tend to keep data as uint8_t arrays
11:52 AM polprog: Since its an 8 bit cpu. 16 bit ints could do as it has some 16 bit operations
11:52 AM dStruct: polprog: yeah, I did exactly what you recommended and did a state machine in the ISR set a flag bool for clock high/low and based all the logic off that
11:53 AM cehteh: there us uint16_t
11:53 AM cehteh: is
11:53 AM dStruct: polprog: well I have 16-bits (possibly as much as 20-bits maybe later) of boolean input I need to parse out serial
11:53 AM cehteh: (or int16_t)
11:54 AM dStruct: so I'm doing basically if(data & _BC(cPeriod)) { //data line HIGH }
11:54 AM dStruct: err BV
11:54 AM cehteh: what operations do you need to do?
11:54 AM cehteh: shifting out via uart? bitbanged?
11:55 AM dStruct: cehteh: I just need to if when it's high and set PB1 high, i'm essentially doing shiftOut but bitbanged with my own clock
11:56 AM cehteh: shift out is possibly more efficient when you work on 8 bits a time, first (for 8 bits) shift the first byte out then the next insteads shifting the whole 16/20/32/whatever bits
11:56 AM dStruct: cehteh: I'm outputting 3 lines, clock, data, and sync, 10khz clock, data is 1 clock period (high and low) per bit, and sync just identifies what word I'm sending
11:56 AM dStruct: cehteh: I was having some very unexpected results with shiftOut, and it generates it's own clock with the output which I need a constant clock regardless of any data
11:57 AM cehteh: in an ISR? or in a loop?
11:57 AM dStruct: cehteh: both
11:58 AM cehteh: should be simple, but i'd prepare the data in some way that you can send that out in an atomic way (if necessary)
11:58 AM dStruct: cehteh: the data prep is good, I'm just working out what the best efficient way would be to store and parse it
11:58 AM cehteh: aka when all your data is on PB then use the 'toggle pin' facility and toggle all bits with one instruction
11:59 AM dStruct: data read only has to happen twice a second
11:59 AM cehteh: then i dont really understand your problem, looks trivial to me
12:00 PM dStruct: cehteh: oh I don't have an issue, just wondering the best way to store and parse it out, I think I may try uint16_t, I was using a byte array but it seems inefficient
12:00 PM cehteh: what do you need to parse?
12:00 PM dStruct: 16-bits of boolean
12:00 PM cehteh: byte array should be most efficient when done right
12:01 PM cehteh: note that shifts on avr are only shift-by-one
12:01 PM cehteh: when you shift multiple places it (the compliler) needs a loop (or unroll it)
12:02 PM dStruct: cehteh: basically I'm buffering 16-bits and then shifting them out serial on a 32 cycle repeating period each half second
12:02 PM cehteh: when you want to shift more than 8 bits (single word) then even more work over some carry flag is required
12:03 PM cehteh: also, do you want to optimize for code size, memory size, speed?
12:03 PM dStruct: cehteh: I'd like to optimize for speed
12:03 PM dStruct: cehteh: my code is only 874 bytes and vars are 13 bytes :D
12:05 PM cehteh: i'd try with something like for(uint8_t mask = 1; mask; mask<<) {PB1= !!(value_to_shift&mask);} /*sketch you may want to use BV_*/
12:05 PM cehteh: aka shifting a mask along the value
12:06 PM cehteh: err forgot <<1 :)
12:06 PM cehteh: or other direction, whatever you need
12:31 PM dStruct: polprog: so to give you an idea of the existing stuff I'm replacing, currently I have a bunch of 2N2222's a SN7400 quad nand gate, and even more resistors generating 10khz, and sending that to about 10 other quad nand gates, and then shifting data with 8 SN7495's to do what this little 328p is now doing :D
12:43 PM Emil: ohshit
12:43 PM Emil: I bought this esp8266 programming tool
12:43 PM Emil: _super_nice_
12:43 PM Emil: hardware wise
12:43 PM Emil: it did cost 14€
12:43 PM Emil: but _super_nice
12:43 PM Emil: lets see if it werks
12:44 PM * dStruct queues up Darude Sandstorm...
01:21 PM Emil: 2018-04-13 20:53:42 +0300 < Elepaja> [emilfihlman] <photo> https://elepaja.fi/telegram/media/AgADBAAD_60xGww1iVLUDNwodNRutENYoBoABNzefAtytZOKR74AAgI.jpg
01:21 PM Emil: 2018-04-13 20:53:42 +0300 < Elepaja> [emilfihlman] <photo> https://elepaja.fi/telegram/media/AgADBAAErjEbDDWJUsYpMBS404qV2UyRGgAEWuv43bciV3xqaQEAAQI.jpg
01:21 PM Emil: 2018-04-13 20:53:42 +0300 < Elepaja> [emilfihlman] <photo> https://elepaja.fi/telegram/media/AgADBAADAa4xGww1iVLQPsKqfwXQv48KmhoABCALT8VFyXgy-bkAAgI.jpg
01:21 PM Emil: 2018-04-13 20:53:43 +0300 < Elepaja> [emilfihlman] <photo> https://elepaja.fi/telegram/media/AgADBAADAq4xGww1iVKY8TRwZS9GNmzXnhoABBk9s_U08vf5wLkAAgI.jpg
01:21 PM Emil: Lets see if it werks
01:35 PM Ameisen: [11:51:17] <polprog> Since its an 8 bit cpu. 16 bit ints could do as it has some 16 bit operations
01:35 PM Ameisen: if the data is 16-bit, at some point you have to cast it to a 16-bit value/reference
01:35 PM Ameisen: to perform operations on it
01:35 PM Ameisen: I mean, you could do the 16->[8,8] operations yourself, though the compiler will probably do a better job
01:35 PM polprog: True
01:36 PM Ameisen: and remember that if you have strict aliasing on, there's limits to things you can cast
01:36 PM polprog: So my suggestion was use 8 bit array, or a 16 bit in if the data is 16 bits
01:36 PM Ameisen: usually best to keep the arrays typed appropriately
01:36 PM Ameisen: 20-bit data... makes it more complicated, though.
01:36 PM Ameisen: no good way to represent that.
01:36 PM Ameisen: You can handle it seamlessly in C++, though I don't know what he's using
01:40 PM Emil: hm?
01:40 PM Emil: using bitfields is super easy
01:40 PM Emil: in c
01:41 PM Ameisen: Ok, write me something that gives me array-access semantics for an 'array' of 100 20-bit integers.
01:41 PM Ameisen: You can use bitfields, but you can't trivially make it into an array.
01:42 PM Emil: struct {u24 value:20;} u20arr[100];
01:42 PM Ameisen: That's not tightly packed.
01:43 PM Ameisen: every element has 4 bits of packing.
01:43 PM Emil: moving the goalpost I see
01:43 PM Ameisen: I asked for an array of 20-bit itnegers
01:43 PM Ameisen: not an array of 24-bit integers.
01:43 PM Emil: It is an array of 20 bit integers
01:44 PM Ameisen: No, it's an array of 24-bit integers with implicit masking
01:44 PM Emil: lol
01:44 PM Ameisen: sizeof(u20arr) != sizeof((20 * 100) / 8)
01:44 PM Emil: struct asdf {char a; int b;};
01:45 PM Emil: "I didn't ask for that size!!!!!111!oneoneoen!"
01:45 PM Emil: Ameisen: just stop
01:45 PM * Ameisen sighs
01:45 PM * Emil sighs even more
01:45 PM Ameisen: Someday, you C programmers will learn that 20 != 24
01:45 PM Emil: No
01:45 PM Emil: hopefully you someday learn to state requirements
01:45 PM Ameisen: I did state requirements. You made assumptions.
01:46 PM Emil: no
01:46 PM Ameisen: You provided me with an array of uint24s.
01:46 PM Emil: you stated: "give me array of 20 bit integers
01:46 PM Emil: "
01:46 PM Emil: I did give oyu that
01:46 PM Ameisen: Yes, and in every single damned parlance, including in the C spec, an array is _tightly packed elements_
01:46 PM Emil: just so happens the compiler will use padding
01:46 PM Emil: Ameisen: NO
01:46 PM Emil: Ameisen: you are fucking with the spec
01:46 PM Emil: Ameisen: the C spec is clear on having _byte_sized_limits
01:47 PM Emil: yes C++ probably allows space efficient packing
01:47 PM Ameisen: [13:45:37] <Emil> Ameisen: the C spec is clear on having _byte_sized_limits
01:47 PM Ameisen: which is _exactly why you cannot do _t
01:47 PM Ameisen: it_
01:47 PM Ameisen: which was my point
01:48 PM Ameisen: you literally cannot define a true array of uint20s in C.
01:48 PM polprog: Just make an external SRAM with 20 bit wide addresses /s
01:48 PM Ameisen: only bitmasked larger sizes
01:48 PM Emil: Ameisen: C++ does not allow it either
01:49 PM Emil: it, too, has requirements on internal representation of data
01:49 PM Emil: aligned to byte
01:49 PM Ameisen: You can most certanly write a construct with array semantics that is tightly packed for uint20.
01:49 PM Emil: for basic types
01:49 PM Emil: Ameisen: and you can also write the C code that does it for you and wrap it in a macro
01:49 PM Emil: so while it's easier in C++
01:49 PM polprog: I dont see how cpp would sanely do that, you need more instructions if your 20 bit word is in 3 separate adresses with bit offset
01:49 PM Emil: it's entirely doable in C
01:49 PM Emil: polprog: it's just easier to write in C++
01:49 PM Emil: polprog: it's just actually more efficient
01:49 PM Emil: not
01:50 PM polprog: What
01:50 PM Emil: it's not actually more efficient
01:50 PM polprog: Yeah, i dont believe this
01:50 PM Ameisen: The macro version would be the same efficiency _at best_
01:50 PM Emil: Ameisen is just a C++ evangelist
01:50 PM nuxil: ^^
01:50 PM Ameisen: And you're just an idiot. So here we are.
01:50 PM polprog: You cant just jump around and have the values scattered around ram and be efficient
01:51 PM Ameisen: I don't recall mentioning efficiency anywhere
01:51 PM polprog: Jump in metaphorical meaning
01:51 PM Ameisen: I just said array semantics.
01:51 PM Ameisen: A uint24 will be faster if masked, but it will be larger.
01:52 PM Emil: Ameisen: aww, are you salty?
01:52 PM polprog: I would totally sacrifice (or leave for future) those 4 bits in the u24 array approach
01:52 PM Ameisen: Why would I be salty about your personal problems?
01:52 PM Emil: Ameisen: :DDDDDDDDDDDDDDDDDDDDDD
01:52 PM Ameisen: polprog - for 100 elements, that's 50 bytes
01:52 PM Emil: Ameisen: is your little C++ evangelist angry that we called you out on your evangelism?
01:53 PM Emil: Ameisen: do you need a hug?
01:53 PM Ameisen: jesus fucking christ you're annoying
01:53 PM polprog: Ameisen: and cant be done better, if you want fast! :)
01:53 PM Tom_L: you kids at it again?
01:53 PM Ameisen: polprog - what if your input is tightly packed U20s?
01:53 PM Ameisen: now you can't just memcpy it
01:53 PM Emil: Ameisen: I'm not the fucking retard who started Evangelising C++ and purposefully moving the goalpost and purposefully not thinking things from a logical standapoint
01:53 PM Emil: and
01:53 PM Emil: not
01:53 PM Emil: who started the personal attacks
01:53 PM Emil: retard
01:54 PM Emil: the
01:54 PM Emil: one
01:54 PM Emil: /rant
01:54 PM * Ameisen decides on the proper course of action to shut Emil up
01:54 PM polprog: If my input is a bunch of bits misaligned with bytes then i would just write a small snippet to unpack it
01:54 PM * nuxil goes to get some popcorn
01:54 PM Ameisen: polprog - so all you've done is move the cost
01:54 PM * Tom_L decides on the proper course of action to shut you all up
01:54 PM * polprog goes on to continue making supper, bbl
01:55 PM * Ameisen doesn't want to deal with this.
01:56 PM Tom_L: seemed effective
01:56 PM polprog: o_o
01:56 PM polprog: okay...
01:56 PM Emil: Anycase
01:56 PM polprog: EOF! EOF!
01:56 PM Emil: Any of you done any of the infosec crypto challenges on avrs?
01:56 PM Emil: I've been thinking about making a challenge like that
01:56 PM Tom_L: seems to run smoother when he's not yapping
01:58 PM Emil: https://www.youtube.com/watch?v=zk3JdMOQPc8
01:58 PM nuxil: Emil, the only crypto stuff i can make is rot13 :p
01:58 PM Emil: I think better keywords are AVR reverse engineering challenge
01:58 PM Emil: nuxil: :D
01:58 PM Emil: nuxil: if's funny, someone might actually miss it
01:59 PM nuxil: :D
01:59 PM nuxil: that would be epic
01:59 PM polprog: I always double my rot13. Makes it more secure
01:59 PM Emil: https://www.youtube.com/watch?v=u_U6F2Kkbb0&list=PLhixgUqwRTjwNaT40TqIIagv3b4_bfB7M
01:59 PM Emil: polprog: hahha :D
01:59 PM polprog: I wish i could implement something more than rot13
01:59 PM polprog: I dunno, simplest... Something
02:00 PM Emil: polprog: I actually wrote my SHA-256 implementation and HMAC implementation from the Wikipedia pseudocode
02:00 PM polprog: Whats HMAC?
02:00 PM Emil: polprog: the pseudocode on SHA2 is really easily understandable
02:00 PM Emil: Have you tried using a search engine yet?
02:00 PM polprog: I literally got the idea of avr encryption 10 secs ago?
02:00 PM Emil: Anycase it means hash mac
02:00 PM polprog: Okay. Ill read on later
02:01 PM polprog: Cya. Need to make supper
02:01 PM Emil: HMAC protects against basic length extension attacks
02:01 PM Emil: https://en.wikipedia.org/wiki/SHA-2#Pseudocode the code is short
02:10 PM MrFahrenheit: <Ameisen> Ok, write me something that gives me array-access semantics for an 'array' of 100 20-bit integers.
02:10 PM MrFahrenheit: what, like vector<bool>? what a great idea that was
02:11 PM MrFahrenheit: I wonder how many man hours were wasted on that decision over the decades
02:13 PM polprog: vector<bool> is when abstraction kicks in too hard
02:13 PM MrFahrenheit: leaky abstraction
02:14 PM MrFahrenheit: might have uti
02:18 PM MrFahrenheit: ugh, I wanna write some documentation, but I also totally don't want to do that
02:20 PM MrFahrenheit: btw, DES is a simple algorithm, and 3DES should be secure enough for a quick encryption
02:20 PM polprog: I should select a chassis for my mixer and start laying out the pcb
02:20 PM MrFahrenheit: I remember implementing DES one night before a test, and then none of the questions mentioned it
02:21 PM MrFahrenheit: I was pretty annoyed
02:22 PM dStruct: polprog: I ended up just doing bool[16] = { 0,1,0,1,etc }
02:23 PM polprog: it *will* work
02:24 PM polprog: meh, i was about to write something but its not that bad.
02:24 PM polprog: :D
02:24 PM polprog: 200 ok
02:24 PM MrFahrenheit: polprog, are you gonna use that mixer or just making it for lulz
02:24 PM polprog: MrFahrenheit: initially this was a stripboard project for learning but now that im making a PCB, i think ill just order 4, and make two. one for each desk
02:25 PM polprog: i mean pair of speakers
02:25 PM LeoNerd: PCBs don't usually come in singles... 3s from OSHpark, 5 or 10 from most other places
02:25 PM polprog: i cant wait to test this one and start working on a cooler one, with led vu meter
02:25 PM polprog: my pplace counts per square meter, i would always order 3 big ones or 6 smaller
02:25 PM MrFahrenheit: don't use leds, use an analog meter
02:26 PM MrFahrenheit: with leds
02:26 PM polprog: i order by email so we usually work out the best price
02:26 PM polprog: analog meter with leds?
02:26 PM polprog: eh?
02:26 PM MrFahrenheit: https://www.youtube.com/watch?v=WxiaxlZfIL8
02:27 PM MrFahrenheit: you can buy those indicators from china
02:27 PM polprog: i think i can get real ones easier here.
02:28 PM polprog: also. i would like to get a combo of a VU meter (solid) and a peak meter (dot) on the same scale
02:28 PM MrFahrenheit: are those imaginary?
02:28 PM polprog: behold some mixing porn https://www.youtube.com/watch?v=XEjLoHdbVeE
02:29 PM polprog: 0:28 dat spectrum analyzer. DAAAMn
02:29 PM polprog: i wish i had desk space for that!
02:30 PM nuxil: polprog, i belive thats a cover.. you really like abba is what youre saying :p
02:30 PM MrFahrenheit: https://www.banggood.com/2-p-1014725.html?
02:31 PM polprog: nuxil: cover of what?
02:31 PM polprog: which band? *
02:31 PM nuxil: cover for your saying you like the specrum analyzer :p
02:32 PM nuxil: abba music :p
02:32 PM polprog: dangit! me cover's blown!
02:32 PM nuxil: yea
02:33 PM nuxil: get these instead https://www.banggood.com/12v-Analog-Panel-VU-Meter-Audio-Level-Indicator-Meter-for-Amplifier-Speaker-p-1247923.html?rmmds=detail-left-hotproducts__3&cur_warehouse=CN
02:33 PM nuxil: 1/2 the prize :p
02:33 PM nuxil: + easy to openup and swap out scale for custom one
02:34 PM polprog: like "bullshit [kg/s]"
02:34 PM polprog: what i imagine this mixer and then meter would be sitting somewhere on this tower, with a silver aluminum enclosure with PCB front. most likely under the vga switch
02:34 PM nuxil: oh never mind. that prev link is for 2x
02:34 PM MrFahrenheit: but those don't look as nice
02:34 PM nuxil: so yours is cheaper
02:35 PM Emil: MrFahrenheit: don't use DES
02:35 PM Emil: anywhere
02:35 PM Emil: ever
02:35 PM polprog: https://puu.sh/A2sO5/3f63f69ad4.jpg
02:35 PM MrFahrenheit: Emil, I said 3DES, and why not
02:35 PM Emil: broken
02:35 PM MrFahrenheit: how
02:36 PM Emil: https://en.wikipedia.org/wiki/Triple_DES#Security
02:37 PM Emil: You can search the keyspace fully by consumer hardware in 2017
02:37 PM Emil: Sure
02:37 PM Emil: unlikely anyone will break your specific application
02:37 PM polprog: also. Blue leds are OUT!
02:37 PM MrFahrenheit: you can on des, pretty hard on 3des
02:38 PM Emil: MrFahrenheit: but since AES is also easy and lightweight
02:38 PM Emil: and secure
02:38 PM Emil: everyone should just use that
02:38 PM MrFahrenheit: aes is much more complex
02:38 PM Emil: Sure
02:38 PM Emil: but still simple
02:39 PM MrFahrenheit: if you want half your avr memory to be aes, not to mention the computation power
02:39 PM Emil: 3DES is very slow especially in software implementations because DES was designed for performance in hardware.
02:40 PM Emil: While AES is also fast as software implementation
02:40 PM polprog: i think it would be something like https://youtu.be/5P1fNMrfxMo?t=32s but with a rotary switch to select the integration time
02:40 PM polprog: and maybe a bit less leds
02:40 PM MrFahrenheit: just implement rsa+dsa and use 8k of avr memory to store a certificate store, nothing less than that is acceptable for your wireless temperature datalogger
02:41 PM polprog: at this pout just get a HW encryption module
02:41 PM Emil: MrFahrenheit: you are going out of scope and deliberately disregarding facts
02:41 PM MrFahrenheit: you just like to argue for the sake of arguing
02:41 PM Emil: wot
02:42 PM Emil: MrFahrenheit: mate you are doing exactly what Ameisen was doing just moments ago :D
02:42 PM Emil: MrFahrenheit: please stop
02:42 PM MrFahrenheit: sure
02:43 PM Emil: Hmm
02:43 PM Emil: is there some specific name for reacting quickly and immediately to values higher than current
02:43 PM Emil: but lowpassing for lower values
02:44 PM MrFahrenheit: polprog, are you gonna use a bargraph like that or just leds?
02:44 PM polprog: just leds. not that many
02:50 PM dStruct: am I correct in my understanding that a statement like PORTB |= _BV(PB1); would set just that port and not touch any other ports right?
02:51 PM MrFahrenheit: you mean bits?
02:51 PM Emil: dStruct: you can only manipulate one register at a time
02:52 PM Emil: dStruct: and the or operation can only set bits
02:52 PM Emil: dStruct: so when you do that code above, there's only 1 bit set in the expanded value, which means yes it would only set a single bit
02:52 PM dStruct: sorry poor wording, I'm talking Arduino, so when I said port I mean't pin
02:52 PM Emil: _BV(PB1) is probably defined something like (1<<PB1)
02:52 PM Emil: dStruct: don't talk arduino
02:53 PM MrFahrenheit: dStruct, yes, it will just set PB1
02:53 PM dStruct: PORTB is the B channel pins
02:53 PM dStruct: hmm, ok
02:53 PM twnqx: but usually not guaranteed side effect; it will still read the whole byte, set the bit (unless it's set already), and write it back
02:53 PM dStruct: my logic appears flawed :D
02:53 PM twnqx: side effect free*
02:53 PM Emil: dStruct: in "arduino" you only have pins, they are an abstract idea. In raw C you have pin banks (A bank, B bank, C bank ...)
02:53 PM Emil: dStruct: and you can only change a bank at a time
02:54 PM dStruct: Emil: agreed
02:54 PM dStruct: Emil: hence part of why I'm directly addressing the register
02:54 PM Emil: dStruct: and the various logic operators work exactly as described
02:55 PM Emil: | is the OR operator, & the AND operator
02:55 PM Emil: ^ the XOR operator
02:55 PM Emil: https://en.wikipedia.org/wiki/Truth_table
02:55 PM dStruct: Emil: yes I just needed to confirm that statement wasn't messing with any other pins on the port, or should I say bit values in the register
02:55 PM Emil: https://en.wikipedia.org/wiki/Logic_gate
02:56 PM Emil: dStruct: |= can only set bits, &= can only clear bits
02:56 PM Emil: ^= can only flipb its
02:56 PM dStruct: Emil: yes, I know that
02:57 PM dStruct: Emil: I was not referring to that logic, I was referring to some nesting inside an ISR that is not behaving as I planned it to
02:57 PM Emil: dStruct: raceconditions are an entirely different thing though
02:58 PM Emil: fortunately |= and &= aren't suspectible to it
02:58 PM Emil: ^= is
02:58 PM dStruct: which is why I'm toggling a flag and setting |= or &=
02:58 PM Emil: but happily PINx is writable in most atmegas and writing to it is atomic
02:58 PM Emil: and flips existing bits
03:00 PM dStruct: polprog: I gave it 2 bits of 1's and I got 3 instead :D
03:08 PM Emil: Hmm
03:08 PM Emil: setvbuf doesn't work on stdin?
03:11 PM LeoNerd: Why would it? It's about output buffering
03:12 PM Emil: LeoNerd: no, it also specifies input
03:19 PM dStruct: can PORTB be called more then once per ISR call?
03:21 PM Emil: dStruct: called?
03:21 PM Emil: dStruct: I sense some lacking knowledge
03:22 PM Emil: or rather understanding
03:22 PM dStruct: can I change the bits.........
03:22 PM Emil: dStruct: ISR is just a function that's invoked by hardware
03:22 PM dStruct: Emil: yes, I know.. it's not a function..
03:22 PM Emil: It _is_ a function
03:22 PM Emil: oh the register
03:23 PM dStruct: an ISR is yes, PORTB is not
03:23 PM Emil: yeah that's just a register
03:23 PM Emil: dStruct: you can write whatever and how many times you want to registers
03:23 PM dStruct: do I need to queue up Darude Sandstorm?
03:23 PM Emil: dStruct: yes
03:23 PM dStruct: lol
03:23 PM Emil: always sandstorm
03:23 PM dStruct: smh
03:23 PM dStruct: I'm getting some odd pulses in my output, like ghosting where there shouldn't be
03:24 PM Emil: dStruct: what are you trying to do?
03:24 PM Emil: and beware of the AB problem
03:24 PM Emil: Tell us what you actually want, not how you are imlementing it
03:26 PM dStruct: Emil: I'm taking in 16 bits of boolean (+/- 10vdc) and parsing it into a boolean array and also generating a 10khz squarewave clock signal (PB1) and then shifting the boolean out over PB2
03:27 PM Emil: ...
03:28 PM Emil: so you are doing spi
03:28 PM dStruct: Emil: I really just needed to know if I can make multiple changes to the PORTB register in a single interrupt
03:28 PM dStruct: Emil: kind of, but with my own constantly running clock on a precise frequency
03:28 PM Emil: that's spi
03:28 PM Emil: not kind of
03:28 PM Emil: exactly
03:29 PM Emil: 2018-04-13 23:21:54 +0300 < Emil> dStruct: you can write whatever and how many times you want to registers
03:29 PM Emil: dStruct: PORTB=1;PORTB=2;PORTB=3;PORTB=4;...
03:29 PM Emil: emil.fi/avr
03:29 PM Emil: And you can do whatever you want in an ISR
03:30 PM MrFahrenheit: dStruct, are you by any chance doing a delay in the interrupt handler?
03:30 PM dStruct: MrFahrenheit: haha no
03:32 PM dStruct: it could just be the damn 328p is loop so fast it's overlapping on my scope
03:32 PM dStruct: err looping
03:33 PM Emil: dStruct: why not use the SPI peripheral?
03:33 PM Emil: dStruct: why bitbang?
03:33 PM Emil: dStruct: your bitbang is inherently jitterly
03:34 PM dStruct: Emil: well I need to generate a very precise clock signal, and then time 2 other signals off of it, and I need control over phase per output so when clock is high, data goes high and stays high for a period of 1 high/low etc
03:35 PM Emil: spi
03:35 PM Emil: it's called spi
03:35 PM dStruct: Emil: the actual signal from bitbanging actually looks really good, and the ghosting I'm seeing may just be because it's zero'ing the cycle every 32 frames, which is why I was asking if I was able to set the PORTB register more then once per Int
03:36 PM Emil: dStruct: anycase, you now understand that you can write whatever you want how many times you want to the registers
03:36 PM Emil: and you can do so inside in interrupt
03:36 PM dStruct: Emil: I'm already doing it in an int
03:38 PM dStruct: Emil: but if you think SPI could do it exactly the same, I may have to do some AB testing on that
03:38 PM Emil: AB-testing is not the correct word
03:39 PM Emil: but eh
03:39 PM Emil: :D
03:39 PM dStruct: it's functionally very similar to how you would address a shift register, with a latch, except the latch in this case would be a sync line that kinda works more like a stop bit in serial
03:40 PM dStruct: Emil: http://leonardodaga.insyde.it/Corsi/AD/Documenti/ARINCTutorial.pdf pdf page 22 (paper page 20)
03:44 PM Emil: dStruct: ah
03:45 PM Emil: https://emil.fi/m/2018-04-13_23-43-39_DptqoDVt.png
03:45 PM Emil: you trying to do that?
03:45 PM dStruct: Emil: no pdf page 22, paper page 20
03:46 PM Emil: https://emil.fi/m/2018-04-13_23-44-57_ubTSRXmO.png
03:46 PM Emil: this one?
03:46 PM Emil: (on pdf page 26)
03:46 PM dStruct: yup that's page 22
03:46 PM dStruct: oh
03:46 PM dStruct: I hate how pdf page numbers never seem to match up
03:46 PM Emil: wot
03:47 PM Emil: it's different for you? :D
03:47 PM dStruct: page 22 for me
03:47 PM Emil: It's definitely page 26
03:47 PM Emil: I counted the pages
03:47 PM Emil: :D
03:48 PM Emil: okay so
03:48 PM Emil: that word sync is hard on the spi peripheral
03:49 PM Emil: but that data is just spi
03:49 PM dStruct: agreed
03:51 PM dStruct: when I looked at SPI I deemed it not ideal, do to what appears to be a lack of exact clock rate control, only multipliers of the base clock, and the sync line would be tricky
03:51 PM dStruct: err *due
03:51 PM Emil: the specific spi mode is CPOL 0 and CPHA 1
03:52 PM Emil: so SPI 1
03:52 PM dStruct: Emil: yeah I'll have to look at it again at some point
03:53 PM Emil: dStruct: plain spi is _super_simple_
03:53 PM Emil: on avr
03:53 PM Emil: You only have two registers: SPCR and SPDR for control and data registers
03:54 PM Emil: dStruct: what's your uc?
03:54 PM dStruct: Emil: what's a uc?
03:54 PM Emil: microcontroller
03:54 PM dStruct: 328p
03:54 PM dStruct: 16mhz
03:55 PM dStruct: pulling in 10v inputs and level shifting 5v logic up to 12v
03:56 PM nuxil: working with spi?
03:56 PM Emil: Oh there was also SPSR
03:56 PM dStruct: nuxil: well Emil is apparently lol
03:57 PM dStruct: nuxil: I'm apparently a sadist for bitbanging my own thing from scratch
03:57 PM nuxil: dont know what you guys talking about
03:57 PM Emil: dStruct: anycase that diagram is super easy to do
03:57 PM nuxil: i just reconnected
03:57 PM Emil: bitbanging
03:57 PM nuxil: oki
03:59 PM nuxil: bitbaning spi or in general :p
04:00 PM dStruct: nuxil: D) All of the of the above lol
04:01 PM nuxil: hehe
04:02 PM nuxil: why bitbang spi when you can use the hw.
04:02 PM nuxil: the built in spi stuff
04:03 PM Emil: :D
04:03 PM Emil: he should but there's an annoying word sync he apparently has to do
04:03 PM dStruct: if it works for my use I may rewrite what I have
04:04 PM dStruct: the clock must be dead on 10989hz
04:04 PM nuxil: you make it interrupt driven :p
04:04 PM Emil: https://emil.fi/m/2018-04-14_00-02-57_XvEVmz4e.png
04:04 PM Emil: dStruct: why does it need to be _dead_on
04:04 PM Emil: it's spi
04:04 PM Emil: (there's clock)
04:04 PM dStruct: currently all my code is interrupt driven, and my main is free to do stuff
04:04 PM Emil: it doesn't matter if it's off by a hertz or so :D
04:05 PM Emil: not to mention that if you really need that exact timing, you need a pretty accurate crystal for it
04:06 PM Emil: if you need accurate timing then you need a txco
04:06 PM Emil: tcxo*
04:06 PM Emil: or even ocxo
04:07 PM Emil: https://en.wikipedia.org/wiki/Crystal_oven#Comparison_with_other_frequency_standards
04:07 PM Emil: dStruct: so don't lie to us that you need "super duper exact timing"
04:07 PM Emil: unless you absolutely need
04:08 PM dStruct: Emil: dead on meaning as close to 10989hz as I can get with the built in xtal
04:08 PM Emil: lol
04:09 PM Emil: mate
04:09 PM nuxil: the internal RC is shait
04:09 PM dStruct: Emil: which it outputs a nice stable 10.99khz with no measurable drift at least in a range that would affect this circuit
04:09 PM Emil: a ) the internal oscillator is rc
04:09 PM Emil: trololo
04:09 PM Emil: dStruct: please
04:09 PM Emil: b) you are overspeccing
04:09 PM Emil: spi is used for a reason
04:09 PM Emil: having a clocksignal frees you from having exact timing
04:10 PM Emil: c) the internal rc is +-5% at worst, +-3% from factory and +-1% when tuned iirc :D
04:10 PM Emil: and it_will_change by temperature
04:10 PM nuxil: dStruct, working in ms with the internal RC is fine. but when you get down in low us its not reliable at all.
04:11 PM nuxil: when i was building my signal gen "dds" i started off using the internal RC. i found quicly out i had to order some crystals. it was all over the place :p
04:12 PM dStruct: nuxil: well I haven't had any issues yet at 10.989khz
04:12 PM Emil: nuxil: he probably uses xtal
04:12 PM Emil: even though he says it's "internal"
04:12 PM nuxil: ahh
04:12 PM nuxil: confusing
04:13 PM Emil: dStruct: the cheapest (if you got it from china it's the chepest) XOs from Mouser are 50ppm stability and 50ppm tolerance
04:13 PM Emil: Probably even worse
04:13 PM Emil: and that's when temperature does not change
04:15 PM Emil: so your single herz accuracy is directly out of the window
04:15 PM Emil: as is your 10 hz accuracy
04:15 PM Emil: and at 100hz it's pretty crap still
04:15 PM dStruct: http://www.gravitech.us/arna30wiatp.html is what I have
04:15 PM Emil: yeah that's china
04:16 PM Emil: well could be "reputable"
04:16 PM Emil: but still the results above stand
04:16 PM Emil: also why pay so fucking much :D you can get the same thing from china for 2usd
04:17 PM Emil: That's like 10 times as expensive
04:17 PM Emil: dStruct: what's the 10k clock used for?
04:17 PM Emil: Is it just for the communication channel?
04:18 PM dStruct: well I didn't buy it from there, but that's the same schematic, and with FTDI, not the crap chinese uart chip
04:19 PM dStruct: it's going to replace the analog drive circuits that currently drive the DME indicators on a 6dof full hydraulic motion flight simulator
04:20 PM Emil: allmylols
04:21 PM Emil: you don't need that accuracy for that
04:21 PM Emil: god damn it kid
04:22 PM nuxil: FTDI can go suck some balls.
04:22 PM nuxil: after what thet did with peoples equipment
04:23 PM Emil: agreed
04:23 PM Emil: though they still produce better quality than some
04:23 PM nuxil: sadly
04:23 PM dStruct: Emil: I never claimed I needed anymore accuracy then I was already getting
04:24 PM Emil: dStruct: pls
04:26 PM Emil: https://www.youtube.com/watch?v=_fHfgU8oMSo
04:26 PM Emil: btw did you see this?
04:26 PM Emil: its from a couple of weeks back
04:28 PM Emil: https://www.youtube.com/watch?v=hWLjYJ4BzvI
04:29 PM dStruct: Emil: the question is did you see this? https://youtu.be/V-_O7nl0Ii0
04:31 PM Emil: There is no war in ba sing se
04:40 PM nuxil: dStruct, god damn.. i like old pop, rock and metal. but some place i there is a line :p
04:41 PM polprog: Goodnight
04:41 PM nuxil: good night
04:41 PM nuxil: The last few days i been listening to metal cover of songs by Frog Leap Studios :)
04:41 PM nuxil: currently listening to https://www.youtube.com/watch?v=gXK4rkwFIwM :)
04:42 PM Emil: polprog: good night
04:42 PM polprog: nuxil: this is nice https://youtu.be/vVXIK1xCRpY
04:44 PM nuxil: oh, long time since i listen ti them
04:45 PM polprog: Oh and this. You definitely dont know this
04:45 PM polprog: https://youtu.be/S7lOF2vuUTM
04:45 PM polprog: Theres a nice guitar in the middle
04:45 PM polprog: Niters ;)
04:46 PM polprog: Tomorrow im routing my mixer !
04:46 PM nuxil: no. i dont know polish music
04:46 PM polprog: Track title - "First Snow"
11:32 PM day__ is now known as day