#avr Logs

Sep 05 2017

12:07 AM enh: I read data from four sensors and store each value in a ten element array which calculates the average and std dev of each data element. four sensors times 3 values each = 12 data coordinates, each with a 10 element array, times 4 bytes. This takes more than 400 bytes of memory. The most amazing thing is that, if I say that data is made of floats, it takes almost the same computing power than if the data is registered as int
12:09 AM enh: 32_t.
12:12 AM enh: The blinking frequency is the almost the same
12:21 AM enh: The calculations are based on typedef float DataType. All arrays are of DataType. Dunno what could be casting integer on the code
12:22 AM _ami_: enh, i think there is no need to have class for blinking?
12:22 AM _ami_: you can have a class for pins and have toggle() function to do the job
12:23 AM enh: A class for pins is a good idea.
12:24 AM enh: blinking has its own class just to keep the code organized. There are some variables that control blinking that would be messing around if outside of their class
12:25 AM _ami_: enh, https://pastebin.com/vEaZZV5k <-- my current implementation for stm32f1 chip
12:25 AM enh: Need, indeed, the is not.
12:26 AM enh: looks very good, _ami_
12:26 AM _ami_: pin p(GPIOC, GPIO13);
12:26 AM _ami_: p.setMode(PinMode::OUTPUT_50MHZ, PinConfig::OUTPUT_PUSHPULL);
12:26 AM _ami_: while (1) { p.toggle();
12:26 AM _ami_: time::delay(1000); }
12:27 AM enh: practical
12:27 AM enh: i like it
12:28 AM enh: much better that macros
12:28 AM day__ is now known as daey
12:28 AM enh: are you from India, _ami_?
12:40 AM enh: much better your code than macros, I mean
01:43 AM _ami_: enh: yeah
02:24 AM Jartza: rue_shop3: turn your attiny85 into vga controller for your projects
02:25 AM Jartza: silly question
02:59 AM rue_bed: heh
03:00 AM rue_bed: how small are vga to composite converters?
03:00 AM rue_bed: what if I want overlays?
03:02 AM ohsix: if something does both it isnt' likely to be much larger because of it
03:03 AM ohsix: you can do vblank&hsync tracking for text
03:11 AM rue_bed: hmm
03:11 AM rue_bed: text overlay would be cool
11:25 AM pcbSebb: i have a stange problem... i have a device that is connected to a pcb that i made, the device spits out 8 bytes of data continuously with a delay of maybe 50ms... I read the the 8 bytes into a buffer and everything work fine.... BUT after like 5 minutes it start to miss bytes and finnaly after like 15 minutes, it wont receive anything, if i restart my board and wait like 10min it works again. i use an external crystal 16Mhz.... any idea
11:25 AM polprog: desynced transfter
11:26 AM polprog: imo, do yoy use any kind of a synchronization system?
11:27 AM pcbSebb: no... i dont have any control over the other device, maybe i should try to use interrups to catch the data insted? right now i check if there is any new data, then fill the buffer, works for a while but...
11:29 AM polprog: you are getting a very characteristical behavior, the data received gets garbled more and more over time
11:29 AM polprog: you need to reset the timing system every time you receive data
11:30 AM pcbSebb: but the thing is that if i restart my board and try again, it wont work... i´ll have to wait for a while, feels like a heat issue or something... nothing get seriously hot though.
11:30 AM polprog: an interrupt may be a good solution, but that depends on how you detect that there's data
11:35 AM pcbSebb: the thing is that if i powercycle all hardware it won´t immediately start working again, i need to wait for a while.... really strange!
11:40 AM LeoNerd: How many STOP bits?
11:40 AM LeoNerd: I often like to use 2 STOP to give the receiving UART time to resynchronise and catch up
11:40 AM LeoNerd: Especially at faster baud rates
11:42 AM pcbSebb: the baudrate on the other device is fixed to 9600bps, so that is what i´m using as well, i´ve set up my comms with 1 stop bit, does it make a different if i change my reciver side to 2 stop bits?
11:43 AM LeoNerd: Ah; at 9600 I doubt that'd matter
11:43 AM LeoNerd: That's slooooow. Receiver should have loads of time to catch up
11:43 AM pcbSebb: yes, i think so too...
11:44 AM pcbSebb: but the behaviour is wierd, when i get to work tomorrow, start everything up it will run perfect for like 10 mins, then i need to shut it all down for 10min, then i can start it again.
11:46 AM pcbSebb: i need to get the scope and analyzer out tomorrow and dig deep,..
11:51 AM antto: my favourite situation is when the problem doesn't occur when you attach a scope x_x
11:58 AM polprog: we should make a circuit that does this
11:58 AM polprog: lol
12:01 PM Lambda_Aurigae: pcbSebb, running the usart in 1x or 2x mode?
12:02 PM Lambda_Aurigae: what is your UBRR set to?
12:03 PM Lambda_Aurigae: and, you have a crystal connected, but are your fuses set to use the crystal?
12:05 PM Lambda_Aurigae: a scope or logic analyzer connected would help a lot.
12:06 PM Lambda_Aurigae: also, if you have a can of fake compressed air stuff, invert and cool the chip and see what happens.
12:28 PM polprog: wow, http://electricstuff.co.uk/glassadc.html
12:32 PM pcbSebb: back... UBRR set to 103 running 16Mhz, yes fuses set to external crystal.
12:33 PM pcbSebb: yes, i think i can of compressed air would be a good thing, but the atmega is not even hot... it seems to be some kind of heat related problem, but things are not hot...
05:07 PM dsalychev1: Hi, guys. Is there any specific debugger/program/hardware you usually use to check your MCU-based device? Do you use timing diagrams, say, to check how two MCUs interact with each other, for instance?
05:09 PM JanC_ is now known as JanC
05:30 PM alx741_: dsalychev1: having a UART connection back to a computer to print debugging data is simple and gets you pretty far
08:53 PM enh: hi