#avr Logs

Mar 07 2018

12:34 AM polprog: kinda makes me want to check sqrt*sqrt directly on the FPU (in assmebly)
12:38 AM rue_: might want to see the gcc source first
12:38 AM polprog: too much hassle
12:38 AM rue_: gcc -S
12:38 AM polprog: g++ -S
12:38 AM polprog: oh
12:38 AM rue_: yea
12:38 AM rue_: if 2 characters is too much hastle, kill yourself now, cause it just gets worse
12:38 AM polprog: i thought you wanted me to browse gcc source code :D
12:39 AM * polprog ties a feedback loop on his neck
12:40 AM * Casper cuts the loop
04:18 AM xoomas: hi
04:25 AM xoomas: Emil you here? :)
05:18 AM xoomas: cant make ringbuffer working ;D
05:18 AM Haohmaru: why?
05:20 AM cehteh: heh
05:21 AM cehteh: btw good excercise: make it work on your pc, write portable C
05:21 AM cehteh: easier to debug
05:22 AM xoomas: but that Emil dont do anything about ring buffer when its read
05:22 AM Haohmaru: C++ ;P~
05:22 AM xoomas: on youtube i seen the after each read index should be decremented
05:22 AM Haohmaru: last night i posted my buffered UART template class, maybe check it out
05:23 AM xoomas: Haohmaru it was way too complicated :D
05:23 AM Haohmaru: it should work on atmega2561/2560/640/1281/1280 and probably on others with some minor modification
05:23 AM cehteh: Emils code is a bit special, because he uses the natural overflow of a byte
05:23 AM xoomas: i even cant figure out what is wrong with 2 functions :D
05:23 AM cehteh: his buffer only works on a 256 byte size
05:24 AM xoomas: i made it smaller
05:24 AM xoomas: 16 byte
05:24 AM cehteh: then emils code wont work anymore
05:24 AM cehteh: as is
05:24 AM Haohmaru: cehteh and i used only power-of-two sizes and wrap the index with bitwise AND
05:24 AM xoomas: hmm ok i can try increase ir
05:24 AM cehteh: Haohmaru: i use any size, not only power of 2
05:24 AM cehteh: 40 if (cbuffer->start >= size)
05:24 AM cehteh: 41 cbuffer->start -= size;
05:25 AM Haohmaru: cehteh i have that sort of class for xmega
05:25 AM cehteh: ... almost as simple as AND'ing
05:25 AM Haohmaru: sure
05:25 AM cehteh: i shown my code to xoomas few days ago too
05:25 AM cehteh: meanwhile he should figure it out :D
05:25 AM Haohmaru: so many options then
05:25 AM xoomas: but im too noob :D
05:25 AM Haohmaru: and he picked Emil's code >:)
05:26 AM xoomas: dont even use ->
05:26 AM xoomas: its like C++ code
05:26 AM Haohmaru: mine *was* C++11 afaik
05:26 AM xoomas: emils code looked simpest
05:26 AM cehteh: xoomas: first think about how a ringbuffer works
05:26 AM xoomas: :)
05:26 AM cehteh: yes but most fragile
05:26 AM cehteh: worked as is, but a little change makes it going boom
05:26 AM xoomas: i watched i think all youtube viodeos
05:27 AM Haohmaru: it's like a snake that eats pixels and shits the same pixels in the same order ;P~
05:27 AM xoomas: about ring buffer
05:27 AM xoomas: they all use head and tail
05:27 AM cehteh: youtube videos about ringbuffers .. wtf
05:27 AM Haohmaru: should be head and butt ;P~
05:27 AM cehteh: i use head+length
05:27 AM xoomas: if data received.. it puts in head
05:27 AM cehteh: but anything should be possible
05:28 AM cehteh: lets say yu have 8 memory locations "________"
05:28 AM xoomas: and when they read from ringbuffer they remove tail index
05:28 AM xoomas: ok
05:28 AM cehteh: then when you push tihngs they are appended to the end:
05:28 AM cehteh: "1_______" "12______" ...
05:29 AM cehteh: when you pop data its removed from the head
05:29 AM cehteh: removing first byte "_2______"
05:29 AM xoomas: hmm on youtube it was other way around ;D
05:29 AM xoomas: add to head remove from tail
05:29 AM xoomas: it was like fifo
05:29 AM cehteh: you can reverse the direction or the meaning of those words
05:30 AM cehteh: yes fifo/queue .. all the same
05:30 AM cehteh: so far so good: now the only things you need to care about is: a) at the end of the buffer it needs to wrap over to the start
05:30 AM xoomas: in youtube they use mod
05:31 AM cehteh: and b) when you try to push more data than the buffer may hold then the end would run into the head
05:31 AM cehteh: mod is the worst
05:31 AM xoomas: :D
05:32 AM cehteh: you can use AND like Haohmaru suggested, or check and substration like mine
05:32 AM xoomas: last video was funy.. guy sayed when read from bufer.. you decrease buffer count
05:32 AM xoomas: it was 5
05:32 AM xoomas: he deleted it and again wrote 5
05:32 AM xoomas: :D
05:32 AM xoomas: thinked few seconds
05:32 AM cehteh: AND is one instruction, mine are prolly 3 instructions, but advantage on my approach is that it can handle buffer sizes which are not a power of 2
05:32 AM xoomas: but left 5 :D
05:33 AM xoomas: hmm
05:33 AM xoomas: maybe need to try yours
05:33 AM cehteh: mine works :D
05:33 AM xoomas: oh but first lets try with 256
05:33 AM cehteh: some AVR's dont even have 256bytes of ram at all :)
05:34 AM cehteh: tiny13 has only 64 bytes
05:34 AM xoomas: Data: 281 bytes (27.4% Full)
05:34 AM cehteh: that says nothing
05:34 AM xoomas: atmega8 looks like have
05:34 AM cehteh: because you also need space for stackframes
05:34 AM cehteh: and local variables
05:35 AM xoomas: 1K Byte Internal SRAM
05:35 AM xoomas: but anyhow
05:35 AM xoomas: with 256
05:35 AM xoomas: its still acting weird
05:36 AM cehteh: most likely you still have these race conditions
05:36 AM xoomas: btw
05:36 AM cehteh: did you fix those correctly as i shown?
05:36 AM xoomas: i think last night was bad idea to use local variables
05:36 AM xoomas: i corrected
05:36 AM cehteh: depends
05:37 AM xoomas: but it was like ever after atmega reset
05:37 AM xoomas: i still had hello world letters in buffer
05:37 AM xoomas: :D
05:37 AM cehteh: you shouldnt do too much nested function calls which reserver local variables, esp recursion, that eats ram like nomore
05:37 AM cehteh: then you didnt properly initalize your data
05:38 AM cehteh: dont work around that by memset or whatever, but rather fix the bug at its root
05:38 AM Haohmaru: i use code blocks to control temporary variable life ;P~
05:38 AM Haohmaru: or was it scope blocks
05:38 AM cehteh: yeah
05:38 AM cehteh: so bbl
05:38 AM xoomas: anyhow
05:38 AM Haohmaru: { int tmp = 3+5; func(tmp); }
05:38 AM xoomas: i think i need to start from begining
05:39 AM xoomas: https://www.avrfreaks.net/forum/tutsoft-interrupt-driven-uart-receive-ring-fifo-buffer
05:39 AM xoomas: what about this ?
05:42 AM Haohmaru: it looks a bit fishy to me on first sight
05:44 AM Emil: xoomas: I'm always here
05:44 AM Haohmaru: ur LATE!
05:44 AM xoomas: yep :D
05:44 AM Haohmaru: ur FIRED!
05:44 AM * Haohmaru yells
05:44 AM xoomas: already deleted code
05:44 AM xoomas: gona start from begining; )
05:44 AM Emil: And I did mention prevoisly that if you change it you need to know what you are doing ;)
05:45 AM Emil: Haohmaru: fuq
05:45 AM xoomas: can we write fresh ring buffer? :))
05:45 AM xoomas: from start to finish :)
05:46 AM Haohmaru: take the C++11 one ;P~
05:46 AM Haohmaru: you can declare two or more instances of it, each with a different size
05:46 AM Emil: I still have my 2 months right?
05:46 AM xoomas: its enough c for now ;D
05:46 AM Haohmaru: take advantage of teh C plus plus!
05:47 AM xoomas: first thing is to declare buffer size
05:49 AM Emil: xoomas: for a ringbuffer
05:49 AM Emil: xoomas: you need an index and the buffer
05:49 AM Haohmaru: don't you need two indecies
05:49 AM Emil: Haohmaru: well yes
05:50 AM Haohmaru: a head and a butt
05:50 AM Emil: optionally can add how much stuff is in it
05:50 AM Emil: but yeah two indexes
05:50 AM Haohmaru: i have that in mine, plus a counter that tracks the peak usage ;P~
05:50 AM Haohmaru: fancy-schmancy ;P~
05:52 AM xoomas: Emil thats what was wrong with your code
05:52 AM xoomas: i think :))
05:53 AM xoomas: i can fill it but cant control what i read
05:53 AM xoomas: https://pastebin.com/N20GJXim
05:53 AM xoomas: empty shell :D
05:54 AM Haohmaru: i really strongly suggest you don't read with that function ;P~
05:54 AM Haohmaru: make yourself a peek() function that checks if there are bytes to read
05:55 AM Haohmaru: then read a byte only if so
05:55 AM xoomas: im trying to write fresh ring buffer
05:56 AM xoomas: not looking at any :)
05:56 AM xoomas: with your help :)
05:56 AM Haohmaru: FIFO_t fresh; // there
05:56 AM xoomas: maybe that way will be easyer to understand
05:56 AM Haohmaru: if (fresh.peek()) { fresh.get(); }
05:57 AM xoomas: volatile unsigned char buffer[RING_BUFFER_SIZE];
05:57 AM xoomas: volatile unsigned char head = 0;
05:57 AM xoomas: volatile unsigned char tail = 0;
05:57 AM xoomas: Haohmaru im not that good at coding :)
05:57 AM xoomas: need slower ;))
05:58 AM xoomas: ok now i have buffer and two indexes
06:00 AM xoomas: so peek means only checking if there is something?
06:01 AM Haohmaru: yes
06:01 AM xoomas: and peek would be something like this if head<>tail then there is something?
06:01 AM Haohmaru: because you should NOT try to read from the FIFO if it's empty
06:01 AM Haohmaru: yes
06:02 AM xoomas: but there also should be check if head == tail
06:02 AM Haohmaru: and i suggest you prevent the FIFO from becoming empty when it goes over capacity
06:02 AM xoomas: that i dont understand
06:03 AM xoomas: also im bit lost how it knows where to read
06:03 AM Haohmaru: cuz then it makes it possible to peek() (which returns true cuz the fifo is full), and then just as you attempt to read a byte - an interrupt happens, another byte has to be added to the full FIFO - and if the fifo turns into "empty" then when your read continues - it will be trying to read from an empty fifo
06:04 AM Haohmaru: you write at the position of one index, and you read off at the position of the other index
06:04 AM Haohmaru: head and tail, tail and head, head and butt, doesn't matter how you call them as long as you don't mix them up
06:05 AM Haohmaru: i call em iw and ir ;P~
06:05 AM Haohmaru: index_write, index_read
06:05 AM Haohmaru: but i'm not a good example of a coder ;P~
06:05 AM xoomas: maybe i should do same :))
06:06 AM xoomas: im tryng to do as i readed and watched on inet
06:06 AM Haohmaru: nah, follow Emil's example, then i we can blame him for our ugly codez
06:06 AM xoomas: :D
06:06 AM xoomas: Emil code was simple
06:06 AM xoomas: but maybe not very explaining him self :D
06:07 AM xoomas: i only seen there one index
06:07 AM xoomas: and it was like i can fill buffer but no way to read it propertly :D
06:10 AM Haohmaru: oh, also, my code included both transmition and reception, both interrupt-driven
06:10 AM Haohmaru: so that's another reason for it to look big
06:11 AM Haohmaru: but interrupt-driven transmition is very nice, it frees up your main() process from waiting like a dumb sheep ;P~
06:11 AM xoomas: my avr should be dumb :D
06:11 AM Haohmaru: use a pic then >:/
06:11 AM xoomas: it only have to wait for command and do its thing
06:11 AM xoomas: :D
06:11 AM Haohmaru: cuz they come "dumb" out of the box
06:12 AM xoomas: https://pastebin.com/SJRjm1mQ
06:12 AM xoomas: how is this
06:12 AM xoomas: btw
06:13 AM Haohmaru: "<>" o_O
06:13 AM xoomas: if now i only peeking at buffer
06:13 AM Haohmaru: does that even compile?
06:13 AM xoomas: oh :D
06:13 AM xoomas: delphi in head ;D
06:13 AM polprog: delphi?
06:13 AM Haohmaru: it should be !=
06:14 AM polprog: that programmin language i only heard about :D
06:14 AM Haohmaru: and you can just make the whole function bool peek() { return (head != tail); }
06:14 AM Haohmaru: maybe not bool but uint8_t
06:14 AM Haohmaru: definately not void ;P~
06:15 AM polprog: #define PEEK() (head != tail)
06:15 AM Haohmaru: x_x
06:15 AM polprog: why the call overhead :^)
06:15 AM Haohmaru: have faith in teh compil3r
06:16 AM Haohmaru: what if you need 2 UARTs?
06:16 AM polprog: i did define a delay like that with sdcc for stm8
06:16 AM xoomas: hmm
06:16 AM xoomas: bool peek()
06:16 AM xoomas: {
06:16 AM xoomas: return (head != tail);
06:16 AM xoomas: }
06:16 AM xoomas: this also not compiles
06:16 AM xoomas: :D
06:17 AM Haohmaru: probably because of the "bool"
06:17 AM Haohmaru: make it uint8_t
06:17 AM xoomas: but why it cannot be bool?
06:17 AM polprog: or include stdbool i think
06:17 AM Haohmaru: switch to C++ and it'll probably work ;P~
06:17 AM xoomas: ah
06:17 AM xoomas: more includes
06:17 AM Haohmaru: moar plusses behind the C!
06:18 AM xoomas: ok now its compiles
06:18 AM xoomas: so now i should use peek() in while(1)?
06:21 AM polprog: objects would work well in such case
06:21 AM polprog: C += 2
06:22 AM xoomas: hmm
06:22 AM xoomas: i think i first need tke care of ISR
06:23 AM xoomas: ISR(USART_RXC_vect)
06:23 AM xoomas: {
06:23 AM xoomas: buffer[head++] = UDR;
06:23 AM xoomas: }
06:23 AM xoomas: but i think here need more stuff
06:23 AM xoomas: :D
06:23 AM Haohmaru: yes, you really want to deal with the situation where your fifo is full
06:24 AM Haohmaru: i suggest you keep it full and just reject new bytes
06:24 AM Haohmaru: that means data corruption, but at least you won't break the peek()/read() logic
06:25 AM Haohmaru: the idea behind peek() is that you should always check whether you *can* read a byte
06:25 AM Haohmaru: then your read() function will not contain any waiting or IFs
06:26 AM xoomas: but read function also have to do tail++ ?
06:26 AM Haohmaru: read() will just get a byte from the buffer, increment the read index, and return the byte it got
06:27 AM xoomas: but if need to grab whole data
06:27 AM xoomas: i mean as much as buffer received
06:27 AM Haohmaru: yeah, so something like uint8_t read() { const uint8_t data = buffer[index_read]; ++index_read; return data; }
06:27 AM Haohmaru: then you loop
06:27 AM Haohmaru: while (peek()) { read(); }
06:28 AM xoomas: ../main.c:98: warning: the address of 'peek' will always evaluate as 'true'
06:28 AM Haohmaru: o_O
06:28 AM xoomas: somehow it warns this ;)
06:28 AM Haohmaru: what kind of compiler warning is that
06:28 AM Haohmaru: i've not seen it
06:29 AM xoomas: its avr studio
06:29 AM xoomas: 4.18
06:30 AM Haohmaru: did you write something like while(peek) { .. } ?
06:31 AM xoomas: yes
06:32 AM xoomas: while(1)
06:32 AM xoomas: {
06:32 AM xoomas: while(peek) {};
06:32 AM xoomas: }
06:32 AM Haohmaru: that explains it ;P~
06:32 AM xoomas: :))
06:32 AM Haohmaru: peek() !
06:32 AM xoomas: fixed it
06:33 AM Haohmaru: "peek" is probably returning the address of the function, and you want to call the function, not get its address
06:33 AM xoomas: btw
06:33 AM xoomas: ++tail
06:33 AM xoomas: tail++ is not good?
06:33 AM Haohmaru: they are different
06:34 AM xoomas: const uint8_t data = buffer[head];
06:34 AM Haohmaru: if you do buffer[++tail] and buffer[tail++] you'll end up with different bytes
06:34 AM xoomas: this also but not clear
06:34 AM Haohmaru: pre increment vs post increment
06:34 AM xoomas: buffer head
06:35 AM xoomas: ah its my mistake ;D
06:35 AM xoomas: again mixing tail head with your inder read write ;D
06:36 AM Haohmaru: i don't like this head/tail thing
06:36 AM Haohmaru: because i think of it as a snake
06:36 AM Haohmaru: then bytes are put on its head
06:37 AM xoomas: to feed snake ;D
06:37 AM Haohmaru: but other people think of an actual queue, where people arrive at the end of the queue (tail)
06:37 AM xoomas: while(peek()) {USART_Send(read());};
06:37 AM xoomas: is this very bad thing to do?
06:38 AM Haohmaru: not too bad
06:38 AM Emil: xoomas: there's nothing wrong with my code
06:38 AM Haohmaru: but depending on how USART_Send() is implemented, you may end up unable to do anything else while you have data
06:38 AM Emil: Haohmaru: also my code is beautiful
06:38 AM xoomas: while ((UCSRA & (1 << UDRE)) == 0) {};
06:38 AM xoomas: UDR=data;
06:39 AM Haohmaru: specifically if USART_Send() does busy waiting
06:39 AM xoomas: here is send
06:39 AM Haohmaru: yup, there's the busy wait there
06:39 AM xoomas: not good>?
06:40 AM xoomas: hmm what other way to see if im reading ringbuffer ok :D
06:40 AM Haohmaru: so ideally you would want to use interrupt-driven transmit, then you can have this thing going and still be left with plenty of free time in main() to process other things
06:40 AM Emil: here's the thing also
06:40 AM xoomas: im not usind interupt driven transmit
06:40 AM Emil: if you dont use the good properties of ringbuffer
06:41 AM Emil: dont use ringbuffers
06:41 AM Haohmaru: but interrupt-driven transmit is a bit trickier to do compared to interrupt-driven receive
06:41 AM xoomas: im only using RXCIE
06:41 AM Haohmaru: yeah, i know
06:42 AM xoomas: so i better add data to another buffer?
06:42 AM Haohmaru: if you only want to transmit in order to debug your reception - then maybe it's not worth it
06:43 AM xoomas: what other way to debug
06:43 AM Haohmaru: if you will need to transmit later on as part of your program's normal operation - then it's good
06:43 AM Haohmaru: well, depends, but you could test this in a few other ways
06:44 AM Haohmaru: send it a long string of (for example) incrementing values
06:44 AM xoomas: ring buffer is 16 bytes long
06:44 AM Haohmaru: and in your main(), as you read them, use a counter to count together with the transmitter, and compare if you are getting the "right" values
06:44 AM Haohmaru: yeah, then send it 16 bytes at a time
06:44 AM Haohmaru: or 15
06:45 AM Haohmaru: do a bunch of bursts so that the values grow and so that the indecies wrap around a few times
06:45 AM Haohmaru: if a byte value doesn't match - switch ON a LED or something
06:48 AM Haohmaru: otherwise, you should first try to implement the transmition, to get it working (because you can test that a bit easier), and once you know your transmition works properly - you can use it to debug the reception code
06:50 AM xoomas: i know uart is working ;)
06:50 AM xoomas: if i do echo
06:51 AM xoomas: i get good reception
06:51 AM xoomas: mybuffer[index] = read();
06:51 AM xoomas: index++;
06:51 AM xoomas: if (index > 16) { index = 0; }
06:51 AM xoomas: is this looks logic? :D
06:51 AM Haohmaru: i meant interrupt-driven transmition
06:51 AM xoomas: you mean interupt driven RX?
06:51 AM Haohmaru: but it's a bit more complicated compared to what you're doing now (interrupt-driven reception)
06:53 AM oxymoron93: R is for receive
06:54 AM Haohmaru: xoomas get that code i posted last night and just save it somewhere so you can look at it for reference
06:55 AM Haohmaru: cuz the paste will expire soon-ish
06:58 AM xoomas: umm
06:58 AM xoomas: how to find it ;D
06:58 AM xoomas: need to check logs
06:59 AM Haohmaru: i can repeat it when i get back home.. but that's not gonna be soon-ish ;P~
06:59 AM Haohmaru: ctrl+f for "paste.debian.net"
07:00 AM Haohmaru: it was "hidden"
07:07 AM xoomas: http://paste.debian.net/hidden/f1923a76
07:10 AM xoomas: hmm
07:10 AM xoomas: my buffer started to working somhow ok :D
07:10 AM xoomas: btw
07:10 AM xoomas: i think i need to clear it when reading?
07:11 AM Haohmaru: nope
07:12 AM Haohmaru: unless you're receiving sensitive information ;P~
07:12 AM xoomas: but then peek is useles
07:12 AM xoomas: if there is allways data
07:12 AM xoomas: :D
07:12 AM Haohmaru: eh? why?
07:12 AM Haohmaru: no
07:13 AM Haohmaru: the buffer is always gonna be N bytes "big" and there are always there in the RAM
07:13 AM xoomas: for example now i just reseted atmega
07:13 AM Haohmaru: but how much "bytes" you have available to process from that buffer depends on the two indexes
07:13 AM xoomas: every 5 sec c i copy buffers
07:14 AM xoomas: now i get 16 x 0x00
07:14 AM xoomas: also i put toggle led in peek
07:14 AM xoomas: if peek true
07:15 AM xoomas: led toggles
07:15 AM xoomas: now its allways off
07:15 AM xoomas: when i send packet
07:15 AM xoomas: it turns on
07:16 AM Haohmaru: if you "toggle" then the LED will be either ON or OFF when your thing is idle, depending on how many times you called peek()
07:16 AM Haohmaru: if you peek() pretty often then the LED will get PWM'ed
07:17 AM xoomas: every 5 sec
07:17 AM xoomas: https://i.imgur.com/ga259PD.png
07:17 AM xoomas: here how it looks on terminal
07:17 AM xoomas: first it allways gets zeros
07:17 AM xoomas: empty ring :)
07:18 AM xoomas: then i send hello world
07:18 AM xoomas: after 5 sec led turns on
07:18 AM xoomas: and i get hello world 000000
07:18 AM xoomas: sometihg like this
07:18 AM cehteh: did you try to run/experiment with the ringbuffer on your pc?
07:18 AM xoomas: and it repeats
07:19 AM xoomas: how you mean?
07:19 AM cehteh: using linux or windows?
07:19 AM xoomas: im using windows
07:19 AM cehteh: you can just write portable code and compile it as small commandline test program
07:19 AM cehteh: experimenting with that
07:20 AM cehteh: easier to debug
07:20 AM xoomas: better i try with atmega ;D
07:20 AM cehteh: ok
07:20 AM xoomas: its already connected
07:20 AM xoomas: and atleast now im getting somethin :D
07:20 AM cehteh: so now you receive zeros?
07:20 AM xoomas: not like rubish data ;D
07:20 AM cehteh: just some bugs left :D
07:20 AM xoomas: zeros until ring buffer is empty
07:20 AM xoomas: i suppose that should be ok
07:20 AM cehteh: no
07:21 AM Haohmaru: it doesn't matter that the buffer contains 16 zeros on init, because you will not be able to read() them
07:21 AM xoomas: as im copyng bufffer out of peek
07:21 AM cehteh: the ringbuffer should start empty, whenever you receive data it will be appended there
07:21 AM Haohmaru: if everything is done right, you will NEVER be able to read those initial values
07:21 AM cehteh: and whenever you consume (echo) data it should be removed
07:21 AM cehteh: until the ringbuffer is empty again
07:22 AM cehteh: you dont need to clear anything or such, once only at program start it must be inititalized (but C will pretty much do that for you when done right)
07:23 AM cehteh: initialized as in setting the head and tail (or length)
07:23 AM Haohmaru: all you need to do is ensure that the two indexes are initialized to the same value
07:23 AM Haohmaru: same value for both indexes == "empty FIFO"
07:23 AM Haohmaru: doesn't matter whether it's 0 or 5 or size-1
07:23 AM xoomas: https://pastebin.com/k58NzRrt
07:23 AM cehteh: btw i had some reason that i use only one index+ length :D
07:24 AM cehteh: eventually you want to do the send in a ISR too
07:24 AM cehteh: and indent your code grr
07:25 AM cehteh: and .. eh .. before something bad happens, dont use eeprom writing, or at least put a delay(1000) in that function FOR DEBUGING ONLY
07:26 AM cehteh: because you can accidentally write in a fast loop into the eeprom and wear it out in no time
07:26 AM Haohmaru: i already told him that interrupt-driven transmit is MUCH better
07:26 AM cehteh: at least for generoic things
07:26 AM xoomas: im not writing to any eeprom now
07:27 AM cehteh: ah and you send the whole buffer .. of course you send any crap (zeros) with it
07:28 AM xoomas: im sending this now only for debug
07:28 AM xoomas: to see if i fill buffer at all
07:28 AM Haohmaru: don't worry about the zeros ;]
07:28 AM xoomas: so i think i fill now
07:28 AM cehteh: back to start: you need a push and a pop function for the ringbuffer at least (and possibly a length or is_empty)
07:28 AM Haohmaru: unless you receive passwords or sensitive data ;P~
07:28 AM xoomas: im not worry im thinking its doing it ok :D
07:28 AM Haohmaru: cehteh he has peek()
07:29 AM cehteh: and you have a off-by-one error
07:29 AM cehteh: if (index > 16) { index = 0; }
07:29 AM cehteh: if (index > 15) { index = 0; } !!
07:29 AM Haohmaru: o_O
07:29 AM Haohmaru: are we looking at the same code?!
07:30 AM xoomas: btw
07:30 AM cehteh: https://pastebin.com/k58NzRrt
07:30 AM xoomas: if i use index >15 i only get 15 bytes in uart
07:30 AM xoomas: dont know why it is
07:30 AM xoomas: i also thougnt should be 15
07:30 AM xoomas: :D
07:32 AM cehteh: 0 ..15 are 16 elements and your buffer has only 16 elements
07:32 AM xoomas: becouse 0-15 = 16
07:32 AM xoomas: yes
07:32 AM cehteh: yes it must be 15
07:32 AM cehteh: so, your error is somewhere else
07:32 AM xoomas: but then why i start getting 15bytes in terminal?
07:32 AM Haohmaru: oh, that bug is in his main() code
07:32 AM Haohmaru: i was only staring at the FIFO-related code
07:32 AM cehteh: btw 'peek' usually returns some value (like the last, first, or some given function)
07:32 AM cehteh: better name that is_empty or is_available or such
07:32 AM Haohmaru: in my case, peek() is the opposite of is_empty()
07:32 AM cehteh: yeah bit confusing naming
07:32 AM Haohmaru: could be, i don't care ;P~
07:32 AM Haohmaru: rename it to avail() then
07:33 AM cehteh: and read() doesnt handle the overflow/wraparound either
07:33 AM xoomas: cehteh
07:33 AM Haohmaru: wut
07:33 AM xoomas: im not that guru to write whole error handling in one go ;)
07:34 AM Haohmaru: cehteh it doesn't have to if you take responsibility to never call read() if you haven't called avail() first
07:34 AM xoomas: first i want to make sure im fulling buffer
07:34 AM xoomas: then ill take care of errors :D
07:34 AM cehteh: make a barebones ringbuffer stuff without any uart things at all first
07:35 AM cehteh: implement push() pop() avail() or however you want to name them
07:35 AM Haohmaru: that works too, then you can test it easily in a commandline program on your computer
07:35 AM Haohmaru: but it'll need a few more functions
07:35 AM cehteh: yeah
07:35 AM cehteh: but first the basics
07:35 AM cehteh: i often test complex algorithms on the computer first too, thats much easier
07:36 AM Haohmaru: i test semi-complex algorithms in mIRC ;P~
07:36 AM Haohmaru: sometimes
07:36 AM cehteh: and when its protable between linux and avr .. its well written C already :) which reduces the chance of bugs
07:36 AM cehteh: also compile with -Wall -Wextra
07:36 AM cehteh: fix all warning
07:37 AM xoomas: anyhow have to go now for a while:)
07:37 AM Haohmaru: -std=C++11 -Wpedantic -HURTMEPLENTY
07:37 AM cehteh: i am away for a few days later on :D
07:38 AM cehteh: going to north germany :D
07:38 AM Haohmaru: that's.. too.. north
07:47 AM polprog: kettle fixed
08:11 AM polprog: Haohmaru: is that a valid option?
08:12 AM Haohmaru: which one? ;P~
08:14 AM polprog: hurtmeplenty :D
08:14 AM Haohmaru: it's a difficulty level in Quake2 ;P~
08:15 AM polprog: i know
08:15 AM polprog: ive just see so many gcc options i wouldnt be surprised if that was valid
08:15 AM Haohmaru: my jokes don't compile
08:16 AM polprog: maybe you nees to interpret them better
08:16 AM Haohmaru: i wouldn't be surprised if they add it as an alias that enables a ton of other arguments ;]
08:16 AM polprog: lol
08:16 AM polprog: yeah :D
08:17 AM Haohmaru: they need to add a feature -vulgar
08:17 AM Haohmaru: where any warnings and errors use dirty language
08:17 AM Haohmaru: for teh funz
08:18 AM polprog: i have sudo insultso
08:18 AM polprog: insults on all my machines enabled
08:18 AM Haohmaru: "unresolved reference, b*tch!"
08:19 AM Haohmaru: "expected lvalue ^. u so lame"
08:20 AM polprog: invalid token, are you f**ing blind?
08:20 AM Haohmaru: "void function returning value. omg u so duuuumb."
08:20 AM polprog: lol
08:20 AM Haohmaru: that would be so kewl
08:22 AM polprog: prof to student: "Your program would make Marks proud, everything in ine class"
08:22 AM polprog: one*
08:22 AM polprog: grr
09:35 AM polprog: made some meatballs
09:35 AM polprog: and fries
09:39 AM Haohmaru: that's what i'll have for dinner too
09:39 AM * polprog hi fives Haohmaru
11:15 AM Ameisen: What's the right kind of circuit to use if I have an MCU being powered (indirectly, through a step-down) from a 36VDC poewr supply, and a stepper driverbeing powered by the 36VDC power supply
11:15 AM Ameisen: to prevent induction/noise from hitting the MCU
11:16 AM Ameisen: I am going to be using photocouplers on data lines (like step/dir), but on the actual power lines, I imagine there needs to be something - series' of capacitors?
11:16 AM cehteh: are the data lines 36v?
11:17 AM cehteh: or excessively long
11:22 AM Casper: Ameisen: I do not see the point for the opto
11:23 AM Ameisen: data lines are 3.3v
11:23 AM Casper: for the noise, a series inductor with a cap should be fine, if even needed
11:25 AM cehteh: step down should be enough for the MPU, when you want to use the analog parts, analog sensors the maybe extra filtering/power rails for those
11:26 AM Jartza: eveningh
11:26 AM cehteh: for data lines just driving them a bit stronger should also be fine (how are they driven?), shielding or differential signaling when the cables are long
11:28 AM cehteh: fuse/crowbar when you want to protect it against voltage regulator fails, clamping/zener diodes and maybe resitors on the inputs on data lines
11:28 AM Ameisen: an arm board is driving the data lines from GPIO
11:29 AM cehteh: driving both potentials or is one pulled up/down with a resistor?
11:29 AM Ameisen: they're output GPIOs (not reading data). I just don't want there to be any backfeed due to inductance from the driver that could damage the board
11:30 AM Casper: if there is feedback, it mean you need to fix that issue first
11:30 AM cehteh: clamping diodes will take care for that
11:30 AM cehteh: possibly the gpios already have some
11:31 AM cehteh: at least avr have, dunno about arm
11:40 AM xoomas: im back ;D
11:41 AM xoomas: for (uint8_t i = 0; i < 16; i++)
11:41 AM xoomas: dont get it
11:41 AM nux_: lol woot ?
11:41 AM xoomas: why i need to do up to 16
11:41 AM xoomas: if i need to get 16 values
11:42 AM nux_: 0 til 15 is 16 values ;)
11:42 AM xoomas: its not
11:42 AM xoomas: if i do 0 to 15 i get 15
11:42 AM xoomas: dont know why :D
11:42 AM nux_: read what i said
11:43 AM xoomas: i see what you wrote
11:44 AM xoomas: but im getting 15 values
11:45 AM cehteh: doing something wrong
11:46 AM xoomas: now did like this:
11:46 AM cehteh: if (index > 16) { index = 0; } is also off-by-one
11:46 AM xoomas: for (uint8_t i = 0; i < 16; i++) { USART_Send(i);}
11:46 AM Emil: xoomas: for(i=0; i<16; i++) will repeat 16 times
11:46 AM xoomas: and i get from 0 to 16
11:46 AM Emil: from i=0 to i=15
11:47 AM Emil: and when exited out of tje block i will be 16
11:47 AM xoomas: huh?
11:47 AM cehteh: oops yes my fault
11:47 AM Emil: if index>=16
11:47 AM cehteh: but the other one is wrong
11:48 AM Emil: not just >
11:49 AM xoomas: atleast now that buffer fills correctly :))
11:49 AM antto: xoomas if it helps, you can use a while () loop instead of for ()
11:50 AM xoomas: so for (uint8_t i = 0; i < 16; i++) is right?
11:50 AM antto: for loops confuse me, i avoid them
11:50 AM xoomas: i like for :D
11:50 AM antto: then u shall SUFFER!
11:50 AM xoomas: but cehteh confused me a bit :D
11:51 AM xoomas: last valid i is 15
11:51 AM xoomas: so 0 to 15 values
11:51 AM xoomas: count is 16
11:51 AM nux_: xoomas, 0 is a value, 0x0-0xf -> same as 0->15, total of 16 values.
11:51 AM xoomas: yes
11:52 AM xoomas: but cehteh sayed that need for(i=0; i<15; i++) to get 16 values
11:52 AM Emil: no
11:52 AM xoomas: that where i get confused ;D
11:52 AM Emil: he didnt
11:52 AM nux_: he did not :p
11:53 AM Ameisen: I had for (int i : from(0, 16)) once
11:53 AM Ameisen: but Visual C++, at the time, failed to optimize it for trivial cases.
11:53 AM Ameisen: it also failed to optimize trivial uses of std::accumulate
11:53 AM Ameisen: not sure if they've fixed that.
11:54 AM Ameisen: g++ and clang optimized it fine
11:54 AM xoomas: or maybe i confused my self :))
11:54 AM xoomas: when we talked about that index reset ;D
11:55 AM xoomas: anyway
11:55 AM xoomas: its ok :)
11:56 AM xoomas: now need to add those head tail checks
11:56 AM xoomas: also i think i need to know how much bytes i got in one packet
11:57 AM Emil: mate
11:57 AM Emil: if you have a packet format
11:57 AM Emil: ugh
11:58 AM xoomas: what then?
11:59 AM antto: xoomas packet format is something that the UART FIFO doesn't care about
11:59 AM antto: you need to deal with the packets outside of that
12:00 PM xoomas: but i need to know when packet arrived and how big it is
12:01 PM xoomas: to get it to my buffer
12:01 PM cehteh: xoomas: sorry that way my fault earlier, didnt paied enough attention
12:01 PM xoomas: then i can parse it
12:01 PM xoomas: no worry cehteh :)
12:02 PM antto: i'd use a sepparate buffer for packet stuff
12:02 PM antto: in fact, that's exactly what i do
12:02 PM xoomas: i have sepparate
12:02 PM xoomas: and i copy from ring to it
12:03 PM xoomas: but problem is that now i copy all
12:03 PM xoomas: becouse i dont know where my new packet arrived and where it ends :)
12:03 PM antto: eh?
12:04 PM antto: you should be reading from your FIFO byte by byte, don't copy stuff around
12:04 PM antto: at least not yet
12:05 PM xoomas: im rading
12:07 PM xoomas: https://pastebin.com/e1evHpCH
12:07 PM xoomas: antto maybe wil be more clear :D
12:20 PM xoomas: hmm
12:21 PM xoomas: looks like now working ok but not understand one thing
12:21 PM xoomas: :)
12:21 PM xoomas: now it read from ring buffer exactly what is sent
12:22 PM xoomas: but i dont get if i send more then 16 bytes
12:22 PM xoomas: and im getting more
12:22 PM xoomas: but ring buffer size is 16
12:22 PM xoomas: and mybuffer size is 16
12:31 PM Tom_itx is now known as Tom_L
12:31 PM cehteh: make mybuffer 32 or 64 bytes and the ringbuffer onpy 8 bytes, then you can test it better
12:31 PM xoomas: https://pastebin.com/aQry4AgE
12:31 PM xoomas: here how it looks now
12:31 PM cehteh: 64byte is reasonable for some (short) commanline interface for example
12:31 PM xoomas: ok
12:32 PM xoomas: but if some eeproms have page like 256 bytes
12:33 PM xoomas: + command and address
12:33 PM cehteh: Emil: i sometimes have more rich commandline interface, set variablename value ... could easily exceed 16 bytes
12:33 PM xoomas: #define RING_BUFFER_SIZE 8
12:33 PM xoomas: #define MY_BUFFER_SIZE 32
12:34 PM xoomas: what should i expect?
12:34 PM xoomas: if i send like 16 bytes
12:34 PM cehteh: its up to you, you should see the ringbuffer in action
12:34 PM xoomas: i have to get chopped message?
12:35 PM xoomas: hmm
12:35 PM xoomas: i just got exactly what i sent
12:35 PM cehteh: when done right you should be able to send up to 32 bytes which get transfered into mybuffer
12:35 PM xoomas: i got sent 16
12:36 PM xoomas: got 16
12:36 PM xoomas: will try now send like 40
12:36 PM cehteh: note that you drain the ringbuffer in your main loop pretty fast, for now your ringbuffer will prolly never hold more than a single byte
12:36 PM cehteh: this ringbuffer only catches up when your loop runs to slow for some reason
12:36 PM xoomas: thats what i thought :D
12:37 PM cehteh: and it is also the machinery to transfer data from a ISR to normal execution
12:37 PM xoomas: yep 40sent : 40 received
12:37 PM cehteh: doesnt 40 overflow your 'mybuffer' havent checked that code
12:38 PM xoomas: i got correct data
12:38 PM xoomas: thats strange
12:39 PM xoomas: thats realy weird
12:40 PM xoomas: how i can fill mybuffer more then its size declared
12:44 PM xoomas: i think i know why
12:44 PM xoomas: its becouse my buffer index also gets reset
12:46 PM xoomas: and yes i know my led not realy represents is data available or not :))
12:46 PM xoomas: its more like its even number or not ;D
01:30 PM xoomas: hmm but where i do wrap around? :))
01:31 PM xoomas: hmm somehow it works even if i send more then 256 bytes
01:33 PM xoomas: cehteh maybe more help? :)
01:51 PM cehteh: you just overflow your mybuffer into unused ram
01:51 PM cehteh: thats undefined behavior, as soon you add more variables it will crash ot do other strange things
01:54 PM xoomas: where do i take care of that?
01:54 PM Emil: cehteh: most
01:54 PM xoomas: in ISR?
01:55 PM cehteh: whenever you write to an array you should be damn sure you dont write out of bounds
01:55 PM cehteh: how you implement that is up to you
01:55 PM cehteh: ah, reads of course also
01:55 PM cehteh: in the simplest case you check the index each and every time against the array size
01:56 PM antto: on the xmega, my FIFOs are over 512 bytes, cuz i will eventually add bootloader
01:58 PM cehteh: how does that matter?
02:00 PM antto: when a tcp packet contains a data packet (some headers and footers) with 512-byte of a flash page, that immediately gets thrown onto a transmit FIFO ;P~
02:01 PM xoomas: while ( head < RING_BUFFER_SIZE ) { buffer[head++] = UDR; } head=0;
02:01 PM xoomas: something like that?
02:01 PM antto: wut
02:01 PM antto: xoomas why are you zero-ing the index?
02:01 PM xoomas: to not overflow
02:02 PM antto: uh
02:02 PM Emil: Is it a ring buffer?
02:02 PM xoomas: yes
02:02 PM xoomas: or i should do modulus/
02:02 PM antto: that doesn't look right to me ;P~
02:02 PM Emil: xoomas: don't
02:02 PM Emil: xoomas: don't use modulos
02:02 PM antto: what does "overflow" mean here?
02:02 PM Emil: modulus*
02:03 PM xoomas: then how to take care that its not overflow?
02:03 PM xoomas: :)
02:03 PM Emil: with an if statement
02:03 PM antto: xoomas think about the problem
02:03 PM antto: to write a chunk of code, you need to have a very clear idea what you want to be happening
02:04 PM antto: typically you have to have a problem
02:05 PM antto: you need to be able to describe it, and then, once your description is rich enough - the solution will probably pop up out of the fog
02:05 PM xoomas: im first time doing this ring buffer
02:06 PM antto: that's fine
02:06 PM antto: if anything isn't clear - ask
02:07 PM xoomas: with if it also not good
02:08 PM xoomas: https://pastebin.com/L1fqthim
02:08 PM xoomas: it works like up to 256 bytes now
02:08 PM xoomas: then its spits out like 256 same bytes
02:09 PM cehteh: and looses one byte each RING_BUFFER_SIZE bytes
02:09 PM antto: i think you missed an important aspect of the FIFO
02:09 PM antto: it's a circular buffer
02:10 PM xoomas: it is
02:10 PM antto: you can't just check "head" versus the "BUFFER_SIZE"
02:10 PM xoomas: but how i reset head
02:10 PM cehteh: https://pastebin.com/8FhZqJsp
02:11 PM cehteh: less code, less bugs :D
02:11 PM antto: ah, he was talking about wrapping the index around
02:12 PM xoomas: so i still can use if statement? :D
02:12 PM cehteh: also you need to check that the ringbuffer doesnt overflow (head runs into tail)
02:12 PM cehteh: you can/must use the if statement yes, but also you need to read UDR
02:12 PM cehteh: in your code you dropped that
02:13 PM cehteh: (when the else branch was choosen)
02:14 PM xoomas: with this code it acts exatly the same as with mine
02:14 PM xoomas: after 256 it womits ;D
02:14 PM antto: he said "overflow" and then he had code which looked like he wants to check if the head is above the buffer size, and if so - reject new data and clear the index
02:16 PM cehteh: my code?
02:16 PM cehteh: there are 2 cases, one is the wraparound, thats the normal thing in a ringbuffer
02:17 PM cehteh: if index>255 then index=0
02:17 PM cehteh: the other is the overflow, the ringbuffer can only hold 256 bytes
02:17 PM antto: can it? ;P~
02:17 PM cehteh: when you want to push the 257'th byte it will run into the tail, possibly overwrite that
02:17 PM Emil: bruh
02:18 PM Emil: if your ringbuffer is 256 bytes in length
02:18 PM cehteh: yes
02:18 PM antto: >:)
02:18 PM xoomas: its 32 byres
02:18 PM Emil: optimise
02:18 PM Emil: fucking
02:18 PM Emil: everything
02:18 PM Emil: :D
02:18 PM antto: both of your indecies are equal
02:18 PM cehteh: well RING_BUFFER_SIZE
02:18 PM cehteh: whatever
02:18 PM antto: unless you implement it a bit differently
02:18 PM cehteh: the point is that you'll overwrite data not yet consumed from the tail
02:19 PM cehteh: make it loosing data and incorrect reads
02:19 PM xoomas: but im consuming it faster
02:19 PM cehteh: so somehow you need to handle that
02:19 PM cehteh: yes thats good
02:19 PM xoomas: whole mcu time is just checking data
02:19 PM cehteh: but in programming you need to make damn sure that such wont happen
02:19 PM xoomas: how i can run it to tail
02:20 PM cehteh: for example when you put a _delay_ms(5000) in your code
02:20 PM cehteh: in the loop
02:20 PM cehteh: the loop sits there does nothing but the sender pushes happily data into your ringbuffer
02:20 PM xoomas: i put it there so i not flood termianl
02:20 PM xoomas: and cant see what is going on
02:20 PM antto: if head is 255 and tail is 0, then you have exactly 255 bytes of data which you can read().. now what happens when another byte gets added to the FIFO? head becomes 256? nope it becomes 0, and that results in fifo_is_empty
02:21 PM cehteh: its not about that 'you just now dont do it' .. programming is about exactness, you need to ensure that this will never ever happen, otherwise it will crash
02:21 PM antto: so, with this implementation, the FIFO size is N, but the capacity is N-1
02:22 PM cehteh: if you know that you never ever send faster, thats ok (like uart is pushed by some realtime clock, once a second a timestamp for example)
02:24 PM xoomas: im just missing something
02:24 PM xoomas: like now i sent 31bytes
02:24 PM xoomas: read all ok
02:24 PM xoomas: then sent only one
02:25 PM xoomas: and got back 256-32
02:25 PM antto: xoomas btw, both indexes (head and tail) need to wrap
02:25 PM xoomas: thats what im thinking
02:26 PM xoomas: so tail wraps in read funcion?
02:27 PM antto: after you increment or change the value of the index, it's a good idea to make sure it's valid.. by cheking it for range or just wrapping it
02:27 PM antto: ++index; if (index >= size) { index = 0; }
02:28 PM xoomas: im still thinking why here its ++index
02:28 PM antto: or with lazy modulo (slow): ++index; index %= size;
02:28 PM cehteh: xoomas: you shoud really implement a standalone ringbuffer instead this ad-hoc coding
02:28 PM xoomas: but not index++
02:28 PM xoomas: :)
02:28 PM cehteh: because later you need another instance for the sending queue as well and thats much easier to debug
02:28 PM xoomas: cehteh whats the point ?
02:28 PM antto: xoomas i write with pre-increment/decrement by default
02:28 PM xoomas: if i dont understand it well
02:29 PM xoomas: i can try implement on anything ;)
02:30 PM xoomas: but on ISR its head++
02:30 PM antto: if you're just doing "++index;" or "index++;" - then it doesn't matter which one you'll pick
02:31 PM antto: but if you're doing "buffer[index++]" or "buffer[++index]" or "while (index++)" etc.. then it *matters*
02:32 PM xoomas: so with buffer[++index] i get like "1"
02:32 PM xoomas: if index++ i get "0"
02:32 PM xoomas: ?
02:32 PM xoomas: both index started at 0
02:32 PM antto: buffer[index++] = val; <- this takes val and assigns it into buffer[index], then increments the index
02:33 PM xoomas: ah
02:33 PM antto: buffer[++index] = val; <- this increments the index, and then assigns val to buffer[index] (which has been just incremented)
02:34 PM cehteh: you can use preincrement or postincrement, but you have to do it correctly
02:34 PM antto: yes
02:34 PM cehteh: and, there arev prolly hundres of permutations but only one is correct
02:34 PM antto: i think i only use post-decrement when i loop over an array backwards
02:34 PM cehteh: you dont find it easily by try'n'error :D
02:34 PM cehteh: you have to understand how it works
02:35 PM cehteh: and this ringbuffer is rather a simple thing
02:35 PM xoomas: const uint8_t data = buffer[tail]; ++tail;
02:35 PM xoomas: this cant be like data = buffer[tail++]?
02:35 PM cehteh: yes you can do that, the compiler will optimize it
02:35 PM antto: it can
02:36 PM cehteh: const uint8_t data = buffer[tail]; tail = tail + 1;
02:36 PM antto: that too
02:36 PM cehteh: when you want it fully verbose
02:36 PM xoomas: then here it doesnt matter
02:36 PM xoomas: pre or post increment
02:36 PM antto: i prefer to increment on a sepparate line ;P~
02:36 PM cehteh: sometimes its a bit matter of taste, often writing verbose is easier to read (but more code)
02:38 PM antto: you can even tail += 1;
02:38 PM cehteh: at least dont try to do as much as possible in a single line, no one can read that and the compiler often optimizes well written verbose code better (because thats the common case and the people writing the compiler care for that more)
02:38 PM antto: yeah, we might write lots of stuff on one line here on IRC, cuz it's IRC
02:38 PM antto: but that doesn't always look good in actual code
02:39 PM xoomas: ok
02:39 PM xoomas: now it works again correct
02:39 PM antto: xoomas again, check the code i pasted last night, specifically void on_isr_rx() on line 189
02:40 PM antto: that function is what i have in my ISR
02:40 PM xoomas: uhm how to find that link again :))
02:40 PM antto: ignore the qrx_errs stuff
02:40 PM antto: http://paste.debian.net/hidden/f1923a76
02:41 PM xoomas: oh
02:41 PM xoomas: thats same debian
02:41 PM antto: yes, teh scary C++ code ;P~
02:41 PM antto: but the function is small
02:42 PM xoomas: who sayed not likes to write in one line? :D
02:42 PM xoomas: const SizeTypeRX iw1 = (rxiw+1) & iq_wrap(); //UART1_IQ_WRAP; // incremented
02:42 PM antto: that's because i declare it const
02:43 PM antto: if i drop the const i can write it on sepparate lines
02:44 PM antto: what this does is, creates a temporary "head" index that is incremented and wrapped around
02:44 PM antto: then it checks if that temporary head index would be equal to the tail index
02:45 PM antto: the logic here is "will head become equal to tail if i increment head?"
02:45 PM antto: ehm "will (head+1) equal tail?"
02:46 PM antto: if it does, that means that if we add another byte to the FIFO - the FIFO will go beyond its capacity
02:47 PM antto: in that case, i read UDRn and throw the value away, and count this as an error
02:47 PM cehteh: up to the application how to handle such error
02:48 PM antto: otherwise i read UDRn into the buffer, and re-use the temporary incremented head index to assign it over the current one
02:48 PM cehteh: complete reset, stop uart, go into some safety mode, just record the error, throw one entire line away, whatever works
02:49 PM antto: my FIFO doesn't understand what a "line" is ;P~
02:49 PM xoomas: i think ill never have that much data comming in
02:49 PM xoomas: im trying to do programmer for eerpoms
02:50 PM xoomas: atmega only need accepts comands
02:50 PM xoomas: those commands maybe can be with some kind check if transmision was ok
02:51 PM cehteh: at some point you need to send the data to be programmed into eeproms
02:51 PM cehteh: which may be bulky and eeprom writing might be slow
02:51 PM cehteh: hey you can implement flow control later, to make things more complicated :)
02:51 PM xoomas: like i2c eeprom accepts 16byte pages
02:51 PM xoomas: :D
02:52 PM xoomas: im thinkig do i need at all this ring buffer :))
02:52 PM antto: xoomas what is the page size of the eeprom?
02:52 PM xoomas: if i can make sure that my pc app never sends more data then avr can accept
02:52 PM xoomas: :D
02:52 PM antto: or are you writing byte-by-byte into it?
02:53 PM cehteh: xoomas: it could be done without too, like the ISR interrupt could write directly into the 'mybuffer'
02:53 PM cehteh: but that needs some rather careful programming to make it race free *and* not loose any data
02:53 PM antto: xoomas your PC app may be an innocent angel, but a noise burst on the cable may turn into a pile of "data" coming at your UART RX
02:53 PM antto: what's gonna happen then with your FIFO?
02:53 PM xoomas: if crc not ok
02:53 PM xoomas: reject
02:53 PM xoomas: :D
02:54 PM xoomas: if its more then pc ever sends
02:54 PM antto: crc is not 100% bulletproof
02:54 PM xoomas: reject
02:54 PM cehteh: such a rinbuffer, even if its only a few bytes saves you from a lot of problems and gives a bit headroom when you cant handle incoming data fast enough
02:55 PM Casper: the only bullet proof would be a triple retransmission with crc and parity, and even then there is a mathematical possiblity of corruption
02:55 PM xoomas: cehteh problem is that i dont have in head that kind of thinking like you guys do :)
02:55 PM xoomas: you think few steps ahead
02:55 PM cehteh: when you going to echo everything you send, then you can verify that as well, with or without CRC
02:55 PM xoomas: i think what i need to to ;D
02:55 PM xoomas: do*
02:55 PM antto: xoomas break down the problem into smaller chunks
02:56 PM cehteh: send data, check that the data is echoed back correctly, then send some kind of 'commit' (to execute some command or whatever)
02:56 PM antto: then break down those chunks into even smaller ones
02:56 PM cehteh: and the microcontroller answers that commit with some acknowlegement
02:56 PM cehteh: when you add CRC to that you should get some pretty solid system
02:57 PM * antto throws a magical symmetric corrupted byte at cehteh
02:57 PM cehteh: yeah shit happens
02:57 PM cehteh: but should be rather unlikely
02:57 PM antto: not 100%
02:57 PM cehteh: nothing is 100%
02:57 PM xoomas: atleast now this ring works again
02:58 PM xoomas: and im starting to get idea :))
02:58 PM antto: const float something = 100.f;
02:59 PM xoomas: its like pc putting bricks inside atmega and (which is interrupt driven) so it can add bircks easy without my knoweldge ;))
02:59 PM xoomas: and im in my code when have time take out bricks
02:59 PM xoomas: :
03:00 PM xoomas: need to make app that pushes more data then i can read
03:00 PM antto: if you busy-wait for the eeprom to be written, then that could take like 5ms
03:00 PM xoomas: to see how it handles that
03:01 PM xoomas: but i guess not good
03:01 PM xoomas: becouse i still not have antything to check for full ring
03:01 PM antto: for those 5ms you can get quite a bunch of bytes on your UART depending on the bitrate
03:01 PM antto: and if you don't have a FIFO, or if it's small enough - you're in trouble
03:02 PM xoomas: i2c write i think is 10ms
03:02 PM xoomas: if i remeber ok :D
03:02 PM cehteh: idea: use just as fast baudrate as you can write to eeprom :D
03:02 PM cehteh: little slower even
03:03 PM PsySc0rpi0n is now known as HelloShitty
03:03 PM cehteh: i debugged my utf8 lineediting with 50 baud or so, its nice when one can see how the terminal stuff is rendered on screen :)
03:03 PM xoomas: 5ms max
03:03 PM cehteh: 5ms is a lot
03:04 PM cehteh: what baudrate do you use? 9600?
03:04 PM xoomas: now 19200
03:04 PM xoomas: but crystal is not good
03:04 PM xoomas: cant use more now ;))
03:04 PM cehteh: more isnt better in this case
03:05 PM cehteh: since you need to handle all incoming data, the faster you make it, the more frequently you have to handle it
03:05 PM xoomas: how i can simulate more bussy mcu:))
03:05 PM cehteh: means you can do less other stuff inbetween
03:06 PM xoomas: with slower checks/reads
03:06 PM cehteh: delay
03:07 PM antto: if you also transmit, then you'd better use interrupt-driven transmit as i talked about earlier
03:07 PM antto: otherwise slow bitrate is bad
03:07 PM xoomas: delay in main while loop ?
03:07 PM xoomas: or delay in peek loop
03:07 PM xoomas: for now need to finish with isr rx
03:07 PM xoomas: :D
03:07 PM xoomas: then with isr tx
03:08 PM antto: i told you, if you need both, then it's probably a better idea to implement the transmit first
03:08 PM cehteh: too slow bitrate is bad, but 'just fast enough' is often the best choice
03:08 PM antto: because once you have it working, you can use it to help you while you implement the reception
03:09 PM cehteh: less interrupt load, and still get the job done
03:09 PM xoomas: i added 50ms mcu delay
03:09 PM cehteh: of couse when you have something which needs bulk data transfers (do you ever do that in avr?) then just fast enough might equal the fastest available :)
03:10 PM xoomas: now only recevei 26 bytes out of 90
03:10 PM xoomas: nop
03:10 PM cehteh: 50ms is a lot
03:10 PM xoomas: i done very very basics with data transfer
03:11 PM xoomas: 5ms
03:12 PM xoomas: and its handling no proplem :D
03:16 PM xoomas: i think its enought for today :) time to sleep
03:16 PM xoomas: thank you cehteh and antto
03:16 PM xoomas: :)
03:17 PM xoomas: gn8
03:22 PM antto: it's not enough! MOAR FIFOs! \o/
03:25 PM Tom_L: FE FIFO FUM
03:28 PM antto: MICROCHIP IS UBER SCUM
03:29 PM Emil: antto: truth!
03:35 PM antto: i just couldn't think of a better rhyme ;P~
03:35 PM antto: that's the first thing that popped into my mind ;P~
03:45 PM * Casper wonders if they will make a dip version of an atmega with a 12+bits adc, and a 1-2 DAC channel...
03:47 PM antto: Casper can't you glue an xmega onto an adapter? ;P~
03:47 PM Casper: there is some adapters of course, but meh
03:47 PM Casper: would be nice to have a native one :D
03:47 PM antto: sure, but i doubt
03:48 PM antto: take the xmegas while they're available
03:48 PM Casper: might be forced to move to pic...
03:49 PM antto: noooooooooo /o\
03:51 PM Emil: >PIC
03:51 PM Emil: Pls
03:51 PM Emil: just move to arm
03:54 PM Casper: dosen't arm require external parts like flash or ram?
03:58 PM Emil: wat
03:58 PM Emil: bro
03:58 PM Emil: no
03:58 PM Emil: :D
03:58 PM Emil: like 99% of all arms sold are self contained mcus
03:58 PM Emil: like avrs
03:59 PM Emil: I pulled that number out of my ass, it's probably even higher in reality
04:00 PM * antto puts that number back to its place
04:00 PM * antto washes his hand
04:00 PM antto: much mistake :~(
04:03 PM Ameisen: Ones on phones are not MCUs and are application processors
04:04 PM Ameisen: ARM MCUs often have data buses for external memory as well, which can be mapped into the address space
04:04 PM antto: xmega has that too
04:04 PM * antto is such an xmega fanboi
04:04 PM Emil: Ameisen: so?
04:04 PM Ameisen: yeah, but basically any ARM chip is still going to crush xmega
04:04 PM Ameisen: :}|
04:04 PM Emil: Ameisen: like I said, pretty much all ARMs sold are self contained MCUs
04:04 PM antto: duh, 8bit vs 32bit
04:04 PM Emil: that leaves out room for the cpu arms
04:06 PM antto: EKSMEGAH \o/
04:07 PM Ameisen: antto - yeah
04:07 PM Ameisen: but then add up the the ARM chips are usually cheaper than the AVR ones...
04:07 PM Ameisen: Emil - what about all of the ARM chips in cell phones
04:08 PM Emil: Ameisen: what about it?
04:08 PM Ameisen: I imagine they are a substantial portion of all ARM chips
04:08 PM Emil: Ameisen: how many ARM cores do you think a regular phone holds ;)
04:08 PM Emil: You think there's no other mcu on your phone?
04:09 PM Ameisen: the MCU on my phone is likely an ESP
04:09 PM antto: there is at least one mcu that deals with spying on you and sending data to the mothership
04:09 PM Ameisen: which is used for the modem
04:09 PM antto: maybe another one that mines bitcoins
04:09 PM Emil: Point is, mcus as a group far outweight cpus as a group in terms of volume
04:10 PM Emil: And usually those arm cpus can function as mcus
04:13 PM Ameisen: I'm suprised there are no obscenely powerful MCUs
04:13 PM antto: i think i read somewhere something about like "in every modern computer processor, there are a bunch of mcus inside that do different small things"
04:13 PM Emil: there are
04:13 PM Emil: a lot
04:13 PM Ameisen: Such as?
04:14 PM Emil: F7, A9, A11
04:14 PM Emil: and whatever
04:14 PM Emil: Ameisen: exactly
04:14 PM Emil: antto: *
04:14 PM Ameisen: You think something that is ~200MHz is obscenely powerful?
04:14 PM Emil: Ameisen: compared to your regular avr
04:14 PM Emil: Ameisen: also A11 goes to gigahertz and above a lot
04:15 PM antto: don't these have GPUs and shizzle
04:15 PM Emil: some
04:15 PM Emil: cortex-a
04:16 PM antto: the olinuxino boards have some ARM chip which have gpus on them
04:16 PM antto: "mali" something
04:16 PM Emil: a15
04:16 PM Ameisen: Are the A9/A11 MCUs?
04:16 PM Ameisen: those are application CPUs
04:16 PM Emil: Ameisen: what is your definition of a mcu
04:16 PM Ameisen: embedded memory. No external dependencies for function.
04:17 PM Emil: then they are mcus
04:17 PM Emil: also all x86/x64 nowadays are just MIPS that process x86 bytecode :D
04:17 PM Emil: or so
04:17 PM Ameisen: microcode has been around for decades
04:17 PM Emil: yes
04:17 PM Ameisen: there are plenty of x86 instructions that are still hardwired.
04:18 PM Ameisen: the common ones, generally
04:18 PM Ameisen: still nice to have the x86 frontend, since it's a very compressed ISA. Nicer on the icache
04:19 PM Ameisen: The A9/A11 have embedded RAM?
04:19 PM Ameisen: I know they have large caches, but I was under the impression that they relied on a memory bus.
04:25 PM Xark: Ameisen: x86 is not really that great an encoding for space (especially 64-bit). See https://imgur.com/a/Yd0bO
04:25 PM Xark: Supid stuff like wasting single byte opcodes on AAA etc. :)
04:26 PM Ameisen: What was the compiler and compiler settings?
04:26 PM Xark: That was all done with gcc, I believe (and normalized options).
04:27 PM Ameisen: normalized doesn't mean much when you're comparing risc to cisc
04:27 PM Ameisen: risc will still have simple instructions. x86 doesn't generally get more dense instructions without higher optimization levels
04:27 PM Ameisen: that, and it usually depends if you're optimizing for size or not, also, since it'll often generate larger, faster code.
04:28 PM Xark: This was a pretty nicely done study.
04:28 PM * Xark links source PDF https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.pdf
04:29 PM Xark: We measured the efficacy of RVC at compressing RISC-V code by comparing the static
04:29 PM Xark: code size and dynamic instruction fetch traffic of RVC and RISC-V versions of several programs:
04:29 PM Xark: the SPEC CPU2006 benchmark suite [91], nominally representative of workstation
04:29 PM Xark: workloads; Dhrystone [104], a historical synthetic benchmark of questionable relevance but
04:29 PM Xark: outsized popularity; CoreMark [29], an embedded systems benchmark; and the Linux kernel,
04:29 PM Xark: version 3.14.29 [94].
04:30 PM Ameisen: The Linux Kernel's size is going to change dramatically from arch to arch because of the completely different support code.
04:30 PM Ameisen: it's not a 1:1 comparison
04:32 PM Xark: Ameisen: I think it is pretty representative.
04:32 PM Xark: But bottom line, x86 is not that great for code size.
04:32 PM Xark: (Nor AARCH64)
04:33 PM Emil: Ameisen: that would work if x64 had considerably smaller size
04:33 PM Ameisen: Also... since when does MIPS have compressed instructions
04:34 PM Emil: Ameisen: because it's been around longer and optimised better for
04:34 PM Ameisen: MIPS has a constant instruction size.
04:34 PM Emil: but since ARM has smaller size there, also, ...
04:34 PM Xark: Ameisen: Google it (but never went far - was to compete with Thumb)
04:34 PM Ameisen: oh, their special instruction set?
04:34 PM Ameisen: I forgot that even existed
10:46 PM nuxil: good morning fellow 8biters.
11:16 PM Casper: no
11:16 PM Casper: not morning!
11:16 PM Casper: it's barelly night!
11:18 PM nuxil: heh. where are you? time is 06:17 here
11:19 PM Casper: 00:20 here
11:19 PM nuxil: usa east coast ?
11:20 PM Casper: NO!
11:20 PM Casper: trump is not our president
11:20 PM nuxil: idk. honululu then :p
11:21 PM Casper: we have a PM instead
11:21 PM Casper: sitting on top of the usa
11:21 PM Casper: and it'S fricking snowing again! grrrr
11:22 PM Casper: atleast they forecast only 4"
11:22 PM Casper: or I guess you prefer 10cm
11:22 PM nuxil: so cannada, halifax area+
11:22 PM nuxil: ?
11:22 PM Casper: not quite, and not at all!
11:22 PM nuxil: looking at my globus trying to see which contry has -6 hours timedifference :p
11:23 PM Casper: canada, not cannada :D
11:23 PM Casper: and more like, montreal
11:23 PM nuxil: :D
11:24 PM nuxil: well, snow isnt something new to me. i live in north norway so i know all about snowy winters :)
11:24 PM Casper: http://www.quebec511.info/Carte/Fenetres/camera.ashx?id=3351&format=mp4 <=== roads look good still
11:26 PM nuxil: so big roads :D
11:26 PM nuxil: this is the road into my island :D https://www.vegvesen.no/Trafikkinformasjon/Reiseinformasjon/Trafikkmeldinger/Webkamera?kamera=100105&zoom=7
11:26 PM nuxil: lol
11:28 PM Casper: we have simmilar ones too! we avoid them :D
11:28 PM day__ is now known as day
11:28 PM Casper: https://www.google.ca/maps/@45.5226837,-73.4705063,7203m/data=!3m1!1e3 <-=== my city
11:28 PM Casper: and if you look on the right, you can see an airport
11:29 PM Casper: it is the oldest (first) civilian airport in canada :D
11:29 PM Casper: with a shitton of idiots all around the airport
11:29 PM nuxil: hehe
11:29 PM Casper: in operation since 1928
11:30 PM nuxil: you speak frensh ?
11:30 PM Casper: no, I speak french :D
11:30 PM nuxil: the names of the places on that googlemap is all in frensh.
11:31 PM Casper: frenCh
11:31 PM * Casper slaps nuxil
11:31 PM nuxil: haha
11:32 PM nuxil: "fransk" is whats its called in my language :)
11:34 PM Casper: français <=== in french, duh
11:46 PM Casper: https://www.google.ca/maps/@45.5137518,-73.4839161,3a,75y,300.05h,75.54t/data=!3m6!1e1!3m4!1sKN-E1qJVSryqSeIAjvpfdw!2e0!7i13312!8i6656 <=== our small streets...
11:51 PM Casper: oh I never finished my story about the airport neighbour idiots...
11:51 PM Casper: they tried to make the airport close because it was too loud...
11:51 PM Casper: ... they are new owners...
11:51 PM Casper: the airport is quite older
11:53 PM nuxil: tell them to move. they knew there was a airport there before they bought
11:53 PM Casper: that's basically what the city said, they still complain and want compensation, lol
11:53 PM nuxil: lol