#avr Logs
Dec 03 2018
#avr Calendar
12:19 AM rue_mohr: jesseg, jesseg
12:23 AM rue_mohr: http://ruemohr.org/~ircjunk/images/cam_2dec2018.png
12:23 AM rue_mohr: http://paste.debian.net/1054124/
12:24 AM jesseg: rue_bed, looking pretty fancy!
12:25 AM rue_mohr: tieing the input fields to the data struct took me most of the day
12:25 AM rue_mohr: still need to set up a loadGui() type thing
12:25 AM rue_mohr: suppose that next
12:25 AM rue_mohr: midnight here I come!
12:26 AM rue_mohr: if I'z wise, I'd take a bottle of melatonin right now...
12:27 AM rue_mohr: guis need so much stitching...
04:23 AM [1]MrMobius is now known as MrMobius
05:10 AM vmt: rue_mohr: i can click those buttons faster than they can respond, i can smell it
05:11 AM vmt: it's like ms outlook
05:29 AM polprog: lol
06:18 AM grog_k is now known as grog
08:11 AM jesseg: Morning
08:14 AM nohit_work: morning
08:49 AM vmt: jesseg: in terms of responsiveness, on a scale of [MS OUTLOOK] to [rue_mohr], how would you evaluate your program?
08:50 AM jesseg: vmt, I'm not sure I understand the question... could you explain?
08:51 AM jesseg: It's written game engine style
08:52 AM jesseg: so it tries to run at 59.93 fps if it can, and it syncs to video refresh rate
08:52 AM jesseg: but if your computer is not fast enough it updates at 30fps or whatever it can, but still synchronizing to video refresh
08:54 AM jesseg: Some processes where you tell it to generate cam data can take seconds to minutes depending on how complex it is and that locks it up till it's done - I haven't put in a feature to cancel a cam job yet
09:02 AM rue_mohr: jesseg, do you know where most of the time goes?
09:02 AM rue_mohr: path filling?
09:04 AM jesseg: well, most of the time when panning or zooming is probably spent parsing through the object database and sending 2D draw requests off to the opengl video card
09:04 AM jesseg: presumably the openGL video card then takes care of all that in parallel so as to not slow down much
09:04 AM rue_mohr: hmm, isn't the normal model to load the graphic into the card and then just manipulate it?
09:05 AM jesseg: that's for 3D image mapped surfaces. OpenGL also supports 2D acceleration for flat games :P
09:06 AM jesseg: and actually it's probably treating it as 3D but the graphics library I'm using converts the 2D objects into 3D objects on a flat plane
09:06 AM jesseg: but I'm not loading any textures for them
09:06 AM rue_mohr: I think tricking it into being a 3d set dosn't quite look the same
09:07 AM jesseg: Normally, in a game, you have lists of 3D vertexes which describe the objects in the view, then you load in bitmap images to the video card and it stretches those bitmaps over the surface of the object
09:07 AM rue_mohr: yup
09:07 AM jesseg: I really don't know what I'm talking about when it comes to 3D
09:08 AM rue_mohr: I'm going to be converting the clipper library to C
09:08 AM rue_mohr: for offsetting
09:08 AM jesseg: but whatever is going on seems to work pretty well on a reasonably modern computer
09:08 AM rue_mohr: I have no idea how its going to perform
09:08 AM rue_mohr: tho it seems your doing all the same stuff,
09:09 AM rue_mohr: so I might be comparing code as I go
09:09 AM rue_mohr: thats way later,
09:09 AM jesseg: feel free to rip off any part of my code you like :P
09:09 AM jesseg: it's not really worth ripping off but it's there to rip off :P
09:09 AM rue_mohr: right now it just drills holes at points, but in the process of that I get the whole frame work assembled
09:09 AM jesseg: yeah
09:10 AM rue_mohr: yesterday I ran into project model questions
09:10 AM rue_mohr: should the dxf that your using be internally saved, or just the filename that was used
09:11 AM rue_mohr: and, why not be able to load multiple dxfs for a project....
09:12 AM rue_mohr: which does mean I'd prolly have to deal with a 'file xy offset'
09:12 AM jesseg: I was trying to add support for importing or exporting DXF files and did not get consistant results. I thought I was exporting them correctly but friend who tried to open them in CNC plasma cutter software said they were scrambled
09:12 AM rue_mohr: which implies availability of file scale, and maybe even file rotate
09:12 AM rue_mohr: librecad
09:13 AM rue_mohr: it produces great fake files
09:14 AM jesseg: I know you won't understand this but I have an unexplaineable but very deep aversion to applications that live in what I call dependency hell: So your app uses 5 different libraries for things like reading DXF files, etc. Then each of those depend on another 5 or 10. Repeat that a few levels down, and you have hundreds of dependencies.
09:15 AM jesseg: And then ONE of those fails to compile on a specific version of gcc or glib or whatever, and bam.
09:16 AM rue_mohr: no, I'm there, I wrote my own libraries, and they usually dont depened on anything
09:16 AM rue_mohr: most programs seem to only be compilable by the author becasue their the only one who has the insanely complex build env
09:17 AM jesseg: exactly
09:18 AM jesseg: My only direct dependency is Allegro, which in and of itself is a dependency hell. But I'm just not up to doing what it does myself.
09:19 AM jesseg: and I can usually get it to compile on slackware which pretty much means any other distro probably has it available in their package feed LOL
09:20 AM rue_mohr: SDL has been pretty nice
09:20 AM jesseg: yeah I think I want to ultimately migrate to SDL
09:21 AM jesseg: but I would have to do a bunch more of stuff myself
09:21 AM rue_mohr: have you done any SDL?
09:21 AM rue_mohr: yea
09:21 AM jesseg: I've done some little demo test programs
09:21 AM rue_mohr: you said you have never split a project into two files
09:21 AM rue_mohr: want to do that later?
09:21 AM rue_mohr: not your program, just something simple
09:22 AM jesseg: I split a PIC micro project into multiple files to show a friend how to do it
09:22 AM rue_mohr: k
09:24 AM jesseg: But Allegro does provide some extremely nice routines, like drawing filled polygons with holes
09:24 AM jesseg: and polylines with round or square ends
09:24 AM jesseg: and arcs
09:27 AM jesseg: speaking of dependency hell, I vaguely remember -- I think one time I was trying to compile some open source application and one of it's 4th level dependencies had a dependency loop: A needs B, and B needs C, and C needs A
09:28 AM jesseg: and because the original author had already had A, B, and C installed before C needed A, he was fine. But me, starting out with none of A, B, or C, was up a dry creek with a leaky canoe and no paddles
09:30 AM jesseg: rue_mohr, but yeah I'd like to split my gwcad project into multiple files some day.
09:30 AM vmt: jesseg: the opengl buffers don't really care what data you put in them
09:32 AM jesseg: vmt, cool
09:33 AM vmt: given, you actually use buffers and not immediate-mode
09:33 AM jesseg: I don't know what Allegro does under the hood
09:33 AM vmt: no idea, i was just referring to what you said earlier. about half an hour ago
09:35 AM jesseg: I call their functions which draw lines, arcs, and polygons, and I may draw it all to a back buffer then flip it to the screen
09:35 AM rue_mohr: this wek is going to be horrid 8am-4:30pm, then 9pm-12pm
09:35 AM jesseg: but I don't remember
09:35 AM vmt: jesseg: of course, but that's irrelevant
09:36 AM rue_mohr: http://paste.debian.net/1054181/
09:36 AM jesseg: speaking of relevant, it's 7:35AM here and breakfast is starting to feel rather relevant.
09:36 AM rue_mohr: thats the core to mine
09:36 AM vmt: also, the vertex shader output is a 4-component vector. opengl works in 3d space
09:37 AM rue_mohr: the calls like line2dSetLine come from my 2d library
09:37 AM jesseg: cool
09:37 AM rue_mohr: arbShape -> arbitrary shape
09:38 AM vmt: and the normalized device coordinates are -1...1 on all axes x,y,z
09:39 AM vmt: everything beyond that gets clipped
11:58 AM vmt: and also yes rue_mohr, you can make it look as 2d as you want.
11:59 AM vmt: also rue_mohr how can you be so sure of the quality of libsdl(/2)?
12:02 PM vmt: also if it's only meant to be run on loonix, i'd skip sdl altogether and use xlib/xcb (and glx for ogl context) directly
12:08 PM nohit: yes, its best to just buy the lib
12:09 PM nohit: dont trust open source libs
12:10 PM polprog: open source is insecure because hackers can see the code
12:10 PM polprog: ~ your local politician
12:11 PM vmt: how many times exactly do you vet code?
12:11 PM vmt: the whole notion of code vetting is just... rofl
12:12 PM vmt: and support and maintaining for commie libs is always a dubious proposal
12:13 PM polprog: programming open source you are programminc communism
12:14 PM polprog: thats why i propse a not-3-clause bsd license
12:14 PM polprog: "Redistribution and use in source and binary forms, with or without
12:14 PM polprog: modification, are not permitted"
12:14 PM polprog: THIS SOFTWARE IS NOT PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
12:40 PM vmt: hey, how about just not host your source publicly
12:44 PM HighInBC: the best way to vet code is to make it a valuable target to hackers, use it to protect some bitcoin or CC#s, hackers will vet it for free
12:44 PM HighInBC: "free"
01:48 PM nohit: i think this is a pretty good deal http://www.embcode.com/en/Products/EcFAT
01:48 PM nohit: 480e for the lite version
01:49 PM nohit: and lite is enough if you use it for small flash memories (max 16MB)
01:51 PM nohit: "For developer licenses you buy 1 license per developer. That developer is then free to use EcFAT in any number of projects in any volume. It is similar to buying say a compiler."
01:51 PM twnqx: > camelCase
01:52 PM twnqx: rm -rf EcFAT
01:54 PM nohit: it will be hidden anyways
01:54 PM nohit: so its just open(), read() etc
01:58 PM twnqx: while the lib seems to have soem nice features, there is an issue
01:59 PM twnqx: if a system has use for it, i'd just run µC linux, some BSD or some other RTOS on it - and those usually come with FAT support
02:00 PM nohit: what's the issue tho
02:00 PM twnqx: why would i pay money for a feature that's already there?
02:01 PM twnqx: and a hefty amount with ridiculous limits on top
02:02 PM nohit: okay, what if the device cant run linux ?
02:02 PM nohit: does uc linux require mmu ?
02:02 PM twnqx: no
02:02 PM twnqx: that's the difference between µC linux and a "normal" one
02:02 PM nohit: ok
02:04 PM twnqx: i mean, 1.5k and not even exFAT support...
02:05 PM vmt: nohit: i honestly see nothing there which could not be put together by a dev team in a *very* reasonable timeframe
02:05 PM twnqx: wear levelling.
02:05 PM nohit: that's the main one
02:05 PM vmt: and by a dev team, i mean even as small as 2-3 competent programmers
02:06 PM twnqx: decent wear levelling algorithms require a few manyears of development
02:06 PM vmt: i am sure papers on the subject exist
02:06 PM twnqx: probably, but then you run into IP problems
02:07 PM twnqx: i'd assume that a least 90% of that price goes into that part, because you are right, everything else is maybe a week or two for two programmers
02:08 PM vmt: i hardly think all (or even the majority) of available research is under a license which prohibits commercial implementation
02:10 PM nohit: twnqx i dont think 1.5k is a hefty amount
02:10 PM nohit: its actually ridiciously cheap
02:10 PM nohit: for a company
02:10 PM twnqx: that's a bloody hobbyist license, not a company license
02:11 PM twnqx: "hey, ONLY ONE of your programmers is allowed to use it, noone else can touch it!"
02:11 PM nohit: no it isnt, its a developer license
02:11 PM twnqx: did you even read it?
02:11 PM twnqx: a single person in a company can use it is a hobbyist license
02:11 PM nohit: you know i did
02:11 PM twnqx: guy is on vacation - sorry, we can't touch the code (legally)
02:11 PM twnqx: lol
02:12 PM nohit: actually no
02:12 PM twnqx: oh wait, he's on 6 month of parental leave, call back then
02:12 PM nohit: If the developer quits or changes assignment you may transfer the license.
02:12 PM vmt: also, i am not exactly sure of the validity of "a decent wear-leveling algorithm takes a few manyears"
02:12 PM twnqx: yeah
02:12 PM twnqx: sorry, if i have to call to legally have code touched by someone else
02:12 PM twnqx: that's hobbyist level
02:12 PM twnqx: nothing else
02:13 PM twnqx: i mean actually it's worse than hobbyist
02:14 PM twnqx: vmt: you can't make decent wear levelling algorithms withut knowing details of the flash chip (SLC, MLC, structure, ...)
02:14 PM nohit: its perfect for small companies, you buy so many licenses that you have developers
02:15 PM nohit: cheap af
02:15 PM twnqx: and suddenly i paid a few man-months of salary for library
02:15 PM twnqx: "cheap af" lol
02:16 PM vmt: twnqx: surely, but these are problems which are definable and ergo solvable. in less time than man-years.
02:16 PM vmt: well, solvable in the sense of a good approximation, at any rate
02:17 PM twnqx: https://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_FAT/index.html hmmm
02:17 PM twnqx: no exfat though
02:17 PM twnqx: (again)
02:18 PM twnqx: not even useful for a portable media player these days
02:18 PM twnqx: afaik 64GB SD Cards require exfat
02:19 PM nohit: so you have used uc linux on commercial products ?
02:20 PM nohit: we use freertos
02:20 PM twnqx: most openwrt based routers do so
02:21 PM twnqx: so you use freertos, which (now) has included fat support
02:21 PM twnqx: but think an external fat lib is a good idea
02:25 PM twnqx: http://elm-chan.org/fsw/ff/00index_e.html a tad cheaper, and even supports exfat
02:25 PM nohit: that's what we use with sd cards
02:26 PM nohit: but there's no wear leveling
02:26 PM twnqx: there can't be wear levelling with sd cards
02:26 PM twnqx: a) it's in the card's controller
02:26 PM nohit: :D
02:27 PM twnqx: b) cards must be readable by other systems, and exfat has no provisions to support it
02:36 PM nohit: actually our card doesnt even have to be readable by other systems, its built inside the dive computer and you cant remove it without breaking the device
02:38 PM nohit: the problem is that we also have flash memory in some of our products and we need a robust solution for that
02:39 PM twnqx: use emmc flash
02:51 PM McDonaldsWiFi is now known as britneyspears69
02:52 PM britneyspears69 is now known as McDonaldsWiFi
02:52 PM twnqx: that moment when you can't move a chip by 4mm to the right because the routing will look ugly
02:53 PM twnqx: but you really ned 4mm more space
02:53 PM twnqx: :X
04:54 PM nohit: but yeah, since we only need that for the flash, then the fat12 would be enough, so it would be 2 developers x 480e = 960e
04:54 PM nohit: not bad price, not bad at all
04:55 PM nohit: considering we can use it in all our products
04:56 PM nohit: and its a tested and doucmented solution, with customer support
04:57 PM nohit: i dont see how can you call this expensive, its a bargain
05:00 PM nohit: vmt if a wear leveling etc is easy for you, you should come work for us
05:24 PM twnqx: well, once you have the source you can look at how they implemented it
05:52 PM nohit_ is now known as nohit
11:45 PM day__ is now known as day