Back
[00:05:46] <yu74> hi, i thing my atmega32 is out after setting an incorrect lfuse or hfuse values for external crystal 8Mhz. There is a way to reset fuses?. I use a pickit2 (ICSP) clone with avrdude. tnx
[00:11:50] <Jartza> sure there is a way to reset them, but you need to connect the external crystal to be able to program it
[00:12:03] <Jartza> or at least something that generates external clock for it
[00:13:08] <Casper> what I did last time I had to do that is: take another avr, and make an "insane led blinker"
[00:13:15] <Casper> and use that as the clock source
[00:15:01] <Jartza> yeah
[00:15:06] <Jartza> that works too
[00:16:00] <Jartza> most often it seems it's possible to at least reprogram avr fuses even if it's set for external crystal just by connecting a clock to xtal1
[00:16:39] <LoRez> Tom_itx has a usb programmer that can provide an external clock if necessary. dunno if he's still selling them.
[00:18:30] <yu74> ok
[00:30:05] <yu74> is alive, put a function generator at 10khz on xtal1. :)
[00:30:28] <yu74> but avrdude show initialization failed, rc=-2
[00:31:24] <Jartza> yu74: you need to slow down programming speed then. something like 1/4th of the cpu clock max.
[00:31:36] <Jartza> so with 10khz system clock you can program it with 2.5khz clock :)
[00:32:32] <Casper> yu74: if you can put a faster clock speed, use a faster one
[00:39:23] <yu74> ok
[01:00:46] <yu74> ohh so cool
[01:01:00] <yu74> can write at 1M
[01:01:10] <yu74> thanks
[01:01:57] <_ami_> yu74: 1M HZ is for using internal oscillator?
[01:02:19] <yu74> _ami_, from function generator
[01:02:28] <yu74> on xtal1
[01:03:14] <yu74> now avrdude respond
[01:07:48] <Casper> 1MHz is default clock speed on many avr
[01:12:06] <_ami_> yeah, 1 MHz is the default one
[01:53:03] <_ami_> i have a question on flashing fuses. I got usbasp programmer.
[01:53:41] <_ami_> Is it absolutely necessary to flash fuses at 16Mhz with 16Mhz external oscillator connected?
[01:56:22] <Casper> no
[01:56:43] <_ami_> ok
[01:56:44] <Casper> in fact, if you use a programmer clock of 16MHz with 16MHz io clock, then it will fail
[01:56:58] <Casper> max: 1/4 io clock for the programmer clock
[01:57:05] <Casper> and the io clock can be about anything
[01:57:17] <Casper> I beleive even a watch crystal work
[01:57:53] <_ami_> ah, good to know that.
[01:57:54] <cehteh> "fully static operation" ... means you can add a 0.1Hz clocksource when you have enough patience
[01:58:10] <cehteh> or a flip switch and trigger the clock manually
[01:58:19] <cehteh> (dont forget to debounce :D)
[01:59:05] <Casper> hey why not simply use a magnet on an hand crank?
[01:59:15] <cehteh> the point is only that the fuses need to be configured correctly for the clocksource you are using
[01:59:16] <Casper> flip the bit, do one turn
[01:59:28] <cehteh> yes that will work
[01:59:49] <Casper> do you imagine the work it would be, just to enter the programming mode....
[02:00:14] <cehteh> i was thinking about a hand cranked punch tape programmer
[02:01:00] <Casper> imagine now.... going back in time... with that...
[02:01:08] <cehteh> the problem is not the programmer but a machine which punches the tape :D
[02:01:12] <Casper> and emulating one of their super computer with a simple chip...
[02:01:49] <Casper> somehow, it reminded me of a video...
[02:02:19] <Casper> https://www.youtube.com/watch?v=fnb7EqfykF4 <=== that one
[02:03:44] <cehteh> in a town closeby there is a museum for historical mechanical instruments
[02:04:44] <cehteh> https://www.youtube.com/watch?v=8HaDvwiQ--I
[02:04:46] <Casper> that guy made a cutter
[02:05:12] <cehteh> https://www.youtube.com/watch?v=AyBI9SLZ0b0
[02:05:45] <cehteh> yes punching/cutting getting complicated
[02:06:54] <Casper> man that second video annoy the heck out of me due to the cymbal that is out of sync
[02:07:01] <cehteh> https://www.youtube.com/watch?v=IvUU8joBb1Q well that was a few weeks ago in the news, they have a lot 'making of' videos too
[02:16:38] <Casper> bed time, nite
[02:16:45] <Casper> (almost 3am...)
[02:57:11] <WormFood> I fuckin' hate soldering perf board. I just got my project finished, and in a case.
[03:12:56] <cehteh> remember when i saied i wanted some pre-tinned breadboard like thing (as thin as pcb, but with tinned springs
[03:13:13] <cehteh> stick together test it .. when it works, fix it with heat gun
[03:13:17] <WormFood> no. I don't remember that....but ok
[03:13:27] <cehteh> i shall invent that :)
[03:13:47] <WormFood> How do they connect together?
[03:14:20] <cehteh> prolly stripe board like breadboard
[03:14:31] <WormFood> You want solder springs, that when you heat up, they turn from springs into soldered connections?
[03:14:41] <cehteh> yes
[03:14:57] <cehteh> well the springs should be cheap and premade there
[03:15:06] <WormFood> Good luck with that...let me know when you invent lead that will return to it's original position.
[03:15:28] <cehteh> why orginial position?
[03:15:37] <WormFood> let me know, when you perfect the spring, made out of lead and tin, that will compress, and return
[03:15:51] <WormFood> That is the nature of a spring.
[03:15:58] <cehteh> nah tinned springs, not springs out of tin
[03:16:02] <WormFood> it bends, and returns to it's original shape.
[03:16:23] <WormFood> And, how would a heat gun help all of this?
[03:17:04] <cehteh> you can use the pcb like a normal bread board (well fewer times, the springs are not intended for many insertion cycles)
[03:17:34] <WormFood> You're inserting the springs into what?
[03:17:48] <cehteh> and when you are satisfied with the design you can permanently fix it, and use it in production (for things where you need very low quantities)
[03:18:08] <cehteh> like once only circruits
[03:18:12] <WormFood> PCBs are cheap to make.
[03:18:25] <cehteh> single ones not so
[03:18:43] <WormFood> Yeah they are
[03:18:49] <cehteh> ok over there
[03:18:57] <WormFood> You don't get 'em quickly, but you can get one off boards cheap. Even where you are.
[03:19:04] <cehteh> but not here and ordering from china makes the shipping along more expensive
[03:20:18] <WormFood> I never suggested ordering straight from China. And, shipping is cheap, unless you live in one of those corrupt shithole countries.
[03:20:21] <cehteh> also i expect thats simpler to produce because you dont have the hasszle to put smd parts to solder every single through hole wire, this thing will hold the parts in place already
[03:20:32] <cehteh> yes i live in germany :)
[03:20:57] <WormFood> I'm talking with an American friend in Germany, right now (in another channel (not IRC))
[03:21:15] <cehteh> haha
[03:21:24] <WormFood> And even so, in Germany, it shouldn't be expensive to ship there, from China.
[03:21:41] <cehteh> i order a lot stuff from china. some even ship for free
[03:21:49] <WormFood> You can probably find a company there (EU), that can do small order PCBs
[03:21:54] <cehteh> but i need to wait 4-6 week for the stuff then
[03:22:07] <cehteh> and sometimes the customs hold things back for ransom
[03:22:09] <WormFood> Right. That is the only downside.
[03:22:19] <WormFood> I had that happen to my passport. Totally fucked me.
[03:22:23] <cehteh> small order pcb in EU are reasonable expensive
[03:22:35] <WormFood> Literally cost me thousands of dollars, because of their delay.
[03:22:56] <cehteh> i mean i am talking about less than $5 .. preferably much less
[03:23:53] <WormFood> I need to go around, and talk with some of the local places doing PCBs here. I see them all the time, that list "prototype" (which means extremely low quanity. Like 1-10)
[03:24:29] <WormFood> I expect I can get 'em made fairly cheaply.
[03:24:53] <cehteh> anyway .. for quantities like 1-2 there is still the work involved to design the pcb and then populate the board
[03:24:54] <WormFood> I picked up my ATmega88-20 PDIP for under $1
[03:25:02] <Valen> if you are after PCB's in a reasonable timeframe and for cheap try hackvana?
[03:25:02] <cehteh> thats the main thing i want to save
[03:25:32] <WormFood> Valen, is that a question, or a suggestion?
[03:25:40] <Valen> bit of both i guess
[03:25:50] <WormFood> You ever dealt with them before?
[03:25:54] <Valen> I've used him in the past, was cheap and with express pretty fast
[03:25:55] <cehteh> make prototype .. when it works, then just make it permantent by soldering
[03:26:06] <Valen> shipped to australia in like a week?
[03:26:32] <WormFood> I don't know. I imagine from China to OZ it'd be fairly quick.
[03:27:10] <Valen> had a batch of 100 boards with tented (or untented) vias that was wrong, he sent the new ones in a few days
[03:27:25] <Valen> its all just post so its however long that is
[03:27:33] <Valen> unless you pay extra for DHL or something
[03:27:36] <Valen> gets a bit less cheap then
[03:28:04] <Valen> (I think like $30 for shipping instead of $15 for express and $notvery much for standard)
[03:28:24] <WormFood> That's $AUD?
[03:28:55] <Valen> yeah
[03:29:08] <Valen> he's an australian who middlemans the chinese fabs
[03:29:16] <WormFood> I've met him before.
[03:29:20] <WormFood> in person.
[03:29:27] <WormFood> I live in China
[03:29:28] <Valen> well he does good stuff ;->
[03:29:47] <Valen> oh sorry I thought you were the one in china ;->
[03:29:55] <Valen> bah germany
[03:30:22] <WormFood> that's cehteh in Germany
[03:30:33] <WormFood> 我在中国
[04:38:10] <liwakura> uhm. if i can code stuff on atmel's and solder the things around them
[04:38:27] <liwakura> and i would do that as job
[04:38:32] <liwakura> how is that called?
[04:38:39] <WormFood> [23:43:18] <liwakura> WormFood: remember that baud rate detector i had in mind the other time? [23:43:24] <liwakura> just finished the PoC [23:43:25] <liwakura>
https://raw.githubusercontent.com/liwakura/avr-baud-detect/master/detect.c <-- what happens if the 1st byte is 0xFF or 0x00?
[04:39:08] <cehteh> my saying
[04:39:11] <liwakura> if 0xFF, you get the right baudrate from the startbit
[04:39:23] <WormFood> and, for 0x00?
[04:39:35] <liwakura> then you get a shitty sample
[04:39:46] <cehteh> FF and 00 are not thatr problematic, start/stop bit transitions will do
[04:39:56] <cehteh> but some other patters are problematic
[04:39:57] <WormFood> what cehteh?
[04:40:14] <WormFood> How do you identify the start and stop bits, when you don't know the bit rate?
[04:40:39] <liwakura> i don't
[04:40:41] <cehteh> you dont need you only need the bit transition
[04:40:54] <cehteh> but that was my saying .. for some data it wont work :D
[04:41:16] <cehteh> he mearures the shortest time between signal changes
[04:41:24] <liwakura> cehteh: i made a list of ascii characters that allow proper detection
[04:41:24] <liwakura> !#%'()*+,-./1345679:;=?ACEGIJKMOPQRSTUVWXYZ[\]^_aceghijklmnoqstuvwyz{}
[04:41:39] <WormFood> ok, how do you detect the speed between 0x80, 0xC0, and 0xE0?
[04:41:42] <liwakura> you need one of them in your test data and you got it
[04:42:11] <cehteh> FF is 1111111110,1111111110 first is the start bit, least is the stop bit
[04:42:22] <WormFood> You know what I mean.
[04:42:24] <liwakura> also, default is 1 on the line
[04:42:33] <WormFood> That's the start bit
[04:42:34] <cehteh> oposite then
[04:42:51] <cehteh> but still, he has a single bit transition
[04:42:53] <liwakura> WormFood: i know what you mean
[04:42:55] <cehteh> there it works
[04:42:59] <WormFood> but if the 1st bit of data is 1, then it will look like a long start bit.
[04:43:11] <cehteh> for other patterns where there is no single bit transition it wont
[04:43:22] <liwakura> some bytes will give a multiple of UBRR, but thats why i collect mutiple samples and only take the lowest
[04:43:24] <cehteh> WormFood: i agree with you :)
[04:43:27] <WormFood> That is why I said, you have to sample a bit, and figure out the start and stop bits, and then ever other bit will line up. If you can do that, then you can reliably autodetect everything
[04:43:56] <liwakura> uhm
[04:43:57] <WormFood> Then you can flyback home
[04:44:07] <liwakura> i don't get why the start and stopbits are important
[04:44:23] <liwakura> i just look for the shortest observed 0 - period
[04:44:28] <cehteh> i'd just keep the UART running and watch for frame errors and use some algorithm/heuristic to detect baudrate
[04:44:30] <WormFood> the start and stop bits are the ONLY thing you can count on.
[04:44:38] <WormFood> cehteh, then you lose data
[04:44:47] <cehteh> of course
[04:44:55] <cehteh> you loos data until you are synced
[04:45:10] <cehteh> which makes the whole thing a bit pointless
[04:45:23] <cehteh> unless your software on both ends support this autodetection
[04:45:39] <cehteh> but if it does, then supporting the correct baudrates from a start would be easier :D
[04:46:33] <cehteh> liwakura tries the best he can do, but how much thats worth is a bit doubtful. in some cases it might be usabled
[04:46:41] <liwakura> uhm
[04:46:43] <liwakura> i did some math
[04:46:57] <liwakura> 219 bytes of the 256 possible will yield the correct value
[04:47:13] <cehteh> yes
[04:47:39] <cehteh> if your data is randomly uniform you have a good chance
[04:47:50] <cehteh> but in a lot cases it wikk not work
[04:48:08] <liwakura> if you sample 16 bytes, the chances that you get the wrong value is (37/256)^16
[04:48:11] <liwakura> thats close to 0..
[04:48:16] <WormFood> well, you can't reliably use the usart, unless you know you're using standard bit rates, and you have a "compatible" clock source for your avr
[04:48:18] <cehteh> hey .. and i had already problem just turning uart on and get a sync :D
[04:48:28] <cehteh> with boudrate known
[04:48:58] <liwakura> WormFood: absolute bit rates don't matter
[04:49:04] <cehteh> if the line is busy then its not easy to sync to serial already when you turn the uart on in the middle of a transmision
[04:49:09] <liwakura> it just gets the UBRR that would work for the received frames
[04:49:25] <liwakura> in my case, i got weird values because im quartz is shit
[04:49:42] <liwakura> but those weird values and the quartz cancel themselves out perfectly
[04:50:04] <liwakura> thats sorta the intention behind the detection
[04:50:56] <WormFood> Autobaud is nothing new. We had that back in the 80s
[04:51:01] <cehteh> doesnt it work with standard calculated values?
[04:51:15] <cehteh> yes it works in many cases
[04:51:35] <cehteh> i am only complaining that it wont work in *all* cases .. and that you loose some data
[04:51:55] <liwakura> oh, i see that in a relative way
[04:52:07] <liwakura> loosing some data is better than receiving only garbled stuff
[04:52:18] <cehteh> unless you sample date, store it away and later when you figured out the baudrate you reconstruct it .. gl;hf
[04:52:46] <cehteh> not necessary better .. if you receive garbled stuff then let the user fix the baudrates
[04:53:08] <cehteh> i'd rather add some protocol level safety there than trusting the bytes i receive/send
[04:53:08] <WormFood> you can reliable autodetect all serial streams, of any speed...with a fast enough AVR...but, you'd be doing it all in software, and not using the usart at all.
[04:53:41] <liwakura> WormFood: how can you reliable detect the baudrate of an continuous stream?
[04:53:55] <liwakura> i mean, how do you know where frames start and end?
[04:54:19] <cehteh> thats hard, but not impossible
[04:54:21] <liwakura> if you just get an stream of cap U
[04:54:28] <liwakura> you just get a rectangle function
[04:54:33] <cehteh> the start/stop bit transition is given
[04:54:39] <WormFood> well, coming in the middle of a stream, is not doable. But hell, nothings is continuous anyways :P
[04:55:13] <liwakura> so its not reliable?
[04:55:24] <cehteh> not for all patterns
[04:55:28] <cehteh> thats the problem with serial
[04:55:34] <liwakura> thats exactly the same issue with my thingie
[04:56:15] <cehteh> for now, i listen to USART for a \n .. only then it really goes live
[04:56:24] <cehteh> (aka filling the buffers)
[04:57:02] <cehteh> later i'll add a detection that when the transmission line is idle it goes live directly
[04:57:14] <cehteh> (typing return to start it sux :D)
[04:57:33] <liwakura> i had something similar in mind
[04:57:46] <liwakura> especially listening to the DTR line and do an autodetection of the protocol
[04:57:50] <cehteh> but usually i use line based text protocols, waiting for a \n is a safe bet that i start at a complete line
[04:57:55] <liwakura> each time a new session is started by the PC OS
[04:58:28] <liwakura> cehteh: what do you use as tty emulator for this?
[04:58:38] <liwakura> gnu screen always sends \r
[04:58:42] <WormFood> https://en.wikipedia.org/wiki/Asynchronous_serial_communication <-- familiarize yourself with that diagram.
[04:58:46] <cehteh> and btw .. "echo" data back is also the simplest form of human validable ACK
[04:59:15] <cehteh> liwakura: maybe i use \r ... forgotten if it was \n or \r .. its configureable anyeay
[04:59:24] <liwakura> WormFood: thats where i know from that uart is 1 per default
[04:59:54] <liwakura> i just need 1 correct sample and the detection is successful.
[05:00:09] <liwakura> how likely is it to have 1 correct sample out of 256 ?
[05:00:24] <WormFood> If they were using parity, that might be slightly easier to reliably detect.
[05:00:32] <cehteh> as saied it works most of the time, but its really a hard problem to make this robust and working und *all* circumstances
[05:01:09] <cehteh> liwakura: i am more interested in configuring the baudrates, but in case there is some drift, recalibrate them a bit
[05:01:36] <liwakura> WormFood: i can do that calculation, too.
[05:01:43] <cehteh> which should be easy to do with the 'frame error' bit
[05:01:44] <liwakura> but i guess more bits -> more samples
[05:02:31] <liwakura> and parity should increase the risk that an frame contains a correct sample
[05:02:59] <liwakura> i don't see your argument here.
[05:03:04] <cehteh> default is w/o parity :D
[05:03:29] <cehteh> also .. parity tells you that the byte is damaged
[05:03:49] <cehteh> but you need software support to initiate a retransmission or whatever to fix/handle that
[05:04:01] <liwakura> yeah
[05:04:10] <WormFood> cehteh, there is no "default"
[05:04:29] <cehteh> 8n1 is pretty much standard
[05:04:33] <liwakura> agree
[05:04:37] <WormFood> What if you were using 9 bit bytes? How would your autodetect fare there?
[05:04:43] <cehteh> yes
[05:04:48] <WormFood> It's a de facto standard
[05:04:52] <liwakura> WormFood that would actually not even matter
[05:05:55] <liwakura> since im just checking for low bits, independent of their context or position
[05:06:07] <WormFood> I saw your code
[05:06:11] <WormFood> I saw how you're doing it.
[05:06:13] <cehteh> liwakura: so for some robust protocol i'll add checksums per 'message' .. thats far better than relying on parity
[05:06:22] <liwakura> cehteh: tcp over serial? :D
[05:06:26] <WormFood> That is why I say it's flawed. I mean, it would work for some things.
[05:06:30] <WormFood> that's called "SLIP"
[05:06:52] <cehteh> tcp is a stream protocol not message based
[05:06:55] <WormFood> and, tcp needs ip
[05:06:57] <cehteh> so forget that :D
[05:07:13] <cehteh> but a lot protocols uses checksums
[05:07:18] <cehteh> onewire :D
[05:07:23] <liwakura> WormFood: take 256 samples on a ascii stream and thats more reliable than every uptime in the world
[05:07:36] <WormFood> Do you know why FTP uses 2 ports? One for data, and one for commands? Because it actually predates the TCP/IP protocol.
[05:07:44] <liwakura> uhm
[05:08:09] <WormFood> They used even ports and odd ports for receiving and transmitting.
[05:08:20] <WormFood> So, connect on one, send commands, the other is for data.
[05:08:23] <liwakura> WormFood: im pretty sure you can implement tcp over any thing that supports datagrams
[05:08:47] <cehteh> FTP he saied :D
[05:08:58] <liwakura> > (09:41:08) WormFood: and, tcp needs ip
[05:09:03] <cehteh> which is awful .. anyone still uses ftp??
[05:09:11] <cehteh> ah
[05:09:31] <cehteh> iirc tcp needs ip and ip needs datagrams
[05:09:45] <WormFood> I used to run a rsync Linux warez server...that was over 15 years ago...and I refused to use ftp
[05:10:13] <liwakura> ip is more or less just an addressing and routing layer for datagrams
[05:10:14] <cehteh> Linux warez? :D
[05:10:20] <liwakura> tcp is the stream layer
[05:10:43] <liwakura> if you use the serial as datagram link, tcp should work on it
[05:11:38] <cehteh> tcp is horribly expensive to implement
[05:11:51] <liwakura> the buffers :(
[05:12:12] <liwakura> would eat the atmel ram quite fast
[05:12:30] <cehteh> i stay with human readable text protocols
[05:12:35] <liwakura> agree
[05:12:40] <liwakura> because easier to debug
[05:12:49] <cehteh> maybe message\nchecksum\n
[05:13:01] <liwakura> or just omit the checksum xD
[05:13:18] <cehteh> well plan later is to have checkpoints and checksums
[05:13:24] <cehteh> and commands to query them
[05:13:37] <cehteh> and transactions (begin/commit) ...
[05:13:57] <cehteh> so you can use human like cli .. or robust text communiucation with a computer
[05:14:33] <liwakura> uhm
[05:14:34] <cehteh> in human mode it will echo back the data
[05:14:37] <liwakura> ah okay
[05:14:43] <liwakura> just wanted to ask that
[05:14:58] <cehteh> in computer mode one can query a checksum
[05:15:18] <liwakura> i tried to implement some termios ioctl for that echo mode switch, but in the end i felt it was just too bloated
[05:15:28] <cehteh> maybe implicit \n sends a checlsum and you have to commit\n again to finalize it
[05:16:06] <cehteh> that can be made quite generic
[05:16:13] <liwakura> dunno. is that even necessary?
[05:16:27] <cehteh> if you need some reliabiltiy/robustnes .. yes
[05:17:09] <liwakura> i don't remember seeing garbled serial data ever, except directly after switching baudrates
[05:17:19] <cehteh> when a control program on the PC pushes some settings and command to the µC you want to be pretty sure it is received there correctly
[05:17:47] <liwakura> hm. maybe i would implement some binary protocl then
[05:17:52] <cehteh> happens rarely, but with long cables or electronic noise .. or drifting clocks it can and will happen
[05:17:52] <liwakura> with checksums and retransmission
[05:18:17] <liwakura> never had serial links > 20cm
[05:18:19] <cehteh> switching to binary would be another option, but these contradict each other
[05:18:52] <cehteh> dont contradict
[05:18:56] <liwakura> include an \n as binary packet that triggers an protocol switch
[05:19:07] <liwakura> like, it starts with binary
[05:19:19] <liwakura> and if you type \n, it goes into human readable mode
[05:19:26] <cehteh> binary will likely the package length as header
[05:19:28] <liwakura> or just opens the shell or whatever
[05:19:40] <cehteh> and maybe end with \0 or \n
[05:20:26] <liwakura> i would do some sort of <1 byte packet type> <1 byte checksum> <1 byte length> <length byte data>
[05:20:38] <cehteh> way too much :D
[05:20:55] <cehteh> i byte length, data, \n .... done
[05:20:59] <cehteh> 1
[05:21:10] <liwakura> hm
[05:21:14] <liwakura> depends on your application
[05:21:25] <liwakura> didn't you say you wanted checksums?
[05:21:29] <cehteh> how data is interpreted (packet type etc) is another layer
[05:21:32] <cehteh> checksum too
[05:21:37] <cehteh> yes
[05:21:37] <liwakura> hm
[05:22:11] <cehteh> but first the *bare* transmission layer, then the safety layer, then the protocol layer
[05:22:38] <cehteh> not all at once
[05:22:54] <twnqx> checksum all the layers
[05:23:09] <cehteh> yes
[05:23:17] <cehteh> but that can be explcit
[05:24:40] <WormFood> Like a 7 layer taco
[05:25:13] <cehteh> not necessary 7 layer .. but yes,
[07:36:27] <GeneralStupid> Hi
[07:36:44] <GeneralStupid> i asked for protocol serialization yesterday
[07:36:57] <GeneralStupid> http://koti.kapsi.fi/~jpa/nanopb/docs/ did anyone try this small protobuf implementation?
[07:38:09] <LeoNerd> *headdesk*
[07:38:09] <LeoNerd> You clearly weren't particularly listening then
[07:39:01] <GeneralStupid> LeoNerd: because i dont want to parse text?
[07:39:06] <GeneralStupid> with strtok ?! :D
[07:39:09] <LeoNerd> Nit..
[07:39:12] <LeoNerd> God fucking damnit
[07:39:15] <LeoNerd> You are not understanding this
[07:39:40] <LeoNerd> You are looking for a "serialisation" as if that's some huge fancy shiney black box that no mere human could possibly understand so you want to "buy" a prepackaged solution in the form of protobuf
[07:40:04] <LeoNerd> Protobuf is a large thing built for 1000+-person projects to store data at rest and on the wire over several years if not decades
[07:40:25] <LeoNerd> It is *totally* overboard for one MCU talking to one Linux box over the course of miliseconds with both ends built by one person
[07:40:37] <LeoNerd> You want to send commands. OK, so number the commands. The first one you think of is 1, the second one is 2, etc...
[07:40:43] <LeoNerd> These commands have some bytes as argmuents. Count them.
[07:41:28] <LeoNerd> So maybe you'll serialise these by sending the byte of the command number, then the byte saying how many more argument bytes there are, then those arguments, then you stop.
[07:41:29] <LeoNerd> Maybe you put a checksum at the end because your serial line is a little unreliable.. that might be nice
[07:41:54] <LeoNerd> "serialise" just means "take some abstract concept and turn it into numbers"
[07:42:42] <LeoNerd> It's not some weird mystical process that can only be obtained by downloading a hundred-megabyte library that originated in Google
[07:45:31] <GeneralStupid> i dont see why i should create a new solution for a totally solved problem. If this is working, i could store _one_ description file and i could use two generators. Generate C for MCU and generate C++ for the Qt part. So i could stop handling with pointers in C++ (directly). For me it is a good solution (If the memory footprint and performance is ok)
[07:49:33] <LeoNerd> Well, do that then. *shrug* I really don't care; it's not my project. You came here to ask advice; that is my advice. Take it or leave it
[09:06:12] <hetii> Hi
[09:08:24] <hetii> Hej, I design avr programmer based on esp8266 circuit:
http://www.elektroda.pl/rtvforum/download.php?id=747728 board:
http://obrazki.elektroda.pl/2277459200_1460466753.png project code:
https://bitbucket.org/hetii/espstk if any of you have idea what to change/add then feel free before I produce it.
[09:18:44] <cehteh> mhm?
[09:18:55] <cehteh> cost?
[09:20:26] <hetii> project is free, you just need to order components and make pcb :)
[09:20:28] <cehteh> i'd like some sd card slot, then when one connects a µC it identifies the chip signature, and based on that it one could select firmwares to flash autonomously
[09:20:49] <cehteh> just 0-9 on a 7 segement display and rotary encoder would be ok
[09:21:13] <cehteh> wifi .. not really a selling point for me
[09:21:59] <cehteh> 2 connectors for target µC would be nice
[09:22:21] <hetii> cehteh, then you can build that project
http://www.elektroda.pl/rtvforum/viewtopic.php?t=2016257
[09:22:37] <cehteh> while one flashes one can swap the other .. or leave a development µC permantently connecte to one port and run debugging code on it
[09:22:56] <cehteh> well .. and that all for less than $5 :D
[17:39:28] <anonnumberanon> what timer does UART use on avr?
[17:40:42] <Lambda_Aurigae> it doesn't
[17:40:50] <Lambda_Aurigae> uart has its own integrated timer.
[17:41:11] <Lambda_Aurigae> unlike the 8051 that used one of the timers to drive the uart.
[17:42:38] <anonnumberanon> ah okay that's what I was hoping, so I may be able to use uart while using timers for other purposes without worry (unless maybe I create so many timer interrupts that it messes with the UART?).
[17:46:04] <Lambda_Aurigae> depends on how you implement the uart...actually usart.
[17:46:16] <Lambda_Aurigae> it can be polled or interrupt driven.
[18:06:42] <Casper> anonnumberanon: the uart is independant to the timers, unless you go the software route (emulate the uart in software via gpio pins)
[18:07:19] <anonnumberanon> Casper, That is an interesting proposition.
[18:08:44] <Casper> man this new cooler is gigantic
[18:08:50] <Casper> I may have exagerated....
[20:46:31] * Casper throws a fish body at flyback
[22:46:13] <anonnumberanon> Is Arduino incompatible with changing the prescaler? I'm debugging my timer interrupt program. Just won't do what I want.
[22:46:27] <anonnumberanon> If it has the Arduino bootloader.
[22:56:56] <Casper> if you use the library, who knows, don't use the library... the bootloader is ok however
[23:22:54] <anonnumberanon> My damn ISR is never called I feel.
[23:33:16] <anonnumberanon> It is called only one time.
[23:54:36] <_ami_> Hello
[23:55:23] <_ami_> I am trying to compile arduino sdk using cmake. i want to use Atmega16A arch for compilation. which definition should i provide to avr-gcc?
[23:55:39] <Casper> arduino? #arduino
[23:56:02] <_ami_> Casper: using avr-gcc though :)
[23:56:25] <Casper> it's arduino madness
[23:56:36] <Casper> don't use arduino library junk
[23:57:25] <anonnumberanon> Don't be that Arduino bashing person who irritates people and make them want to keep using Arduino.
[23:57:33] <anonnumberanon> It's become a meme now I feel.
[23:58:14] <Casper> there is a channel just for it, they don't have to come here for that cancer
