#avr Logs
Jan 23 2018
#avr Calendar
12:02 AM rue_: its part of the compile process
12:05 AM rue_: Ithink its one of the intermediate binaries it makes and then decomposes
01:28 AM Jartza: morning
01:28 AM Jartza: Makefiles are so 80's
01:28 AM Jartza: meson + ninja <3
01:32 AM rue_bed: did you do a setup for stm32?
01:33 AM rue_bed: and do meson and ninja just use 18 layers that result in a makefile it runs?
01:36 AM polygon: hi
01:36 AM polygon: so i will need ta moke a xil or wiggler dongle to parallel port
01:37 AM polygon: i have a dapa but it is only for avr
01:39 AM Jartza: rue_bed: no, meson doesn't create makefile
01:40 AM Jartza: because makefiles are so 80's
01:40 AM Jartza: I use meson for lot of builds
01:40 AM Jartza: avr, kinetis, stm32, nxp, atmel sam...
01:43 AM Jartza: I think debian is moving towards meson as build system, and so is yocto
01:49 AM _ami_: i like meson too.
01:49 AM _ami_: although it needs more documents. but its alright
01:53 AM polygon: What is your opinion on directly driving this with the pins of an arm :> https://cdn.sos.sk/productdata/34/47/0369a0f3/lcd-4-0-13-de-119-rs-20-7-5-1.pdf
01:55 AM Jartza: guy who created meson is my colleague :)
01:55 AM Jartza: so I might be a bit biased
01:57 AM rue_bed: so you have a meson, .... script I can compile & upload from console?
01:58 AM Jartza: I think meson documentation have improved over time, but surely there's still room for improvement
01:58 AM Jartza: but meson has been gaining a lot of love lately, I bet the documentation will improve further
01:58 AM Jartza: http://mesonbuild.com/Manual.html
01:58 AM rue_bed: so you have a meson, .... script I can compile & upload from console?
02:00 AM Haohmaru: oh dejavu.. a glitch in the matrix
02:03 AM Jartza: rue_bed: your question doesn't make sense
03:20 AM Aslak3_ is now known as Aslak3
04:31 AM polygon: i have an idea dynamically adjusting the cutting power of a hotwire foam cutter according to linear velocity, what is your opinion?
06:16 AM polprog: rue_bed: wow, thanks for that code! and why the hell it was not indexed by search engines!
06:16 AM polprog: good to know my rant came out in something usable to me :P
06:16 AM polprog: and that example with number juggling was crap
06:17 AM polprog: rue_bed: is gpio_set_mode a macro or a function in opencm3 ?
06:36 AM _abc_: Hello. Has anyone gotten an atmega serial connection with properly working xon/xoff handshake going under linux? I did some work and I saw it overruns the buffers with abandon, the linux side is very slow to react to xon/xoff tokens using usb to serial ...
06:36 AM _abc_: ... cnverters (pl2303 or such)
06:37 AM _abc_: *converters
06:38 AM _abc_: Hm, it's a bit early for North America, I'll wait a little longer for answers :)
06:38 AM polprog: what do you already have?
06:39 AM _abc_: I have working xon/xoff code which works fine avr to avr but not avr to linux host
06:40 AM polprog: so the avr side is ok?
06:40 AM _abc_: I can control the buffer sizes on the host side, but I would prefer to read more about it
06:40 AM _abc_: yes
06:40 AM _abc_: So this is 50% about settings and buffer sizes and 50% about host settings
06:40 AM polprog: what do you use in linux for serial?
06:41 AM _abc_: I tried several things, starting with minicom, screen, tio compiled from source (I have full control) etc
06:41 AM _abc_: currently using cp210x 3-2.4:1.0: cp210x converter detected
06:41 AM _abc_: ttyUSB0
06:41 AM _abc_: Has anyone got a page on this? Maybe with success?
06:42 AM Emil: you need to enable xon/xoff with a stty call or ioctl
06:42 AM _abc_: really?
06:42 AM polprog: have you tried picocom? it has selectable flow control modes
06:42 AM _abc_: polprog: oh all of these have it
06:42 AM polprog: minicom was broken for me
06:42 AM Emil: Sorry, meant tcsetattr
06:42 AM _abc_: tio is easy to mod because it is a simple C program, I compiled from source
06:42 AM Emil: instead of ioctl
06:43 AM Emil: _abc_: comeone, of course you have to enable flow control separately :D
06:43 AM Emil: or ask for it
06:43 AM _abc_: Emil: fyi a more interesting question is, how does one define unbuffered (at hw fifo level) serial io
06:43 AM polprog: _abc_: https://www.cmrr.umn.edu/~strupp/serial.html
06:43 AM polprog: try this
06:43 AM Emil: https://emil.fi/d/serial.c
06:44 AM _abc_: Yeah, looks like I need to read the cp210x kernel module source and see if it takes and fifo params
06:44 AM _abc_: Emil: https://emil.fi/d/serial.c secure connection failed
06:44 AM Emil: _abc_: look at struct ermios
06:44 AM Emil: _abc_: upgrade your fucking tls support bro :D
06:44 AM _abc_: Emil: really, the other progs already do it
06:44 AM Emil: I only accept TLSv1.2 and TLSv1.3
06:46 AM Emil: termios*
06:47 AM _abc_: https://github.com/torvalds/linux/blob/master/drivers/usb/serial/cp210x.c
06:47 AM _abc_: there are 2 layers of problems: normal serial programming latency due to buffered io and usb introduced latency/buffer size
06:47 AM _abc_: I would like to nail a solution which requires NO changes in the host, by defining a large enough buffer in the avr
06:48 AM _abc_: turns out with 128 char buffer and issuing xoff at 64 the buffer still overruns.
06:49 AM Emil: Why not hardware?
06:49 AM polprog: have you actaully checked that xoff is sent as the 64th byte>
06:49 AM polprog: ?
06:54 AM Emil: _abc_: bruh, you do realise that if you have a complete buffer to write out the drivers attempt to max the packet size, usually at least 64 bytes. If you want to use software flow control your driver needs to examine every single byte in and out to check for xonn/xoff or you must do it yourself
07:07 AM _abc_: Emil: the code does that on avr and work
07:07 AM _abc_: s
07:07 AM _abc_: polprog: yes
07:07 AM _abc_: polprog: there's usb latency involved too
07:08 AM _abc_: I'm using 9600 for testing which is quite slow, but I am hoping to get to 115200 later.
07:08 AM _abc_: Setting a MUCH lower speed (1200) makes it work flawlessly
07:08 AM Emil: _abc_: yes, but on a linux machine you a) need to ask for it from the driver/interface or b) do it yourself
07:09 AM _abc_: Basically the host takes a while to obey an XOFF
07:09 AM _abc_: Emil: no I need to use the settings of a default comms program which will be used with this device
07:09 AM Emil: _abc_: yes, make a simple stty call
07:10 AM Emil: Like I already said
07:10 AM _abc_: No, you will read what I wrote. I need to make an avr side xon/xoff serial code which works with unmodified existing known to work serial terminal programs on linux
07:11 AM Emil: alrighty, be a fucking retard then
07:11 AM _abc_: So, in https://github.com/torvalds/linux/blob/master/drivers/usb/serial/cp210x.c , there are no obvious serial buffers I can see besides the usb transaction buffer itself
07:11 AM Emil: sigh
07:11 AM _abc_: Emil: dude, when you answer a question try to read the question.
07:11 AM Emil: or
07:11 AM Emil: if you'd ever consider it
07:11 AM Emil: you are too stuck up in your ass to listen to what I say
07:11 AM _abc_: Emil: rephrased: I need avr side code, not host. This is #avr. Stay on topic, please.
07:12 AM Emil: _abc_: there is nothing AVR can do about it
07:12 AM Emil: if you want software flow control you need to enable it in your serial terminal program, usually by using stty
07:13 AM Emil: and also
07:13 AM Emil: lol
07:13 AM Emil: "stay on topic"
07:13 AM Emil: and you are talking about cp2102 drivers
07:13 AM Emil: fuck off, mate
07:18 AM _abc_: Yeah, I am trying to suss out what the buffer size is in them, as a clue
07:18 AM Emil: Usuaully 64 bytes
07:18 AM _abc_: relevant bits in generic.c -- getting closer
07:19 AM _abc_: No, it is not "usually" and it is not "64"
07:19 AM _abc_: uart fifos are at least 16 bytes and can be as much as 256
07:19 AM _abc_: usb is yet another thing and the kernel serial buffering comes on top of it
07:19 AM Emil: full speed usb packet sizes are usually 64 bytes
07:19 AM _abc_: I should look at a linux fax program which probably does the right thing, fax is symchronous and does not tolerate any lost bytes
07:19 AM Emil: irrelevant what is in the device buffers
07:20 AM _abc_: I know, thus 128 buffer with high water mark at 64, tried 40, same outcome
07:20 AM _abc_: Works 9 out of 10 times, 10th overruns
07:20 AM Emil: bro.
07:20 AM Emil: If you have full buffers
07:20 AM Emil: they send 64 bytes all the fucking time
07:21 AM Emil: and after that check what's arrived
07:21 AM _abc_: Yeah so I should try throttling at 16 and set buffer to 148 oe what
07:21 AM _abc_: In theory there should be a way to make the driver 'expedite' sending without issuing a flush after each byte on the host. Because doing the flush after each byte would "fix" it but is a host side fix I do not want
07:23 AM Emil: Wh is this so hard for you to understand. Your AVR can do absolutely nothing about this.
07:24 AM Emil: It's more likely that your avr code handling data input causes your overruns instead of anything else
07:25 AM _abc_: https://github.com/torvalds/linux/blob/master/drivers/usb/serial/safe_serial.c some clues
07:25 AM polprog: smack a leb bar on a port and make it display your buffer pointer every time
07:25 AM _abc_: Emil: then why does it work avr to avr
07:25 AM polprog: so hard to debug a single value
07:26 AM _abc_: polprog: I know it overflows, I intrumented it, it issues the proper message and stops when overrun
07:26 AM Emil: _abc_: because avrs are deterministic
07:26 AM _abc_: Once out of 10 or so full buffers, and no, not deterministic, it appears to depend on host load. The host takes longer to obey the XOFF when loaded.
07:26 AM _abc_: *instrumented
07:26 AM Emil: _abc_: learn to read
07:27 AM polprog: wow linux takes longer to so stuff when its under load
07:27 AM Emil: polprog: who would have guessed
07:27 AM _abc_: certainly but here we are talkng about 1 byte per msec at 9600, so 20msec relay is 20 extra bytes in the buffer, after the 64 mentioned by Emil are already in, once or even twice.
07:28 AM polprog: _abc_: you could do char-by-char transmission, program echo on the avr and make your sending loop wait for every echo
07:28 AM _abc_: Fyi better serial devices than this crap usb adapter handle the xon/xoff in hw, so they react fast, without sw intervention, as they do with hw rts/cts handshake
07:28 AM _abc_: polprog: yes, but, again, that is a host based solution
07:28 AM polprog: also, tcdrain() waits until the sending buffer is empty. useful function
07:28 AM polprog: _abc_: well the host is the problem i believe
07:29 AM _abc_: Right now, looking for avr side only solutions. I know how to fix it on the host, don't worry.
07:29 AM _abc_: I find it slightly strange that nobody ran into this before
07:29 AM _abc_: Sending copious amounts of data to an avr over serial is a common problem,
07:29 AM _abc_: 3d printers etc
07:29 AM Emil: Because it's probably pebkac
07:29 AM _abc_: Emil: you have a not so nice attitude today, I'll just pretend I am not reading what you write, ok?
07:30 AM Emil: _abc_: I find it strange that you are not acknowledging that there is nothing you can do about this avr side
07:30 AM Emil: Also, if you transfer lots of data through a serial port
07:30 AM Emil: you have a protocol for it
07:31 AM _abc_: Yes, you either use a protocol, or handshake, seldomly both nowadays.
07:31 AM Emil: no
07:31 AM Emil: handshake does not protect you against lost data
07:37 AM _abc_: Okay, so the simple answer is: cp210x does not completely implement xon/xoff handshake, that is the correct answer
07:38 AM _abc_: This was gleaned from reading the code.
07:41 AM _abc_: Right, so we'll discuss some kernel driver things where appropriate, not here.
07:41 AM _abc_: Meanwhile, no more xon/xoff time wasting on avr since the avr side works fine.
07:41 AM Emil: You don't have to but it's still fine here as long as it doesn't eat everything
07:41 AM _abc_: Emil: indeed it does not protect but you have to start somewhere and the start idea was to limit send data from the host while the slow avr sorts it
07:42 AM _abc_: Fyi lage makers like cisco still to this day implement xmodem in boot sectors/recovery mode on $50k routers in despite of all possible hw assistance precisely because that is a limited-buffer-size (128 or more) sending protocol which every serial ...
07:42 AM _abc_: ... terminal program can handle.
07:43 AM _abc_: Thanks for insights, and the handholding ;)
07:43 AM _abc_: Especially Emil
07:44 AM Emil: Glad you got it solved
07:45 AM polprog: i should look at [xyz]modem
07:47 AM polprog: already back :P?
07:47 AM _abc_: update: per https://github.com/RishiGupta12/SerialPundit/tree/master/drivers/cp210x-silicon-labs , very new (kernel 4.x?) cp210x drivers under linux DO support xon/xoff fully. I use an older kernel
07:53 AM _abc_: btw Emil, the complete driver does also mention the buffer sizes, depending on chip, 280 or 500 bytes.
07:59 AM polprog: should i go do some shopping or not
08:04 AM Emil: YES
08:10 AM polprog: allright
08:10 AM polprog: i shold go out more anyway
08:10 AM polprog: cya
09:18 AM polprog: this was a good idea
09:19 AM Emil: share it
09:20 AM polprog: i took a trip to the city center to buy some stuff
09:20 AM polprog: db9 cables
09:20 AM polprog: and stuff
09:20 AM rue_: db9 wow
09:21 AM rue_: I throw so many of those out..
09:21 AM Emil: rue_: haha same
09:21 AM Emil: and then someone buys them :D
09:21 AM rue_: polprog, how much did you pay?
09:23 AM polprog: 12 pln for 1.5m2
09:23 AM rue_: is that more or less than a bar of gold pressed latinum?
09:55 AM polprog: sorry my phone died, its -6 C outside ;)
09:55 AM polprog: its 3.5 bucks
11:55 AM day: normal gpios are open drain. i.e. they can pretty much only sink current. Are the PWM ports in PWM mode differently?
11:57 AM Casper: does anyone have experience with ntfs reading? need to do data recovery, and the hd is way too slow to let the normal recovery process go... need to 'manually' recover...
11:58 AM day: Casper: can you dd the drive onto a faster one?
11:58 AM polprog: Casper: afaik NTFS is totally closed and even the linux drivers are not really "sure"
11:58 AM nuxil: day, go into your datasheet. section 15 or something, I/O Ports. you should see a block diagram of how the output looks like
11:58 AM polprog: id say just dd it to another drive
11:58 AM day: yeah the linux one are reverse engineered. i think they are considered save these days though
11:59 AM day: nuxil: thanks. i wasnt sure where to look for that. i thought the opendrain design is fix so to speak
11:59 AM Casper: day: eta: 100 to 300 days
12:00 PM day: Casper: i was suggesting to simply dd the drive onto an ssd
12:00 PM Casper: day: the drive has failed, extremelly slow, insanelly slow
12:00 PM Casper: 100 to 300 days ETA to copy it
12:00 PM Casper: hence the manual parsing
12:01 PM day: you only need a few specific files?
12:03 PM Casper: yes
12:03 PM Casper: so far, all tools failed to do just that
12:03 PM Casper: there is some failed sectors in both the main file table and the backup
12:04 PM Casper: so I was hoping to figure out both the main and backup MFT and manually mix to follow the trace up to the single file I need
12:04 PM Casper: few MB :D
12:05 PM nuxil: send it in to Ibas :p
12:13 PM day: nuxil: i dont find any driving specifics in the datasheet
12:13 PM day: driver*
12:14 PM nuxil: what chip?
12:14 PM day: pick one. im looking at the atmega16u4 datasheet atm.
12:14 PM day: i doubt that stat is going to vary much between the atmegas
12:15 PM nuxil: https://gyazo.com/aa43928859651bd969a0ab720521040b
12:15 PM nuxil: you dont have that ?
12:15 PM day: ive seen the upper one in chapter 10
12:16 PM day: yeah ive seen the 2nd one as well
12:17 PM day: but the diagram says 'general digital I/O' which isn't what PWM is.
12:17 PM day: theres a similar diagram called 'Alternate Port FUnctions"
12:17 PM nuxil: the internal building blocks of the chip dosent end. besides. pwn is in a way general. since its just 0/5v
12:18 PM day: yes. but i thought its 0V/ Vcc via the pullup. which i dont think it is
12:28 PM nuxil: why do you think that ? all the diagram blocks i see shows a a fet with a pullup.
12:31 PM nuxil: PUD ?
12:34 PM Emil: day: wtf
12:34 PM day: because I've seen a few simple PWM based boost circuits which drive a N-Channel FET directly with the PWM output, the current that flows through the pullup resistor shouldnt be sufficient, should it?
12:34 PM Emil: are you saying that gpio on avr are open drain?
12:34 PM Emil: what the fuck got that into your mind
12:35 PM Emil: the gpio on avr are push-pull, with additional optional enabled pull-up resistors in size around 30k
12:35 PM Emil: if your fet is low capacitance then 30k is more than enough to drive it
12:36 PM Emil: and it's mostly a high frequency issue
12:36 PM day: now im totally confused :/
12:36 PM Emil: pwm is nothing but hardware control on the output stage
12:37 PM day: i thought you can either pullup an I/O output through its pullup resistor, or pull it down through a fet to gnd. (the later one allows more current to flow, and potentially damage the port)
12:37 PM day: thats my understanding of the I/O's
12:38 PM Emil: lol
12:38 PM Emil: bro
12:38 PM Emil: how
12:38 PM Emil: top kek
12:38 PM nuxil: read sectuib 15.2.3 Switching between input and output :p
12:38 PM nuxil: *section
12:38 PM Emil: nuxil: on an avr? You really though so
12:38 PM Emil: all my keks
12:38 PM Emil: why can't I hold all these keks
12:39 PM nuxil: Emil, was for day :p
12:39 PM day: not sure what is funny here
12:39 PM Emil: https://i0.wp.com/www.embedds.com/wp-content/uploads/2010/10/inside_AVR_IO_port.jpg?resize=468%2C371
12:39 PM Emil: day: * meant day with my question
12:40 PM Emil: day: it's funny that you thought IO was only through a resistor :D
12:40 PM Emil: or to ground
12:40 PM day: o.0 and?
12:40 PM day: its not like im boosting with my superior knowledge
12:40 PM day: am i?
12:40 PM Emil: Not sure if you are trolling
12:41 PM Emil: or if I'm just missing something
12:41 PM day: the later
12:41 PM Emil: the io is push-pull with optional pullup
12:41 PM Emil: see the attached image
12:41 PM Emil: linked, above
12:43 PM day: i wonder what made me believe they are open-drain :/
12:55 PM polprog: i added a db9 rs485 port on the driver pcb
12:58 PM day: i blame polprog D: 2017-11-23 20:27 < polprog> it's open drain
12:58 PM polprog: what?
12:58 PM day: in reality he was refering to a rtc chip and not to the attiny, which i missed :P
12:58 PM polprog: ;)
12:58 PM day: that was the reason i thought they are open-drain :^)
01:00 PM Tom_L: it's still his fault
01:00 PM day: #1 it's never your own fault
01:00 PM polprog: rule 1 users lie
01:00 PM polprog: rule 2 its always dns
03:15 PM polprog: got "flow control" working in my 485 rig
03:15 PM polprog: DTR low = transmitter enable. it was rts before but minicom can toggle dtr so its more conveinient
03:24 PM polprog: termios is sweet
03:27 PM Emil: polprog: no
03:27 PM Emil: bad
03:27 PM polprog: no
03:27 PM polprog: sweet
03:27 PM Emil: what it can do is required and mandatory to have
03:28 PM Emil: but the api ic käääänssser
03:28 PM polprog: well, i wrote one or four helper functions
03:28 PM polprog: for wiggling dtr/rts
03:28 PM polprog: https://www.cmrr.umn.edu/~strupp/serial.html#3_1_5 this guide is great tho
03:28 PM polprog: and one to open the serial port
03:28 PM polprog: ill post the code later
03:28 PM polprog: when its totally done
03:31 PM polprog: i should by a modem
03:31 PM polprog: buy*
03:33 PM polprog: actaully im using a mix of ioctl (for line wiggling) and tcsetattr etc
03:39 PM polprog: i could replace tcdrain with ioctl(fd, TCSBRK, 1) i guess. or just keep tcdrain
03:39 PM polprog: this is quite fun actually
03:39 PM polprog: making linux like a big microcontroller
03:40 PM polprog: i should try paralell port later :)
04:17 PM day__ is now known as day
04:40 PM nuxil: Why does pizza come in a squar boxes, but is made like a circle and eaten in triangles :E
04:47 PM wondiws: nuxil, clever, nice for a geometry exercise
04:47 PM nuxil: :)
04:50 PM nuxil: got my 50 UV leds i ordered on ebay today, time to make a uvbox soon
04:51 PM nuxil: heh. i dont know how they do it in china. i have to pay more for a post stamp here than i paied for these 50 leds + shipping
04:53 PM Emil: nuxil: because of packagin
04:54 PM Emil: circle/circular packagingis hard
05:14 PM nuxil: so "#prama once" is a none standar thing but widly supported. whats the bennefits of doing #pragma one \ #ifndef foo \ #define foo...
05:14 PM nuxil: vs doing the same but not including #pragma
05:15 PM nuxil: is it only dont incase the preprocessor dosent support #pragma ?
05:15 PM nuxil: *done in casees
05:28 PM nuxil: oki so yea that seems to be it.
05:34 PM polprog: odd, my server died
05:35 PM nuxil: rip
05:35 PM polprog: i cant seem to be even able to restart it via the web panel
05:38 PM dev1990: nuxil: 3 lines vs 1 line, and you can avoid mistake like #ifdef THIS_HEADER_IS_DEFINED_TWICE_BY_MISTAKE_BECAUSE_SOMEONE_COPY_IT_AND_FORGET_TO_CHANGE_IFDEF_AND_DEFINE
05:39 PM polprog: did i miss something
05:40 PM nuxil: dev1990, yea sure.
05:41 PM nuxil: i see that a valid one.
05:42 PM nuxil: i wounder what would happen if you add this to your top main.c: #pragma GCC poison uint8_t uint16_t uint32_t
05:42 PM nuxil: :p
05:43 PM nuxil: was reading this https://gcc.gnu.org/onlinedocs/cpp/Pragmas.html
05:44 PM polprog: interesting
05:44 PM polprog: i never seen a pragma "in the wild"
05:45 PM * dev1990 http://goalkicker.com/CBook/
05:46 PM polprog: my book buffer is overrun since last year
05:46 PM polprog: i need to finish Art of Electronics and the Witcher
05:46 PM nuxil: "C notes for proffesionals" and it starts of with a hello world program, :p
05:47 PM nuxil: anywho. downloaded and stored
05:47 PM dev1990: this is from stackoverflow articles, well it's good to know how to write hello world anyway
05:47 PM nuxil: im a pdf collector :)
05:48 PM polprog: i guess i will dl this as well
05:48 PM polprog: if its free
05:49 PM nuxil: it is
05:49 PM polprog: im a pdf collector as well
05:49 PM dev1990: im a epub collector ;p but pdf is fine
05:49 PM polprog: my favourite type are scripts from uni lectures/labs
05:49 PM polprog: epub, meh
05:50 PM dev1990: go opensource and it's really nice with electronic paper
05:50 PM polprog: if i had a kidnle
05:50 PM polprog: kindle*
05:50 PM polprog: i have one but it runs cyanogen, laggy as hell
05:51 PM polprog: nuxil, #define struct union
05:54 PM nuxil: i wounder if the creater of minions redefined struct to minions is their custom code they use.
05:55 PM polprog: what
05:55 PM nuxil: unions and minions :p
05:56 PM polprog: μnions
06:16 PM polygon: [19:32] <day> because I've seen a few simple PWM based boost circuits which drive a N-Channel FET directly with the PWM output, the current that flows through the pullup resistor shouldnt be sufficient, should it? [19:32] -will wark, connect limiting resistor in series with gate, the rise and fall times will suffer though with only 25mA current, 190mA is better.
06:16 PM polygon: <Emil> are you saying that gpio on avr are open drain? - they can be open drain, but they usually have a high side so the body diode will catch/clamp the output
06:17 PM polygon: day: the io pin will perfectly drive a tiny mosfet like BS170
06:18 PM nuxil: dont even have to be a mosfet.
06:19 PM nuxil: a small bjt will do aswell
06:19 PM polygon: [08:51] <polygon> What is your opinion on directly driving this with the pins of an arm :> https://cdn.sos.sk/productdata/34/47/0369a0f3/lcd-4-0-13-de-119-rs-20-7-5-1.pdf
06:19 PM polygon: [11:29] <polygon> i have an idea dynamically adjusting the cutting power of a hotwire foam cutter according to linear velocity, what is your opinion?
06:21 PM polygon: [13:42] <Emil> _abc_: upgrade your fucking tls support bro :D - i said the same, he is posing cool for nothing, nothing is secure ;) ever.
06:23 PM nuxil: waz duis ? https://cdn.sos.sk/productdata/34/47/0369a0f3/lcd-4-0-13-de-119-rs-20-7-5-1.pdf
06:24 PM polygon: nuxil: Liquid Crystal Display
06:24 PM nuxil: polygon, something you need to drive ? watch eevblog video 1045 on how to drive lcd's
06:24 PM polygon: i know how to...
06:24 PM nuxil: ahh ok
06:25 PM polygon: I think i will use 595 HC extender to interface it
06:25 PM polprog: watch eevblog video and see that driving lcds is non trivial and you should use off the shellf driver/module instead of wasting time :^)
06:25 PM polygon: so i need only 4 ports
06:25 PM nuxil: i have i2c lcd's :p
06:25 PM polygon: hi polprog
06:25 PM nuxil: bought a couple of Jartza
06:25 PM nuxil: verry nice ones.
06:26 PM polprog: hi polygon
06:26 PM polprog: ive done a cool thing with hd77480 once
06:26 PM polprog: matrix rain scroller :P
06:26 PM nuxil: :)
06:27 PM polprog: i still have it actually!
06:27 PM polygon: polprog: last year i played with 595s a bit, i have driven a 5x7segment+dp display connected in matrix, driven by 2 HC595s at 256Hz with a mega168 :>
06:27 PM polprog: polygon, 595s are sweet
06:27 PM polprog: i can show you some assembly code for fast driving them
06:27 PM polygon: lel i even removed delays and it worked :)
06:28 PM polprog: or no since my server is dead lol
06:28 PM polprog: yeah, NXP ones can do 45 mhz iirc
06:28 PM polygon: 100
06:28 PM polygon: ;>
06:28 PM polprog: my code bitbanged them with 3 cycles per bit speed
06:29 PM polygon: i dont know how fast it was, bit i am sure fast enough
06:29 PM polprog: they can be very fast
06:29 PM * polprog needs to try driving them from serial port
06:29 PM polprog: now that he can control serial from linux
06:29 PM polygon: i am in progress creating a modular 7seg display and lcd display for my stuff cheap
06:30 PM polprog: hmm
06:30 PM polprog: nice
06:30 PM polprog: btw, where are you from?
06:30 PM polygon: i could use a cheap calculator display but i don't like the zebra rubber thingy ;/
06:30 PM polprog: those are bad. plus, the hassle of driving a bare lcd
06:30 PM polprog: vide dave jones videos
06:31 PM polygon: i don't see how it is harder than driving a port extended matrix ;>
06:31 PM polprog: maybe you are right. i found a cool 3 1/2 digit lcd sometime ago
06:31 PM nuxil: you need to flip flop the voltage on a static lcd else you will wreck it in short time.
06:32 PM polygon: i will give it 64Hz+-32Hz refresh
06:32 PM polygon: assuming it will be perfect then
06:32 PM polprog: i guess you could do that with avr pins. but... too much work
06:32 PM polygon: nah
06:33 PM polygon: avr will love it
06:33 PM polprog: unless its someting very special i will use hd44780 which i have a whole lot of
06:33 PM polygon: a simple 4 digit display like on a multimeter
06:33 PM polprog: unless you make some smart stuff with timers
06:33 PM polprog: i should buy one module and try it
06:33 PM polygon: i can buy it for 3 eur
06:34 PM polprog: goodnight everyone. i hope my server will be up in the morning
06:34 PM polygon: https://cdn.sos.sk/productdata/34/47/0369a0f3/lcd-4-0-13-de-119-rs-20-7-5-1.pdf
06:34 PM polygon: this is about 3 eur
06:35 PM polprog: yeah ive seen similar. i like 16 segs in particular
06:35 PM polprog: night!
06:35 PM polygon: polprog: im in the centre of eu
06:35 PM polprog: polygon, got so sleep then ;)
06:35 PM nuxil: polygon, ask if Jartza has a couple of Raystar RX1602A3-BIW-TS to sell you :p
06:35 PM polprog: go to*
06:36 PM polygon: nuxil: i only want bare LCD now...and 7seg led
06:37 PM nuxil: oki. but this is nice that its i2c. so if your short on pins its a nice lcd to use.
06:37 PM polygon: well mine will be synchronous serial using 4 pins
06:38 PM polygon: i will connect a string of HC505s
06:38 PM polygon: 595
06:39 PM polygon: nuxil: https://assets.nexperia.com/documents/data-sheet/74HC_HCT595.pdf
06:39 PM polygon: it is a cmos ic that works at 2-6V
06:39 PM polygon: and upto 100MHz
06:41 PM nuxil: looks goood
06:41 PM polygon: yeah, a simple loop pushes out bits
06:42 PM polygon: on mcus with cpu clocked <100MHz no delay is even necessary
06:44 PM polygon: nuxil: lcds are cool too and led displays are cool too, lcds are better in daylight, but can even be backlit with a led
06:45 PM polygon: lcds draw microamps... but leds can be seen in the dark at microamp drive too
06:47 PM polygon: i guess the choice depends on power usage and visibility wainly, response time of lcd is 440ms at room temps, led is instant, led is simpler to drive, lcd needs ac
06:49 PM polygon: anybody know how these things are rated for dissipation? i have no clue, they say "dick stuck in the grinder" http://www.kingbrightusa.com/images/catalog/SPEC/CA56-11SRWA.pdf
06:50 PM polygon: for a large digit i doubt it should be rated 75mW, maybe it is per segment? and dp is same rating as segment?
06:52 PM polygon: but if i drive all segments at 20mA total is 1.28W for 4 digits
06:52 PM nuxil: so i was like. where the fuck have i seen this datasheet before.
06:53 PM nuxil: then it hit me. i got https://i.gyazo.com/1371888674f4624e48e0a9ed6f9bd1e3.jpg
06:53 PM nuxil: lol
06:53 PM polygon: haha, and you haven't used them.
06:53 PM nuxil: i had 16 of them
06:54 PM nuxil: made this with some of them. https://gyazo.com/545bcfa99598f57b9d175d328448c3ea and gave it to my brothers child.
06:55 PM polygon: ever seen a 7 seg led display that is static? :)
06:55 PM nuxil: no
06:55 PM nuxil: wait what=
06:56 PM nuxil: what do you mean a static led ?
06:56 PM polygon: i thought i want that, if i were to film it it would not flicker, and it only needs refreshing with new data
06:57 PM polygon: no matrix
06:57 PM polygon: no strobe effect
06:57 PM nuxil: ah.
06:59 PM polygon: atmega was ok with the port extended matrix at 256Hz too though
06:59 PM polygon: at stock 8MHz rc osc
07:01 PM nuxil: hmm well.to truly get rid of flicker on a 7seg LED display, you need to get rid of multiplexing. but that requires many pins tho..
07:02 PM polygon: 4
07:02 PM polygon: :)
07:03 PM nuxil: yea.
07:05 PM nuxil: but it still reqire more pins if you want sontant current on all segment. useing shit reg to expland your i/o is a nice way to do this :)
07:05 PM polygon: no
07:05 PM polygon: i pet resistors in series with leds.
07:05 PM polygon: that is how it works
07:06 PM nuxil: yes. i think you missed my point. using a shitreg you expand from 4 pins to 8 pins. cascading the shitreg expands your i/o even more.
07:07 PM polygon: btw 3 pns enough if you continuously display and dont want to tristate
07:08 PM polygon: output enable can be used to pwm dim
07:11 PM nuxil: btw. what thing-a-ma bob are you making ?
07:11 PM polygon: m i don't soo a reason to tristate an lcd, do you?
07:11 PM polygon: *see
07:11 PM nuxil: you confuse me. you say 7seg led display. now you say lcd :p
07:12 PM polygon: timer, temp controller, speedometer, battery charger
07:12 PM polygon: i want both :)
07:12 PM polygon: not at the same time
07:12 PM nuxil: oh.
07:12 PM polygon: leds arenot visible in daylight if low power, but lcd is
07:13 PM nuxil: so thats the reason you go for both ?
07:13 PM polygon: ya
07:14 PM nuxil: no no no.
07:14 PM polygon: but led display is cool at night and it is wide angle, fast, simple to drive
07:14 PM nuxil: you add in custom backlight (Side light) to your lcd. no readon to use led segments.
07:14 PM polygon: it can be soon in daylight but consumes much
07:15 PM polygon: ;/
07:15 PM polygon: never tried that
07:15 PM polygon: why dont they add the led in factory?
07:15 PM nuxil: some do.
07:16 PM polygon: https://cdn.sos.sk/productdata/34/47/0369a0f3/lcd-4-0-13-de-119-rs-20-7-5-1.pdf
07:16 PM polygon: for example i dont see a good and simple way to add 2 leds to this
07:16 PM polygon: that will work good
07:16 PM nuxil: it a bit of a custom job since you basically spread the light onto the display using some sort of difusers around the display.
07:17 PM polygon: it needs light from front to reflect back light front
07:17 PM nuxil: yea. thats why there is a small difuser frame on some lcd's
07:18 PM nuxil: meant to light up the display
07:18 PM polygon: i need to make a led frame for it?
07:18 PM nuxil: idk how your setup is. but light need to come from side/front.
07:18 PM nuxil: how you do it is up to you,
07:19 PM nuxil: add in mirrors :p
07:19 PM polygon: my setup will look like there will be a glass thing like 5mm polycarbonate and i epoxy the 7 seg display on it
07:21 PM polygon: i will not overcomplicate it
07:37 PM nuxil: overcomplicate it? dude :D. all you need to do in short term. sink in the display a few mm. (2-4) and add dioes on the side.
07:37 PM nuxil: using 7 seg Leds is overcomplicating it :p
07:38 PM nuxil: go take look at a old alarm/watch clock
07:38 PM nuxil: :D
07:45 PM polygon: nuxil: lel? https://www.aliexpress.com/item/Multi-function-LCD-Alarm-Clock-Projector-Color-Display-LED-Backlight-Attention-Projection-Digital-Weather-Snooze-Alarm/32810154721.html
07:45 PM nuxil: heh
07:45 PM polygon: 7seg led display IS projector
07:48 PM nuxil: was thinkng. you might even use some hot snort glue to create a frame with the leds in it for sidelight for the lcd :)
07:48 PM nuxil: hot snort glue or whatever you call it.
07:48 PM nuxil: pistol glue :p
07:49 PM nuxil: polygon, is that your plan ?
07:49 PM polygon: nah i dont use hot goo, epoxy, pc, glass
07:51 PM polygon: nuxil: this? https://www.helifreak.com/showthread.php?t=172436
07:51 PM nuxil: yes
07:51 PM polygon: hm i will look in my old mobile phone
07:54 PM polygon: nuxil: maybe i can cut a piece outof a light diffuser from a tft display? :)
07:55 PM nuxil: lol woot
07:55 PM nuxil: you got a broken one ?
07:57 PM polygon: i have some yea
07:57 PM polygon: even led backlight ones
07:58 PM polygon: they have horisontal and vertical fresnel foil, and a plexiglass light diffuserwedge
07:58 PM polygon: z
07:59 PM polygon: that foil is hypnotic, tried lighting through with a led
08:02 PM polygon: an RGB le backlit LCD would be cool
08:02 PM polygon: LED
08:03 PM nuxil: :)
08:05 PM polygon: i should connect the rgb led to the 595 string too right?
08:06 PM polygon: i see no simple way of color mixing thou
08:08 PM nuxil: cascade more shift regs. and dedicate some i/o to rgb control of backlight :p
08:09 PM nuxil: would not be pwm tho.
08:09 PM polygon: r2rdac on 595 lel
08:09 PM nuxil: :D
08:09 PM polygon: 8x3 bit RGB ?
08:10 PM polygon: 3x8bit
08:10 PM polygon: truecolor lcd backlight lol
08:12 PM nuxil: my keypad is built up using r2r network.
08:12 PM Emil: it's quite efficiemt
08:12 PM Emil: you only need a single pin for input
08:12 PM nuxil: yea. i had 8 buttons and was using 8 pins. now i just use 1
08:13 PM nuxil: to do the same job :D
08:13 PM Emil: and adc reads don't require fancy debouncing that much
08:13 PM Emil: So it's super simple software side also
08:14 PM Emil: you like, need a single timer, the adc and one adc-read sized byte of memory if I'm not wrong
08:14 PM Emil: adc-read sized memory block
08:15 PM Emil: so usually 2 bytes
08:15 PM nuxil: set ADLAR to 0 and you get full 10bit.
08:15 PM Emil: no I mean
08:15 PM Emil: I'm talking about what it takes to implement such
08:17 PM nuxil: hmm you sure about that ? dont you need to read ADCL before ADCH ? else you get corrupt data?
08:17 PM nuxil: and each is 1 byte
08:21 PM Emil: https://emil.fi/d/2018-01-24_04-21-10_NznCobov.png
08:22 PM Emil: nuxil: we are talking about custom silicon
08:27 PM polygon: nuxil: cool :)
08:28 PM Emil: that requires like 3 registers if I'm not mistaken
08:28 PM Emil: adc, memory and compare
08:28 PM polygon: ptting these together results in an r2r dac current generator for led driving http://ikalogic.cluster006.ovh.net/wp-content/uploads/8bitdac_2.jpg https://static.electronicsweekly.com/wp-content/uploads/2015/10/14142455/Linear-Tech-AN105-current-sink.jpg
08:29 PM Emil: Well, 4 if you count the timer
08:29 PM nuxil: polygon, that 1st pic is how i got my output on my AVR DDS :)
08:30 PM Emil: adc register, memory register, timer register and one general purpose compare register
08:31 PM Emil: well, of course transmit register, also
08:31 PM Emil: but like, only 2 code editable registers: memory and compare
08:32 PM polygon: :) adc button matrix
08:32 PM nuxil: its simple
08:32 PM nuxil: https://gyazo.com/beab3a6172e4c3194479be9ab52c566e
08:33 PM nuxil: no matrix
08:34 PM polygon: :)
08:35 PM polygon: it is probably awesome on the attiny with 8 pins
08:35 PM polygon: and with adc
08:35 PM nuxil: jup
08:35 PM polygon: dac is cool too
08:35 PM polygon: stm32 has dac hehe
08:36 PM polygon: nuxil: btw you can use a stepper motor or a bldc motor from a hdd as encoder
08:37 PM polygon: you need 2 (or 3) ports
08:37 PM nuxil: i have proper "cheep chinees" rotory encode :p
08:37 PM polygon: https://www.youtube.com/watch?v=tjCJ3MlFt7g
08:38 PM polygon: this is from trash, and it has ball bearings :)
08:41 PM nuxil: nice hack
08:53 PM polygon: nuxil: a cd rom drive's main drive motor is a bldc too that can do this, i'm sure you can find some nearby a garbage can
08:54 PM polygon: the coolness in that it is industrial, non-contact
08:55 PM nuxil: while the hack is nice. the thing is rather useless as a rot button. though it and it will spinn for 50 turns,
08:55 PM nuxil: might be nice for some sort of rpm counter tho.
08:55 PM polygon: well i will need temperature/time setting that can use it
08:57 PM polygon: can be done with buttons but sometimes it will feel good to turn that knob
11:04 PM day__ is now known as day
11:57 PM rue_: dial your clock speed, not the rate of time in your universe