#avr Logs
Mar 27 2018
#avr Calendar
12:14 AM rue_: _ami_,
12:17 AM rue_: ok
12:17 AM rue_: so
12:17 AM rue_: I have a stm32, here, ... with a pcf8574... on a breadbaord close by
12:17 AM rue_: but their getting closer
01:07 AM polprog: https://puu.sh/zQp67/7499bb398b.jpg
01:07 AM polprog: eye cancer imninent
01:08 AM rue_: eeek dos
01:08 AM rue_: and not tabbed properly!
01:09 AM rue_: and the variable declerations aren't in the right place
01:09 AM rue_: which means, the only crime its missing, is returning pointers to local variables
01:10 AM rue_: cause, its been vertically stretched (a horrid waste of space)
01:10 AM rue_: and wait, main isn't right
01:10 AM rue_: ugh
01:10 AM rue_: is it trying to be C or c++?
01:18 AM Haohmaru: znak, kwadratu..
01:18 AM Haohmaru: someone is trying to write weird bulgarian with latin letters ;P~
01:18 AM Haohmaru: Lekcja >:)
01:18 AM polprog: this is just plain wrong
01:19 AM polprog: clrscr(); no such function in my conio
01:19 AM Haohmaru: rue_ "cout" .. C++
01:20 AM Haohmaru: polprog r u on win10?
01:20 AM polprog: horrid indentation, no using namespace std - g++ wont compile
01:20 AM polprog: Haohmaru: this computer? win 7 win server 2003 wallpaper
01:20 AM Haohmaru: afaik, thanks to M$, you should avoid using conio.h on newer windows
01:21 AM polprog: you should avoid it anywhere
01:21 AM Haohmaru: i think win10 has a "terminal" that works similar to linux/posix/whatever (i don't get that sh*t)
01:21 AM Thrashbarg: what the heck?
01:21 AM Haohmaru: they had that terminal from a long time but didn't include it in previous windows versions before 10
01:22 AM polprog: win 10 cmd.exe is a bit more vt100 compatible iirc
01:22 AM Haohmaru: yeah, somethin like that
01:23 AM rue_bed: :) the stm32 took the led blink software
01:23 AM polprog: but this is fucking horrible
01:23 AM polprog: and she writes c++ and the increment operator as a subscript
01:23 AM Haohmaru: i think this is gonna be a problem, stm32cubemx not being able to export C++ files
01:23 AM rue_bed: linux dosn't have conio.h
01:24 AM rue_bed: someone made one, but it was never maintained
01:24 AM Haohmaru: if ya want fancy i think pdcurses is your friend
01:24 AM rue_bed: pd?
01:24 AM rue_bed: ncurses?
01:24 AM polprog: ncurses?
01:24 AM rue_bed: ncurses is evil
01:25 AM polprog: indeed
01:25 AM Haohmaru: or roll your own, like i did ;P~
01:25 AM Haohmaru: sorta
01:25 AM rue_bed: they make non-compatible changes between versions
01:25 AM polprog: umm
01:25 AM Haohmaru: ncurses is GPL iirc
01:25 AM polprog: char** framebuffer;
01:25 AM rue_bed: so the functions nonally take a different set of arguments, but thier totally different
01:25 AM polprog: am i doing it right
01:25 AM Haohmaru: pointer to char pointer? wut'cha doin'
01:26 AM rue_bed: its a 2d array
01:26 AM Haohmaru: isn't it a 5D array? ;P~
01:26 AM Haohmaru: why 2D
01:27 AM polprog: char[12][34] framebuffer. same but you can allocate the first one during runtime
01:27 AM rue_bed: / convert X,Y to integer offset V, I is XMAX J is YMAX
01:27 AM rue_bed: / this is broken for 0 based arrays...
01:27 AM rue_bed: /#define xy2i(X,Y,I,J) (((I)*(Y))+(X))
01:27 AM rue_bed: #define xy2i(X,Y,I) (((I+1)*(Y))+(X))
01:27 AM rue_bed: #define i2x(V,J) ((V)%(J+1))
01:27 AM rue_bed: #define i2y(V,J) ((V)/(J+1))
01:27 AM polprog: so it can have variable size
01:27 AM rue_bed: I wrote those to do it in a 1d buffer
01:27 AM polprog: nice
01:27 AM Haohmaru: i thought char[12][34] is of type char*
01:27 AM rue_bed: well, ~
01:27 AM Haohmaru: *shrug*
01:27 AM polprog: its an array of arrays. or array of pointers
01:28 AM rue_bed: its an array of pointers to pointers to characters
01:28 AM rue_bed: er,...
01:28 AM Haohmaru: unless you want to access it like (a[x])[y] or something
01:28 AM * rue_bed counts on his fingers
01:28 AM polprog: and array being syntactic sugar for ptr arithmetics
01:30 AM Haohmaru: mmm, more evil preprocessor macros from rue_bed ;P~
01:30 AM rue_bed: I know how to use them so they work
01:31 AM rue_bed: tho, I missed some ()
01:33 AM polprog: void (*functions[256])(void*);
01:33 AM polprog: a b u s e
01:33 AM rue_bed: argumentless functions
01:33 AM rue_bed: er, 1 argument
01:33 AM rue_bed: ugh
01:33 AM polprog: what
01:34 AM rue_bed: 1 pointer to arguments
01:34 AM rue_bed: no return values
01:34 AM polprog: okay
01:34 AM rue_bed: otherise more *
01:35 AM polprog: void* (**_)(int, int, int, int);
01:35 AM Haohmaru: so, afaiu, on the stm32 (at least when used with cubemx), there are like 3 things: CMSIS, HAL, LL, where CMSIS comes from the ARM guys and is like sorta the equivalent of the avrgcc headers for a chip, HAL is a high-ish level C abstraction layer, and LL is tighter C layer
01:35 AM Haohmaru: is that correct?
01:35 AM rue_bed: wtf would you use a hardware abstraction layer?
01:35 AM rue_bed: just write the damn code for the device.
01:36 AM rue_bed: code dosn't live past the device anyhow
01:36 AM Haohmaru: i'm using cubemx, it has certain default options
01:37 AM rue_bed: like taking up all your resources so that your code can be unsuccessfully ported to soemthing you didn't make it for?
01:37 AM Haohmaru: i don't know what to do!
01:37 AM rue_bed: write the code for the device your using it for
01:38 AM Haohmaru: on xmega, i've not used the atmel libraries, i wrote my own C++ classes for dealing with spi, usart, FIFOs, eeproms, w5500, RTC, ADC, etc..
01:38 AM rue_bed: or do like everyone else, and apply some monkey to code that was close but didn'tcompletely work to get something new that dosn't completely work either
01:38 AM Haohmaru: that means reading datasheets, writing sloppy code
01:38 AM rue_bed: you cant write code thats not sloppy?
01:39 AM Haohmaru: maybe i can't
01:39 AM Haohmaru: but it works
01:39 AM rue_bed: yea
01:39 AM rue_bed: thats the arduino way
01:39 AM rue_bed: so stick to arduino for now
01:39 AM Haohmaru: IMO it's less sloppy than your macros ;P~
01:39 AM * Haohmaru runs
01:40 AM rue_bed: you have to know how to use them.
01:40 AM Haohmaru: yeah, i know how.. avoid them
01:40 AM rue_bed: yes, if you dont know what your doing, avoid them completely
01:40 AM Haohmaru: const size_t nasty_calculation = <integer math goes here>;
01:40 AM rue_bed: cause you will try to use them for things they cant do anyhow
01:40 AM * Xark notes CubeMX is worse than Arduino in many ways (in terms of you needing to do things "its way").
01:41 AM Haohmaru: Xark so the HAL/LL stuff is trying to be like arduino?
01:41 AM Ameisen: you should use constexpr.
01:41 AM Haohmaru: (i'm not familiar with arduino)
01:41 AM Emil: polprog: is it char z because z is like the first letter of "character" in Polish? :D
01:42 AM polprog: most likely
01:42 AM Haohmaru: Ameisen constexpr is still new to me, i got a pile of things to learn
01:43 AM polprog: whats a constexpr
01:43 AM Haohmaru: some of the new C++ stuffz
01:43 AM Ameisen: constant expression.
01:43 AM Ameisen: I mean, it was introduced 7 years ago :|
01:44 AM rue_bed: you can learn from two people who battle about methods(void) {
01:44 AM Haohmaru: method(void) sounds like C
01:44 AM rue_bed: c++ is an abomination
01:45 AM rue_bed: even t oop
01:45 AM polprog: my grandfather used algol
01:45 AM polprog: is linux kerner in c or cpp?
01:45 AM Haohmaru: my grand grand father probably used candles to see in the dark
01:45 AM polprog: kernel*
01:45 AM rue_bed: its C
01:45 AM Xark: rue_bed: At least the newer changes are making it better (but not smaller...although I think they did remove a keyword). :)
01:45 AM Haohmaru: yey, so let's throw away all other languages!
01:46 AM Haohmaru: C is all you EVER need
01:46 AM Haohmaru: woohoo
01:46 AM Ameisen: why bother with C?
01:46 AM Ameisen: you can write asm just fine.
01:46 AM rue_bed: C is just glorified asm
01:46 AM Ameisen: Hell, ASM is too high-level
01:46 AM Ameisen: write machine code
01:46 AM Ameisen: or, better yet, hard-wire CPUs to perform specific tasks using discrete components.
01:46 AM polprog: you just need a steady hand and a magnetized needle
01:46 AM polprog: oh nice
01:46 AM rue_bed: pascall is better than C, but it didn't live
01:46 AM Ameisen: or, even better than discrete components... use a system of electromechanical relays.
01:46 AM rue_bed: compiles much nicer
01:47 AM * Haohmaru takes away rue_bed's computers and replaces them with equal number of discrete logic gates and transistors, in buckets
01:47 AM polprog: i corrected that bloody switch prog, she asked me if she could print it as an example. nice
01:47 AM Haohmaru: here you go rue_bed
01:47 AM Xark: rue_bed: Pascal needed a lot of extensions...however Modula-2 was pretty nice. :)\
01:47 AM rue_bed: Ameisen, you know, that what they do when they make a FPA based cpu...
01:47 AM polprog: Ameisen: this messgae was brought to you by omron?
01:48 AM Ameisen: FPGAs are neither discrete components or electromechanical relays
01:49 AM Xark: Ameisen: Not sure there is a market for a relay based FPGA... :)
01:49 AM Ameisen: I don't recall saying field programmable
01:49 AM Ameisen: I just said electromechanical relays
01:50 AM Haohmaru: so, i haz confooz, shall i be wasting my time with cubemx HAL/LL/CMSIS?
01:50 AM Ameisen: the proper way to progrma them is using jumper wires
01:50 AM Ameisen: prolly using Plankalkül
01:50 AM Xark: Haohmaru: Hmm, https://hackaday.com/2017/07/15/stm32cubemx-makes-makefiles/
01:50 AM polprog: if i take my avr prog and a laptop and go outside does it nake it a field programmable device?
01:51 AM Ameisen: I have a functional Clang-based ARM Embedded toolcain
01:51 AM Ameisen: toolchain*
01:51 AM Haohmaru: Xark i already stuffed a generated project from cubeMX into my IDE and built it
01:51 AM Haohmaru: so i don't need them makefiles
01:51 AM Ameisen: not really better or worse than the GCC one yet
01:51 AM Xark: Haohmaru: Okay, well, this is if you care what is going on.
01:52 AM rue_bed: maybe we should all just go back to FORTRAN
01:53 AM polprog: its lisp where its at
01:53 AM Haohmaru: cubemx seems to be able to set up a lot of stuff like clock sources, peripherals, and even this DMA thing, but i want to code in C++
01:53 AM Haohmaru: i mean, my existing code from the xmega is in C++ .. i want to reuse it
01:53 AM Xark: Haohmaru: I would be surprised if it couldn't do C++ projects...
01:53 AM Haohmaru: it can't
01:54 AM Ameisen: I use a ruby-based build system to build C, C++, and assembly using either GCC or Clang for either AVR or ARM
01:54 AM Haohmaru: i renamed main.c to main.cpp and it built again, but i read that this might not actually work if you flash it onto the chip
01:54 AM Xark: Haohmaru: Yeah, reading that. Wow, crappy. :)
01:58 AM rue_bed: for( m = nn; !(j & m) && m; m >>= 1, j ^= m ) ; // reverse binary increment j
01:58 AM Haohmaru: ..because something related to one or more of the HAL files or ld scripts or something
01:58 AM Xark: Haohmaru: Yeah, you would need to port C++ startup files, linker script etc. Lame.
01:58 AM Haohmaru: so what can i do in this situation?
01:58 AM Haohmaru: forget cubemx/HAL/LL, and use CMSIS?
01:58 AM Ameisen: I need to actually flesh out this build system a bit more and publish it, prolly
01:58 AM rue_bed: I still object to a HAL on a microcontroller
01:58 AM rue_bed: I also object to running java on them
01:58 AM Ameisen: A HAL is fine if it's a compile-time construct
01:58 AM rue_bed: but I regard them the same
01:58 AM Ameisen: like you can do with templates and constexpr
01:58 AM Ameisen: aka what I do
01:58 AM Ameisen: doing what the arduino sdk does, though, is stupid
01:58 AM Haohmaru: Ameisen yes, that's my long-term goal, i wanna learn this new stuff that lets you use templates to do compile-time optimizations to the extreme
01:59 AM polprog: same
01:59 AM Haohmaru: i tried to do that on atmega, i did a buffered USART template class
02:10 AM _ami_: why to use HAL or CubeMX, when you already have open source libopencm3.
02:10 AM _ami_: few people might not like the api long names
02:10 AM Haohmaru: _ami_ there are too many things that are "for" stm32 or work "on" stm32
02:11 AM Haohmaru: cubemx happens to be the first thing i picked, cuz it was on st's website
02:12 AM _ami_: IMHO, use libopencm3.
02:12 AM _ami_: HAL/CubeMX code seems like written by java developers.
02:13 AM Haohmaru: well cubeMX *IS* written in java
02:13 AM _ami_: i don't like this kind of api name HAL_Stupid_Api_Name()
02:13 AM Haohmaru: and it eats a quarter of my RAM when it runs
02:15 AM Haohmaru: _ami_ but opencm3 is gpl
02:15 AM _ami_: Haohmaru, don't plan to open your code?
02:15 AM Haohmaru: no, this is for the job
02:15 AM Haohmaru: it's not up to me
02:16 AM _ami_: In that case, you can just provide .o of your code and provide a guide (or makefile) to compile it with libopencm3 lib.
02:16 AM _ami_: hmm..
02:18 AM Haohmaru: what do i do otherwise? take CMSIS and write my own "HAL" the way i like?
02:18 AM _ami_: Haohmaru, its LGPL
02:18 AM _ami_: libocm3 license
02:18 AM _ami_: check this: https://balau82.wordpress.com/2015/04/12/libopencm3-for-the-license-sensitive-cortex-m-developer/
02:19 AM _ami_: you just have to provide a way to link your application object to libocm3
02:24 AM _ami_: This is true since someone asked the same question to libocm3 lead developers, and they said the same thing which is mentioned in the blog
02:25 AM _ami_: i think you should try talking to your boss and show this picture.
02:25 AM Xark: LGPL is not ideal for embedded...good luck with your boss Haohmaru. :)
02:25 AM Haohmaru: yes, i know this sort of trick on computers, closed-source programs which use LGPL libraries
02:26 AM Haohmaru: you don't static-link the LGPL lib, you dynamic link to it
02:26 AM Haohmaru: i've not done it, i just know that it's technically possible
02:26 AM _ami_: well, in mcu firmware, there is no meaning of dynamically linked
02:26 AM Xark: Haohmaru: Yeah, which typically doesn't exist on embedded (so you need to provide .o files and leak symbols and stuff).
02:26 AM Haohmaru: yeah
02:27 AM Xark: I.e., forget it. :)
02:27 AM _ami_: you have to link statically. so you got to provide .o
02:27 AM * Xark is in the same boat on consoles (where things are encrypted etc.)
02:27 AM Haohmaru: i think i saw opencm3 a few days ago, i ran away immediately when i saw GPL
02:28 AM Haohmaru: so, i'm left with CMSIS then
02:28 AM Haohmaru: but according to that article, CMSIS only covers things which are part of the "ARM" core, not the entire STM32Fxxx chip
02:29 AM Haohmaru: right?
02:29 AM _ami_: no idea abt CMSIS.
02:30 AM _ami_: i think with little effort, you could write your own HAL :)
02:31 AM _ami_: its not very hard but yeah it would take time
02:33 AM _ami_: Xark, why LGPL is not ideal for embedded? Haohmaru ^
02:34 AM Xark: _ami_: Because you need to provide .o files of all your stuff and a way to relink and reload into firmware for end-user. PITA (and hard to comply with if you have a legal team).
02:35 AM * Xark links https://balau82.wordpress.com/2015/04/12/libopencm3-for-the-license-sensitive-cortex-m-developer/
02:36 AM Xark: LGPL is a good when you have shared libs/DLLs.
02:36 AM Haohmaru: i see " * @brief CMSIS STM32F446xx Device Peripheral Access Layer Header File." but this file is written by ST, not the CMSIS guys
02:36 AM Haohmaru: so, CMSIS plus chunks from the ST HAL then.. should be my starting point
02:36 AM Haohmaru: or maybe i can't butcher out stuff from the HAL
02:36 AM Haohmaru: :/
02:36 AM Xark: Haohmaru: Yes, my understanding is you use CMSIS along with CubeMX libraries for STM32
02:40 AM Haohmaru: i think the idea is that the end user getting your device, has to be able to replace the LGPL'ed chunk from your project with a new version of that LGPL'ed chunk
02:40 AM Haohmaru: if it was a computer program that uses some LGPL .dll like, say, SDL (no idea if that's exactly LGPL, doesn't matter) then the user must be able to replace the sdl.dll with a new version
02:40 AM Haohmaru: actually, it doesn't matter if the user wants to replace it with a "new" version, he MUST be able to do it, even if it's because he doesn't trust you that you kept your hands off of the LGPL'ed chunk
02:41 AM * Xark notes SDL was completely re-implemented with a new BSD license (so it can be used on iPhones etc.)
02:41 AM Haohmaru: i never went for SDL, i used allegro ;P~
02:42 AM Xark: (sorry, zlib license, but exactly because LGPL was not suitable for consoles and other close systems)
02:42 AM Xark: SDl > Allegro (but to each his own). :)
02:42 AM * Xark notes he did some SDL work long ago...
02:42 AM Haohmaru: so afaiu, CMSIS alone is not enough, because that thing seems to know nothing about USARTs, SPIs, ADCs, etc..
02:43 AM Xark: Haohmaru: Jibs with what I was reading a bit ago.
02:43 AM Xark: Jibes*?
02:43 AM Haohmaru: ji-wat?!
02:44 AM Xark: agrees with* :)
02:46 AM Emil: Haohmaru: CMSIS is only the core
02:46 AM Emil: Haohmaru: all peripherals are vendor specific
02:46 AM Emil: and startup is vendor specific
02:47 AM Emil: ARM is a clusterfuck
02:47 AM Xark: Emil: Not fun porting between vendors, that is for sure. :)
02:48 AM Emil: this means that yes, you can have a general computer running on any arm quite easily
02:48 AM Emil: but communicating with and sensing the outside is another problem :D
02:49 AM Xark: Emil: Yeah. At least instruction set is standardized.
02:50 AM Haohmaru: i need at least enough headers/c files for my chip, to be on a comparable starting point level as i was with xmega and avr/io.h + avrlibc
02:50 AM Haohmaru: ..and datasheet
02:53 AM _ami_: i already wrote one article for f407 but its based on libocm3.
02:53 AM _ami_: http://amitesh-singh.github.io/stm32/2017/09/02/blinking-leds-on-stm32f407zgt6.html
02:59 AM Haohmaru: Emil i was calling it "the wild west" .. "clusterf*ck" i guess is in the same spirit
02:59 AM Haohmaru: so i got a better view on the situation now, i'm in deep sh*t
02:59 AM nohitzwork: there is this cmsis header file, that's basicly only thing you need
03:00 AM nohitzwork: it has all the registers
03:00 AM nohitzwork: but it's just not feasible
03:00 AM Haohmaru: nohitzwork i thought it doesn't include anything chip-specific like USARTs and stuff
03:00 AM nohitzwork: HAL provides everything you need, even the middlewares so why not you them
03:01 AM Haohmaru: i need C++
03:01 AM nohitzwork: all the uart registers are there
03:01 AM Haohmaru: my code from the xmega (which i'll be reusing) is in C++
03:02 AM Haohmaru: nohitzwork where do you get this CMSIS? i'd expect it comes from ARM
03:03 AM Haohmaru: in the cubeMX generated code, there's a folder CMSIS, and inside there there are two or three STM32-specific headers, BUT their author is ST, not ARM
03:03 AM nohitzwork: its in your project you created with cube mx, <project>\Drivers\CMSIS\Device\ST\STM32L4xx\Include
03:03 AM Haohmaru: yes, look at who's the author
03:03 AM nohitzwork: stm32l476xx.h
03:04 AM nohitzwork: ST is the author
03:04 AM Haohmaru: yes, so i think that if i obtain "CMSIS" - it will not contain those files that ST adds
03:04 AM Haohmaru: i'll need to obtain those from ST
03:05 AM Haohmaru: and then glue them together somehow
03:05 AM nohitzwork: or course its's ST sinmce its their chip
03:05 AM Haohmaru: so "CMSIS alone" is not enough, i need CMSIS plus ST chip-specific headers from somewhere
03:06 AM Haohmaru: but are those files from the HAL?
03:06 AM nohitzwork: this is CMSIS
03:06 AM nohitzwork: and this is all you need programming wise
03:06 AM _ami_: Haohmaru, check this lib: https://github.com/andysworkshop/stm32plus
03:07 AM _ami_: check the license if it suits to your needs.
03:07 AM nohitzwork: no they are not from HAL, Haohmaru
03:08 AM nohitzwork: in the Drivers folder there are 2 folfres, HAL and CMSIS
03:24 AM nohitzwork: http://arm-software.github.io/CMSIS_5/Core/html/templates_pg.html blue ones are provided by vendor, pink ones by arm
03:26 AM nohitzwork: you do need of course that startup assembly file that sets SP, config clock system etc. before branching to main() but that goes without saying
03:27 AM Haohmaru: i am trying to download cmsis5 from github.. for more than 10 minutes..
03:27 AM nohitzwork: that's basicly equalent of crt0.o with avrs
03:28 AM Xark: Zero bss, copy data section to RAM, if C++ call constructors etc.
03:28 AM Haohmaru: i got the .zip, but it must be broken cuz it fails to completely unzip, i fail to download the .tar.gz at all
03:28 AM Haohmaru: i don't understand that stuff, i need C++ tho, i don't want to be stuck with C :~(
03:31 AM Haohmaru: oh sh*t.. "no space left on device" O_O
03:31 AM nohitzwork: you have all the reuired cmsis already
03:32 AM nohitzwork: CMSIS/Include has all the arm made files
03:32 AM Haohmaru: the cubeMX only downloads *certain* things and puts them into folders, so it's kinda hard to know what's CMSIS and what's HAL
03:33 AM nohitzwork: if you have 2 folders, HAL and CMSIS, how is it hard to know. i thin its quite obvious then
03:34 AM Haohmaru: i don't know untill i know >:(
03:34 AM nohitzwork: but yeha, for example "arm_math.h" is for using the DSP instructions
03:35 AM nohitzwork: that file is made by arm
03:35 AM nohitzwork: its in the include folder
03:35 AM Haohmaru: hm, i filled up my /home partition
03:35 AM Haohmaru: bleh!
03:39 AM Haohmaru: well fugg, i got 17GB worth of .iso files >:/
03:39 AM Haohmaru: that'd be easy ;P~
03:50 AM lvlinux: 17GB of ISOs? Noob lol...
04:00 AM Haohmaru: nohitzwork i search into files for "stm32" (case-insensitive) in the CMSIS folder, and i don't find much
04:02 AM nohitzwork: like i said, all the cmsis files comes from the vendor package already, so that download was useless
04:03 AM Haohmaru: then i need to obtain CMSIS from ST?
04:03 AM nohitzwork: read above
04:04 AM Haohmaru: which part exactly?
04:14 AM nohitzwork: Drivers/CMSIS folder includes all the vdero files and arm files, then startup_stm32l476xx.s is in some folder, probably startup folder
04:14 AM nohitzwork: *vendor
04:16 AM nohitzwork: look at this http://arm-software.github.io/CMSIS_5/Core/html/templates_pg.html
04:16 AM nohitzwork: To simplify the creation of CMSIS-Core device files, the following template files are provided that should be extended by the silicon vendor to reflect the actual device and device peripherals. Silicon vendors add to these template files the following information:
04:16 AM nohitzwork: Device Peripheral Access Layer that provides definitions for device-specific peripherals.
04:16 AM nohitzwork: Access Functions for Peripherals (optional) that provides additional helper functions to access device-specific peripherals.
04:16 AM nohitzwork: Interrupt vectors in the startup file that are device specific.
04:18 AM Haohmaru: yeah okay, i get that
04:18 AM Haohmaru: where do i get these from?
04:18 AM Haohmaru: if not from arm.com
04:19 AM nohitzwork: why would arm host ST spesific files
04:19 AM Haohmaru: the answer must be "from st.com"
04:19 AM nohitzwork: cube mx is the easiest and fastest way to get them
04:20 AM nohitzwork: C:\Users\antto\STM32Cube\Repository you probably have them already
04:20 AM nohitzwork: if you have used cubemx
04:20 AM Haohmaru: i don't have them on the debian
04:21 AM Haohmaru: and i don't want to use cubemx for now
04:22 AM nohitzwork: then sign up for ST, request software, wait, open email and link...if you wanna do it the hard way
04:23 AM nohitzwork: but i dont get it :D you made that makefile project so you have them already
04:23 AM nohitzwork: unless u changed mcu
04:23 AM Haohmaru: the makefile doesn't work
04:24 AM nohitzwork: so? does that make the other files useless
04:24 AM Haohmaru: the only way i managed to build the files was by creating a Code::Blocks project
04:25 AM nohitzwork: yeah, and if you used the files from that makefile project, the files are in that c::B project
04:25 AM Haohmaru: i need to make a new project anyway, that was just testing "wtf is this cubemx thing" ;P~
04:26 AM nohitzwork: ok but if you have same mcu, the CMSIS files are ok
04:26 AM Haohmaru: "what if i click here, how bout there, oh noes, ctrl+z"
04:27 AM Haohmaru: http://www.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32cube-mcu-packages/stm32cubef4.html
04:27 AM Haohmaru: so "STM32CubeF4" seems to smell like the thing i need
04:28 AM Haohmaru: for the F4xx chips
04:30 AM nohitzwork: yeah
04:31 AM nohitzwork: if youre on linux this might be the fastest way to get them https://github.com/stv0g/stm32cube-gcc
04:31 AM Haohmaru: ooh, it's 414MB, that smells right
04:31 AM nohitzwork: i think u need to register for that
04:32 AM Haohmaru: no
04:32 AM Haohmaru: but i had to supply my name and email to get cubemx before that
04:35 AM Haohmaru: a makefile?!
04:52 AM nohitzwork: make cube Downloads the most recent STM32Cube version from the ST website and extract it to cube.
04:53 AM rue_bed: who had the nice i2c function library that incorperated the start and stop stuff into the transmisison calls?
04:54 AM rue_bed: why are most libraries to use hardware i2c systems larger than just bitbanging the i2c?
04:57 AM LeoNerd: Merging start/stop into the main calls means it's harder to do things that require "repeated start"
04:57 AM LeoNerd: I.e. almost any sort of sensor/memory reading
05:02 AM nuxil: rue_bed, Peter Fleury's asm version ?
05:04 AM nuxil: rue_bed, you'll find it here http://homepage.hispeed.ch/peterfleury/avr-software.html
05:04 AM nuxil: manual http://homepage.hispeed.ch/peterfleury/doxygen/avr-gcc-libraries/group__pfleury__ic2master.html
05:04 AM nuxil: err. docs
05:06 AM rue_bed: it must be his that I'm thinking of
05:06 AM rue_bed: http://homepage.hispeed.ch/peterfleury/doxygen/avr-gcc-libraries/group__pfleury__ic2master.html
05:07 AM nuxil: i been using that lib on atiny13/85, atmega88 /324, worked verry nice on all oh thouse chips.
05:07 AM rue_bed: it just makes sense for i2c that start it always issued with address
05:07 AM rue_bed: yep
05:07 AM LeoNerd: Yah; I usually do that sort of wrapping. A "start" function that takes address and direction flag
05:07 AM rue_bed: but should I drag it to stm32?
05:07 AM LeoNerd: Then read and write as just operating on sized buffers, then a no-args stop
05:09 AM rue_bed: things like this send a shivver thru me
05:09 AM rue_bed: while (!((I2C_SR1(i2c) & I2C_SR1_SB)
05:09 AM rue_bed: & (I2C_SR2(i2c) & (I2C_SR2_MSL | I2C_SR2_BUSY))));
05:11 AM rue_bed: a) it locks the processor for the hardware time, b) if it fails, it locks everything
05:11 AM LeoNerd: Yeah; I give little countdown timers in mine and have them return errors
05:11 AM rue_bed: yep, it should be a for loop with a error trip
05:11 AM rue_bed: well, at worst
05:11 AM rue_bed: hmm
05:11 AM LeoNerd: https://paste.debian.net/1016922/ -- is mine
05:12 AM polprog: i2c_errno
05:12 AM polprog: whats this :o?
05:12 AM LeoNerd: Just some variable I use for that sort of thing
05:13 AM polprog: oh
05:13 AM polprog: well i know that. but how dod
05:13 AM polprog: did you implement that
05:14 AM LeoNerd: ... it's just a variable
05:14 AM rue_bed: he did it as an object thats part of the core running it
05:14 AM rue_bed: ;)
05:14 AM LeoNerd: i2c.h: extern uint8_t i2c_errno; i2c.c: uint8_t i2c_errno;
05:14 AM polprog: nice
05:14 AM polprog: i see
05:15 AM polprog: bbl
05:15 AM LeoNerd: Only slight downside is it does waste an entire RAM byte all the time, when perhaps other modules could also share the same errno for their own purposes. Unsure...
05:16 AM rue_bed: this stm32 i2c library looks like a minefield of gotcha
05:16 AM rue_bed: https://github.com/libopencm3/libopencm3-examples/blob/master/examples/stm32/f1/other/i2c_stts75_sensor/stts75.c
05:16 AM rue_bed: look at the read_temperature function
05:16 AM rue_bed: LOOK at that..
05:17 AM rue_bed: proper library functions should NOT result in code that looks like that
05:18 AM rue_bed: i mean geez, why the hell even have hardware i2c then?
05:18 AM rue_bed: thats sure not the hell something a dma can operate
05:19 AM nohitzwork: i would love to get this kind of poster for c64 https://pbs.twimg.com/media/DZPqTy2WAAAMnBF.jpg:large
05:20 AM rue_bed: geez, where was that when I needed it
05:21 AM LeoNerd: I'd almost say that I²C is too slow for a thing that DMA needs; on a CPU that fast otherwise
05:21 AM LeoNerd: SPI maybe
05:21 AM rue_bed: its not about speed, its about unloading the cpu
05:22 AM Haohmaru: blocking wait gets worst on slow bitrates ya know
05:22 AM Haohmaru: SPI ftw
05:23 AM Haohmaru: i still haven't made mine interrupt-driven tho
05:23 AM LeoNerd: Right; but I mean if you cared about nonblocking I²C you'd just handle it one interrupt per byte of transfer, like "normal"
05:23 AM LeoNerd: DMA helps you get _under_ one interrupt per byte, by letting the boring "just shuffle bytes around" be handled by the DMA controller
05:24 AM Haohmaru: in my head, it's not too easy to picture how an interrupt-driven SPI would work, with something like an EEPROM
05:25 AM Haohmaru: the only way i can think of is to basically have a buffer, big enough to store a long command+response, plus a data length variable
05:25 AM LeoNerd: My point is more that on a 72MHz CPU, even 400kHz I²C is only going to need one byte per 400/9 = ~45kHz; so that's one byte per 1600 instructions
05:25 AM LeoNerd: Tiny overhead
05:25 AM Haohmaru: then this buffer structure is one element of a "command/response" FIFO
05:25 AM LeoNerd: Oh; yah.. DMA is for read/write transfers between some one-byte-at-once hardware register and a block of RAM
05:25 AM nohitzwork: see Haohmaru all the files are there
05:25 AM nohitzwork: assembly files for all different mcu's on the f4 series
05:26 AM Haohmaru: yeah
05:26 AM nohitzwork: \Drivers\CMSIS\Device\ST\STM32F4xx\Source\Templates\gcc
05:28 AM rue_bed: I just want to start by talking to a pcf8574, I honestly dont know if I can do it with that library
05:28 AM rue_bed: without stepping in a bucket
05:29 AM rue_bed: and it getting stuck on my foot
05:29 AM rue_bed: and having to walk around pretending it isn't there
05:29 AM LeoNerd: 8574s are lovely :)
05:29 AM rue_bed: with my ears back
05:29 AM LeoNerd: I usually use them for front-panel button / status LED offload
05:29 AM Haohmaru: rue_bed i hate to say it but..
05:29 AM Haohmaru: you have a BED stuck to your back ;P~
05:29 AM rue_bed: LeoNerd, have you with an stm32?
05:30 AM LeoNerd: Hah.. nope. Just 8bit AVR
05:30 AM rue_bed: hmmm
05:30 AM rue_bed: with the hardware or flurrys library
05:30 AM LeoNerd: With my own library; see above
05:30 AM rue_bed: ok, did you bitbang it?
05:30 AM LeoNerd: Nope; hardware
05:31 AM rue_bed: k
05:31 AM LeoNerd: It's easy enough
05:31 AM LeoNerd: I actually have two versions of my library, working to the same .h interface
05:31 AM rue_bed: is the library for doing that SMALLER than flurrys library?
05:31 AM LeoNerd: One for real I²C modules, and one for ATtiny USIs
05:31 AM LeoNerd: 296 src/i2c.c
05:31 AM LeoNerd: ^-- LoC
05:31 AM rue_bed: casue I'v noticed the same with avr, the code to use the hardware is insane
05:31 AM LeoNerd: Hrm.. mine isn't too bad. Let me grab it
05:32 AM LeoNerd: https://paste.debian.net/1016925/ <== whole thing; I²C master on real periph
05:32 AM rue_bed: well, I'm playing with stm32 here, its just a general point
05:32 AM LeoNerd: Oh; and that's even written to cope with dual-master chips like the ATmega328PB
05:32 AM Tom_L: all nighter ehh?
05:32 AM LeoNerd: So it'll do both peripherals
05:33 AM rue_bed: I cant sleep
05:33 AM rue_bed: its 3:30am, I have to be up at 6:15
05:35 AM rue_bed: hmmm
05:35 AM rue_bed: maybe I can SLEEP on this i2c thing...
05:35 AM rue_bed: please????
05:45 AM Haohmaru: get out of bed, it's 06:14!
05:45 AM Haohmaru: RING RING RING RING
05:59 AM MrFahrenheit: LeoNerd, yeah, it can be made nice, the official examples are what makes people think it's hard - they're utter rubbish
06:02 AM MrFahrenheit: https://github.com/puuu/USIWire/blob/master/src/USI_TWI_Master/USI_TWI_Master.c
06:05 AM Haohmaru: how would you implement non-blocking SPI eeprom?
06:05 AM polprog: isrs?
06:05 AM Haohmaru: yeah, but how?
06:06 AM polprog: some buffer
06:06 AM polprog: two ptrs
06:06 AM Haohmaru: i mostly mean the read/write functions, since there you have to potentially be able to handle at least one page of EEPROM in size
06:06 AM polprog: repeat transfer on spi transfer complete interrupt
06:06 AM polprog: i think
06:08 AM Haohmaru: let's say EEPROM page size is 128 bytes, i'd make a struct that can hold 128 bytes + a few more in order to fit a whole eeprom command/response
06:08 AM Haohmaru: you need that twice, because SPI shifts in both directions simultaneously
06:08 AM Haohmaru: and a data length
06:08 AM Haohmaru: then this structure is a FIFO element
06:09 AM Haohmaru: or maybe even one is enough, if you're careful
06:09 AM polprog: one would be enough
06:10 AM polprog: you just swap the bytes as they come and go
06:11 AM Haohmaru: currently, my (blocking) SPI EEPROM code can handle writing variable-sized chunks of data, and it deals with the eeprom page size (so it segments the writes into multiple commands if that's needed)
06:11 AM Haohmaru: it can also detect the eeprom and page size
06:12 AM polprog: nice
06:12 AM polprog: cant wait to get home
06:12 AM Haohmaru: so if i want to keep that, i'll need a FIFO of those structs
06:12 AM polprog: only 2 hours here
06:13 AM Haohmaru: because a single write() can potentially result in two (or more) actual commands
06:13 AM Haohmaru: polprog cd ~/
06:14 AM polprog: :)
06:14 AM polprog: a fifo of the structs
06:15 AM Haohmaru: eggzactly
06:15 AM polprog: so your struct is bunch of data/cmd bytes
06:15 AM polprog: ?
06:15 AM Haohmaru: the struct is just a buffer (big enough to contain the longest-ever single SPI command you'd ever need) plus a data size variable
06:16 AM polprog: okay
06:16 AM Haohmaru: so the size of this structure has to be configured based on the needs, preferably per instance
06:16 AM Haohmaru: smells like templates again
06:16 AM polprog: mm
06:17 AM polprog: i need to read about them..
06:17 AM polprog: templates
06:17 AM Haohmaru: and then make a FIFO out of these structures (poor RAM)
06:20 AM Haohmaru: the inconvenience is then in your main program, having to remember which bytes you need from that buffer
06:20 AM Haohmaru: if you wrote to the eeprom - none
06:21 AM Haohmaru: if you read from the eeprom - then you gotta skip the first bunch of bytes (command bytes) to get to the actual data from the eeprom
06:22 AM Haohmaru: the bigger inconcenience is that you read(); and don't get the data immediately, so you continue doing stuff in main, of course ;P~
06:22 AM polprog: have two arrays
06:22 AM polprog: data and cmd
06:22 AM Haohmaru: then the structure becomes spi device specific
06:22 AM polprog: or a pointer to data start in the command bufer
06:23 AM Haohmaru: even for an eeprom, not all commands are equal in size
06:23 AM Haohmaru: get status reg is 1 byte, read/write is 1 byte plus address offset (two bytes in my case)
06:24 AM polprog: yeah. but whrn you populate the struct you can add that data ptr
06:25 AM Haohmaru: and then, there are some weird SPI slave devices that have certain weird aspects
06:25 AM Haohmaru: but i won't think about those
06:26 AM Haohmaru: oh, my eeprom class can also detect a non-usable (broken, missing) eeprom ;P~
06:26 AM polprog: you cant support every edge case
06:26 AM Haohmaru: yeah
06:26 AM polprog: every odd prom
06:49 AM MrFahrenheit: fookin proms
07:08 AM polprog: stealin our cycles
07:11 AM polprog: make electronics great again
07:13 AM nuxil: no need t make it great again. itsalways been great :p
07:16 AM nuxil: Jartza, where is a good place to order qualtity pla filament ? i was looking a bit on ebay but im skeptic to the quality.
07:19 AM MrFahrenheit: I think seeedstudio sells some
07:20 AM MrFahrenheit: I guess they don't anymore, they used to
07:28 AM Haohmaru: hm, i think my deadline is 6 months
07:29 AM Haohmaru: while (true) { ++skepticism; }
07:30 AM nuxil: MrFahrenheit, well i ordered 300 Meter of pla on ebay.. guess it will be here in 1-2 months or so :p
07:31 AM nuxil: but i was looking for a place in europa with a reasonable shipping time.
07:31 AM Haohmaru: wut's pla?
07:31 AM nuxil: plastic type for my 3d printer
07:31 AM Haohmaru: mm, smells like the perfect chinese product
07:39 AM Haohmaru: nohitzwork what about this: http://arm-software.github.io/CMSIS_5/Driver/html/index.html
07:40 AM Haohmaru: on first sight, that looks promising, but is that just a proposed implementation that is not implemented yet?
07:41 AM Haohmaru: or a proposed API/specification
08:17 AM nohitzwork: dont touch
08:17 AM nohitzwork: you can use c++ with cube
08:17 AM Haohmaru: yes but difficult/one time
08:18 AM Haohmaru: i changed main.c to main.cpp and "it compiles"
08:18 AM Haohmaru: but.. i read somewhere that the program might fail to work
08:19 AM Haohmaru: when C and C++ are mixed within a project
09:18 AM Haohmaru: nohitzwork this? https://github.com/xpacks/stm32f4-cmsis
09:22 AM nohitzwork: what about it
09:22 AM nohitzwork: i need to head home
09:56 AM polprog: you know the Futura typeface
09:56 AM polprog: quite popular, for example Supreme logo is typed with it
09:57 AM polprog: wikipedia shows a pic of a 747 autopilot panel with markings in that gont
09:57 AM polprog: font*
09:57 AM polprog: looks quite nice. if only kicad could load ttf
09:58 AM polprog: Would make nice and stylish front panels
10:08 AM Haohmaru: S T Y L I S H -ish
10:39 AM _kl0wn: anyone recommend any cheap but non shit eprom eraser? :|
10:51 AM MrFahrenheit: a hammer works best, I hear
10:58 AM polprog: if i am thinking right any good source of uv would work
10:58 AM polprog: it takes time though
11:45 AM skz81: Doing / updating my CV web page... I invented a new word : microntroller. I guess that's a troll, but a very tiny one !! :)
11:47 AM antto: utroller
11:49 AM antto: so i read that depending on the "startup code", i may have trouble with global-scope objects and their constructors :/
11:50 AM Ameisen: One thing I've been considering, besides supporting C++ exceptions in embedded
11:50 AM Ameisen: trapping CPU faults and converting them into runtime exceptions to improve resiliency and allow for zero-cost modular forms
11:50 AM Ameisen: that would be more robust
11:50 AM polprog: try { main() } catch {}
11:51 AM antto: i really don't understand exceptions too much, neither on PC, especially not on stm32
11:51 AM Ameisen: that's... not particularly robust.
11:51 AM Ameisen: It would also terminate your execution
11:51 AM Ameisen: for (;;) try { main(); } catch (...) {} would sorta work
11:51 AM Ameisen: still not very robust since you're not handling the fault in any fashion
11:52 AM polprog: i was joking ;)
11:52 AM Ameisen: antto - there's been a number of papers on exception handling compared to C-style error codes in the last 10 or so years
11:52 AM Ameisen: including on embedded
11:52 AM Ameisen: in _general_, exceptions can be both larger and smaller depending on a few factors
11:52 AM Ameisen: performance-wise, exceptions are faster if errors are rare. They're slower if errors are common.
11:53 AM Ameisen: The performance and size of exceptions is fairly dependent on your compiler
11:53 AM Ameisen: The general trade-off most compilers make (like gcc and clang):
11:54 AM antto: all i know about them is that, if anything fails (suddenly throws an exception) it lets your program exit in "not the ugliest way"
11:54 AM Ameisen: with C error codes, you end up with a shitton of branches to check error codes, and then propagate them up teh stack.
11:54 AM antto: like, destructors are called, etc..
11:54 AM antto: but i've no idea how it works
11:54 AM Ameisen: With exceptions, the unwinding code is in a separate section
11:54 AM Ameisen: and gets called when there is an error. There is no 'checking' code littered throughout the program
11:54 AM Ameisen: so, execution of an exception is far slower, but when there are no errors, it's way faster
11:55 AM polprog: with C error codes, you end up with a shitton of branches to check error codes,
11:55 AM polprog: and then propagate them up teh stack
11:55 AM Ameisen: Usually, hanving an unwinding section is smaller than having a bunch of branches
11:55 AM antto: yeah, i do agree that proper code tends to turn into like 80% code which checks for invalid parameters and sh*t
11:55 AM Ameisen: antto - C has unwinding semantics as well
11:55 AM Ameisen: for setjmp etc
11:55 AM Ameisen: same principle
11:55 AM Ameisen: difference is C++ has more things to handle
11:56 AM Ameisen: when unwinding, you are literally moving up the stack to the handler
11:56 AM polprog: that could happen if you do if(error) { ... } else {actual code}. id expect the branch predictor to handle this
11:56 AM Ameisen: so, anything that is going out of scope must be destroyed
11:56 AM Ameisen: polprog - AVR and cheap ARMs don't have branch predictors.
11:56 AM polprog: well, yeah
11:56 AM Ameisen: it also _bloats_ code
11:56 AM polprog: good point
11:56 AM Ameisen: which causes pressure on the icache of higher CPUs
11:56 AM Ameisen: the interrupt handlers don't pressure the icache unless called
11:57 AM Ameisen: err
11:57 AM Ameisen: exception
11:57 AM Ameisen: exceptions are faster when rarely called - in fact, they're zero-overhead when not called
11:57 AM Ameisen: they're not supposed to be used for code flow
11:57 AM Ameisen: they're slow there
11:58 AM Ameisen: One idea I've had is to make sure, on embedded, that Os/Oz is _always_ used for exception handling routines
11:58 AM Ameisen: regardless of flags used elsewhere
11:58 AM antto: in my code, i got a few things which may happen to fail, like, external eeprom, external RTC(calendar)
11:58 AM Ameisen: how often do they fail?
11:59 AM Ameisen: The cutoff is usually somewhere between 5-10%
11:59 AM antto: they should not
11:59 AM antto: ;P~
11:59 AM Ameisen: that is, if a function throws an error > 10% of the time, error codes are faster
11:59 AM Ameisen: otherwise, exceptions are
12:00 PM Ameisen: You can of course hybridize the system where appropriate
12:00 PM Ameisen: a function that can return an error 50% of the time, but one of the codes must be propagated higher and is very rare
12:00 PM Ameisen: handle the common-case codes as error codes, throw an exception for the rare one
12:00 PM antto: but the exception scheme lets you get out of a given function quickly, and then still continue working, right?
12:00 PM Ameisen: yes
12:00 PM Ameisen: so long as you have a handler for the exception
12:00 PM antto: without having a ton of if/else mechanisms to be able to return all the way back
12:00 PM Ameisen: That is a positive/negative
12:01 PM Ameisen: you can ignore error codes/returns. You can't ignore exceptions.
12:01 PM Ameisen: I mean, you could always template the function call for true/false on whether it throws exceptions if you don't care about them in a context, but stil
12:01 PM antto: my point is, if the code somewhere deep f*cks up, you have the chance to break out of there and *detect* that, and then continue doing other stuff, right?
12:02 PM Ameisen: yes
12:02 PM Ameisen: without the chain of branches going all the way up
12:02 PM Ameisen: 15-or-so years ago, compilers generated the branch chain for exceptions, making them not that useful
12:02 PM Ameisen: they don't do that anymore
12:02 PM antto: well that's quite kewl then
12:03 PM Ameisen: though having __attribute__((common)) for a throw statement would be neat
12:03 PM Ameisen: then the exception would use error-code semantics and would be fast in the common case
12:03 PM Ameisen: spec doesn't mandate how the exceptions are implemented, only how they work
12:04 PM antto: so stm32 has exceptions?
12:04 PM Ameisen: GCC and Clang are very similar in implementation, MSVC uses a strange hybrid system on x86-32, and uses zero-overhead on x86-64
12:04 PM antto: or is it up to the code itself
12:04 PM Ameisen: exceptions are a property of the language, not the architecture
12:04 PM Ameisen: you can do exceptions on AVR or even a 4-bit MCU
12:04 PM Ameisen: theoretically
12:04 PM antto: ah right, it's where the avrlibc says that "C++ is supported, minus these things: ... exceptions ..."
12:04 PM Ameisen: the size trade-off is that _usually_ the unwinding code is smaller than all the branch code everywhere
12:05 PM polprog: i was to write a guide on avr and serial but im too tired to think
12:05 PM Ameisen: you'd have to rebuild avrlibc or write your own libc that supports exceptions
12:05 PM Ameisen: basically, it needs unwinding code.
12:05 PM polprog: i wrote a plan of it though
12:05 PM Ameisen: teeeechnically you don't have to
12:05 PM Ameisen: so long as you make no calls THROUGH libc that throw
12:05 PM Ameisen: like function pointers
12:05 PM Ameisen: if you do, things will get sour
12:06 PM antto: Ameisen like, it needs to go all the way back, close all the scopes (put end to the life of each temporary variable/object)?
12:06 PM Ameisen: the unwinding will unwind all the way to a handler that can handle the exception
12:06 PM Ameisen: anything that goes out of scope during that is destroyed
12:07 PM antto: in proper order
12:07 PM Ameisen: yes
12:07 PM Ameisen: that's what the unwinding code does
12:07 PM antto: so what does the try and catch do exactly?
12:07 PM antto: is "catch" the said handler code?
12:07 PM Ameisen: try/catch pair is just wrapping a code segment, saying 'there's an exception handler associated with this'
12:07 PM Ameisen: the catch statement establishes the handler
12:08 PM Ameisen: catch (const blahexcept&) would say 'this handler can catch blahexcept'
12:08 PM Ameisen: if the exception thrown cannot match that, it will go higher and higher in the stack until it either finds one
12:08 PM Ameisen: or doesn't find one
12:08 PM antto: try wraps the code that should be affected into a scope?
12:08 PM Ameisen: not finding one = termination or bad things on embedded
12:08 PM Ameisen: yes
12:08 PM antto: okay, i think i get the picture now
12:08 PM Ameisen: there's other ways to do exception handling as well, this is just the C++-way
12:09 PM Ameisen: MSVC has structured exceptions on the NT Kernel which are 'similar' (and I play with to do some cool things like zlib streaming)
12:09 PM Ameisen: there's also vectored exceptions which NT supports, which are kinda similar to linux signals
12:09 PM Ameisen: Vectored Exceptions are non-scoped
12:09 PM Ameisen: both of those, though, don't unwind
12:10 PM Ameisen: they give you a handler _at the exception_, that you can try to resolve and then resume, or do something else. You could manually unwind, or something.
12:10 PM antto: hm
12:10 PM Ameisen: It's surprisingly difficult to do useful things with those, though
12:10 PM Ameisen: C++ exceptions give a nice semantic requirement that works well with things like object lifetimes
12:11 PM Ameisen: VEH (and SEH which is built upon VEH) is very similar to interrupts.
12:11 PM antto: yeah, then you can exploit RAII to death
12:11 PM Ameisen: Exception handling is just a complex form of code flow
12:11 PM Ameisen: can almost think of it like a goto out of scope.
12:12 PM Ameisen: a safer goto that doesn't break everything.
12:12 PM Ameisen: I haven't experimented with exceptions really on AVR yet, though
12:12 PM Ameisen: there shouldn't be any fundamental limitations, but the compiler might not be very good at it for it
12:12 PM antto: my head hurts from stm32 already
12:12 PM antto: x_x
12:13 PM Ameisen: exceptions should work fine on AR
12:13 PM Ameisen: ARM
12:13 PM antto: i can't find my way still
12:13 PM Ameisen: any of the big, modern architectures support that stuff fine
12:13 PM Ameisen: AVR is just weird
12:13 PM Ameisen: and tends to confuse the compiler
12:13 PM Ameisen: compilers like presuming sizeof(word) >= sizeof(ptr)
12:14 PM antto: word?
12:14 PM Ameisen: sizeof(word) on AVR is 1, sizeof(ptr) is 2 or 3 depending on context
12:14 PM Ameisen: native word size
12:14 PM Ameisen: AVR's native word size is 1 byte
12:14 PM Ameisen: the pointers are 2 bytes or 3 bytes depending on what you're doing
12:14 PM Ameisen: compilers don't like that
12:14 PM Ameisen: invalidates like 90% of their optimizer's assumptions
12:15 PM Ameisen: it has a lot of trouble figuring out how to establish register pairs to do memory access
12:15 PM Ameisen: tends to do it inefficiently
12:16 PM Ameisen: also tends to implement uint16/uint24/uint32/uint64 inefficiently since they use the same memory semantic, which is using adjacent register paris
12:16 PM Ameisen: which is only necessary for memory access
12:16 PM Ameisen: but there's no benefit for implementing large integers
12:16 PM Ameisen: so you end up adding register pressure and sometimes needing to push registers to the stack unneededly
12:16 PM antto: i don't get the asm-related sh*t
12:17 PM antto: *shrug*
12:17 PM Ameisen: ARM has 8-bit registers
12:17 PM Ameisen: memory accesses are 16-bit
12:17 PM Ameisen: err
12:17 PM Ameisen: AVR
12:17 PM Ameisen: without going into super accurate detail
12:17 PM antto: memory as in.. flash/ram?
12:17 PM Ameisen: you can tell the access 'this address is the R0/R1 pair'
12:17 PM Ameisen: yes
12:17 PM Ameisen: or the R2/R3 pair
12:17 PM Ameisen: there's specific pairs, I'm just being general
12:17 PM Ameisen: GCC has common code for larger types to do this
12:18 PM Ameisen: but it uses them for just doing, say, uint16_t
12:18 PM Ameisen: which is unnecessary
12:18 PM MrFahrenheit: I think you're overwhelming antto
12:18 PM antto: he is ;]
12:18 PM Ameisen: https://i.imgflip.com/y29m7.jpg
12:19 PM antto: you brought this pic up too quickly
12:19 PM antto: waaay too quickly
12:19 PM antto: it was planned
12:19 PM Ameisen: https://i.imgur.com/xbTUBzv.jpg
12:30 PM polprog: heh. look at that bbc micro https://youtu.be/IkmFgNUWA4A?t=3m27s
12:30 PM polprog: cute
12:48 PM desperek: polprog, look at these http://microbit.org/
12:48 PM Emil: SIgh
12:49 PM desperek: :D
12:49 PM polprog: desperek: ive seen them
12:49 PM desperek: i've touched them!
12:49 PM polprog: not the same thing :/
12:49 PM Emil: god fucking glibc
12:49 PM polprog: what this time :D
12:49 PM desperek: polprog, tbh setting them up was such a pain in the ass...
12:49 PM Emil: nss and iconv _always_ require dynamic libs
12:50 PM polprog: i thought you hated newlib Emil
12:50 PM Emil: > can't have dns on statically linked builds
12:50 PM Emil: polprog: not talking about newlib
12:50 PM Emil: also never hated newlib
12:50 PM polprog: desperek: were you doing something with those?
12:50 PM polprog: Emil: oh. my bad
12:50 PM desperek: yup polprog
12:50 PM polprog: :P
12:50 PM desperek: i didnt like them
12:50 PM polprog: desperek: cool :D some kind of a school or science club?
12:51 PM desperek: polprog, school science event ! :D
12:51 PM polprog: nice ;)
12:51 PM desperek: i prefer my poor half-fried atmega8 over that tho\
12:51 PM polprog: haha
12:52 PM polprog: microbit is a toy like thingy to teach children programming, avr is a bare microcontroller
12:52 PM desperek: yup
12:52 PM desperek: polprog, though i believe programming is far easier to present when there's just code
12:52 PM desperek: and no special hardware
12:52 PM polprog: indeed
12:53 PM Emil: Well
12:53 PM Emil: it does work though
12:53 PM Emil: the script
12:53 PM Emil: Also updated it a bit
12:54 PM polprog: your linux in a box script
12:54 PM polprog: ?
12:54 PM Emil: yeah
12:54 PM desperek: linux in a box?
12:54 PM Emil: Now I just want the _fooking_ dns working
12:55 PM desperek: aw, i would like freebsd to work ffs
12:55 PM desperek: but "no i dont wanna, dont use me for desktop please!"
12:55 PM Emil: polprog: https://emil.fi/d/spinit/spin.tar.gz
12:55 PM Emil: That is a result of quite many fucking hours of work :D
12:55 PM desperek: wahs that Emil ?
12:55 PM Emil: desperek: wget and see
12:56 PM desperek: oh well this is irc so i wont try!
12:56 PM desperek: also, curl is superior
12:56 PM Emil: you can curl it also
12:56 PM Emil: wget just doesn't require any flags for download
12:57 PM polprog: Emil: rofl https://puu.sh/zQHVF/52cf21ef67.png
12:57 PM polprog: curl'd it
12:57 PM Emil: polprog: wtf
12:57 PM Emil: it shouldn't fucking do that
12:58 PM polprog: and im proud of myself cos i got the tar flags right on the 2nd try!
12:58 PM Emil: polprog: tar -xf file :D
12:58 PM polprog: yea content-type is borked i think
12:58 PM Emil: on my end it downloads
12:58 PM Emil: can you check your headers?
12:58 PM polprog: tar xzf emilslinux
12:58 PM Emil: what's the content type header
12:59 PM desperek: quarter/stream
12:59 PM Emil: quarter?
12:59 PM desperek: oh yea
12:59 PM desperek: quartet
12:59 PM desperek: sorry
12:59 PM Emil: wot
12:59 PM Emil: not octet?
12:59 PM Emil: :D
12:59 PM desperek: nope :D
01:00 PM Emil: wot
01:00 PM polprog: hmm for me
01:00 PM polprog: content-type: text/plain; charset=utf-8
01:00 PM Emil: wtf
01:00 PM polprog: server: nginx theres your problem __endsarcasm()
01:01 PM desperek: Content-Type text/plain; charset=utf-8
01:01 PM desperek: indeed
01:01 PM Emil: Well, now it's served as octet stream by default
01:01 PM Emil: polprog: btfo
01:01 PM Emil: nginx takes apasshit anyday
01:01 PM polprog: lets see if other stuff messes up :D
01:01 PM * desperek chuckles
01:01 PM Emil: probably
01:02 PM polprog: good, /avr still works
01:02 PM polprog: :Dd
01:02 PM Emil: polprog: also nice spoiler, I better do it faster than you :D
01:02 PM polprog: ping.c is returned as application/octet-stream but thats not a problem
01:03 PM polprog: i said i was writing some small thing yesterday if you missed
01:03 PM polprog: :D
01:03 PM Emil: GAH
01:03 PM Emil: I'll add a mimetype for .c
01:03 PM Emil: There we go
01:04 PM Emil: polprog: no I know, just that I should also write the many tutorials I've talked about :D
01:04 PM polprog: Content-Type: text/x-c++src apache does that by default :D
01:04 PM polprog: curl -I polprog.net/papiery/x86/inline_asm/simple.cpp
01:04 PM polprog: ;)
01:05 PM polprog: we should have stuff like that in handy to paste the links here
01:05 PM polprog: your /avr is just genius
01:05 PM desperek: hm, what's better for rss client? rust or go?
01:05 PM Emil: desperek: C
01:05 PM polprog: lol
01:05 PM polprog: i expected taht
01:05 PM polprog: that*
01:05 PM desperek: Emil, no!
01:06 PM Emil: polprog: haha :D
01:06 PM desperek: i wanna something m o d e r n
01:06 PM polprog: what if you need generics
01:06 PM * polprog hides
01:06 PM Emil: polprog: but you are catching up, and people like html so your page will be more pleasant to look at
01:06 PM polprog: thanks
01:06 PM Emil: desperek: then use C17 or something
01:06 PM Emil: or if you want webscale then javascript
01:06 PM Emil: javashit*
01:06 PM polprog: i found a nice balance between the time it takes to set up writing and the time it takes to write
01:06 PM Emil: (I code javashit all the time also)
01:06 PM polprog: wordpress was horrible for that
01:07 PM polprog: i used to code java
01:07 PM desperek: i code in java'
01:07 PM desperek: s script too!
01:07 PM Emil: well there you go
01:07 PM Emil: now change your development style and don't use npm
01:07 PM Emil: or webpack
01:07 PM Emil: or grunt
01:07 PM Emil: or any of those shits
01:07 PM desperek: oh i started like that
01:07 PM desperek: actually
01:08 PM Emil: polprog: you know what I'm approaching in doing
01:08 PM Emil: polprog: LFS/Gentoo
01:08 PM polprog: LFS?
01:08 PM desperek: linux
01:08 PM desperek: from
01:08 PM desperek: scratch
01:08 PM polprog: ah
01:08 PM polprog: nice
01:08 PM desperek: means linux compiles with scratch.mit.edu
01:08 PM polprog: kek
01:08 PM desperek: compiled*
01:08 PM Emil: desperek: LOL
01:08 PM polprog: if scratch is turing complete....
01:09 PM desperek: of course it is
01:09 PM polprog: you could make an x86 emulator there
01:09 PM desperek: im fulltime job in it
01:09 PM Emil: polprog: did you run the script already?
01:09 PM Emil: THere's really nothing else to it
01:09 PM polprog: desperek: https://bellard.org/jslinux/ and https://copy.sh/v86/
01:09 PM Emil: just tarrrrrrrrr -xf (script, if you want to log everything which I do) and ./spin
01:10 PM polprog: Emil: sure, just a sec
01:10 PM desperek: oh my
01:10 PM polprog: curl | tar | sudo bash :D
01:10 PM Emil: tar -xf && script && ./spin
01:10 PM Emil: polprog: I dare you :D
01:10 PM Emil: except it doesn't work
01:10 PM Emil: since the tar file contains directories
01:10 PM Emil: well just one
01:11 PM polprog: jq command not found on line 20
01:11 PM polprog: whats that
01:12 PM desperek: eh
01:12 PM desperek: i should develop my site
01:12 PM desperek: i guess
01:12 PM Emil: polprog: check the dependencies
01:12 PM Emil: polprog: at the beginning of the file
01:13 PM polprog: ikr
01:13 PM Emil: sudo apt install jq
01:13 PM polprog: whats jq
01:13 PM polprog: for?
01:13 PM Emil: it's a json parser, because the fucks at kernel.org don't provide a proper link to the latest stable
01:13 PM Emil: but provide kernel.org/releases.json
01:13 PM polprog: okay
01:14 PM Emil: So instead of manually parsing that, which I could have done, I just used jq :D
01:14 PM polprog: it downloads more stuff. my kernel image just had busybox installed
01:14 PM desperek: is lead conductive?
01:15 PM polprog: like every metal yes
01:15 PM Emil: polprog: it downloads kernel, busybox, musl and vash
01:15 PM Emil: bash*
01:15 PM polprog: menuconfig craps out.. i shouldhave installed curses
01:15 PM Emil: ayy
01:16 PM Emil: wait so why did I change my default mime type
01:17 PM Emil: ah yeah
01:17 PM Emil: .tar.gz
01:17 PM polprog: qemu: could not load kernel '/home/plpg/Desktop/latestvm/build/linux/arch/x86_64/boot/bzImage': No such file or directory
01:17 PM polprog: ayy
01:17 PM MrFahrenheit: <3 rust
01:17 PM MrFahrenheit: it makes hard things easy
01:17 PM Emil: polprog: lies, you did not compile it that quickly
01:17 PM MrFahrenheit: but in turn makes easy things hard
01:17 PM polprog: it did
01:17 PM Emil: lies
01:17 PM MrFahrenheit: so it's a tradeoff
01:17 PM polprog: just menuconfig didnt run so its some uber minimal version
01:18 PM Emil: polprog: you either missed dependencies, had failed targets or something
01:18 PM MrFahrenheit: also, polprog, are you writing html, or just hardcore browsing?
01:18 PM polprog: Emil: ./usr/bin/lsusb
01:18 PM polprog: fack
01:18 PM polprog: https://puu.sh/zQIHk/b236a0d464.png
01:19 PM polprog: MrFahrenheit: writing html
01:20 PM Emil: polprog: install: sudo apt-get install libncurses5-dev gcc make git exuberant-ctags bc libssl-dev
01:20 PM Emil: https://kernelnewbies.org/KernelBuild
01:20 PM polprog: ikr, i was about to build one yesterday
01:20 PM Emil: that's why I recommend using script
01:20 PM Emil: so you can see where it crapped out
01:21 PM Emil: Now onto adding getty
01:21 PM Emil: After that I'll fix the fucking dns
01:21 PM Emil: Also I could add strace and htop
01:21 PM polprog: the internet one or something different
01:22 PM Emil: hm?
01:22 PM polprog: dns
01:22 PM polprog: also
01:23 PM polprog: shoud i build busybox static or will it link against the new kernel?
01:23 PM Emil: static
01:23 PM Emil: and that's not what non static means
01:23 PM polprog: i never linked against a custom [not running] kernel
01:23 PM Emil: basically I'm (like pretty much everyone) links against your normal kerne
01:23 PM Emil: "links"
01:24 PM Emil: because it's abi calls
01:24 PM Emil: the real issue is dynamic libs
01:24 PM Emil: and linking against those
01:24 PM MrFahrenheit: I prefer lynx
01:24 PM polprog: okay
01:24 PM Emil: which is why you must select settings -> static build
01:24 PM polprog: did that
01:24 PM Emil: on busybox menuconfig
01:24 PM Emil: I tried fucking automating that
01:25 PM Emil: but apparently STATIC=y like it fucking says on the menuconfig page is not enough to make busybox linked statically :D
01:25 PM Emil: if anyone knows please do share
01:25 PM Emil: what's the correct magic word and where to fucking put it
01:25 PM polprog: like -Wall -Wextra
01:25 PM Emil: to have busyshit link statically
01:25 PM Emil: polprog: these are build options that you must pass on a higher level
01:26 PM polprog: Emil: my i3 is chooching at full speed
01:26 PM polprog: i meant that one would think -Wall enables all warnings, which is not the case
01:26 PM polprog: odd. same
01:26 PM polprog: no such file
02:05 PM Emil: did you get it working?
02:07 PM polprog: not yet. it still fails on the initrd fike
02:07 PM polprog: file*
02:07 PM polprog: im making coffe right now. ill be back in a sec
02:13 PM polprog: allrighty
02:13 PM Emil: okay so whatthefuck
02:13 PM Emil: htop thinks ncurses libs are missing :D
02:13 PM polprog: qemu: could not load kernel '/home/plpg/Desktop/latestvm/build/linux/arch/x86_64/boot/bzImage': No such file or directory
02:14 PM polprog: did you manage to actually boot it?
02:14 PM Emil: yeah
02:14 PM Emil: of course
02:14 PM polprog: i cant :/
02:14 PM Emil: do:
02:14 PM Emil: script
02:14 PM Emil: ./spin
02:15 PM Emil: ctrl+d
02:15 PM polprog: okay
02:15 PM polprog: could have told me to provide a log ;)
02:15 PM polprog: just simply
02:15 PM polprog: ;)
02:19 PM Emil: Okay so
02:19 PM polprog: https://puu.sh/zQKV4/328bed9a54.txt
02:19 PM polprog: too fast
02:19 PM Emil: This is literal cancer
02:19 PM polprog: somethigns wrong
02:20 PM Emil: linking statically is made almost impossible
02:21 PM Emil: WHY IS THIS SO FUCKING CLUSTERFUCK AND RETARDED GAHAHHTEAHSGHSGDHHHSGAHHGASDGHASDHGREEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
02:21 PM polprog: exit(1)
02:21 PM polprog: ^^^
02:21 PM Emil: that doesn't get it done :D
02:22 PM antto: wut?
02:26 PM polprog: bbl
03:03 PM Emil: polprog: did you get it working? :D
03:03 PM polprog: nope. i had to teach chemistry to my sis
03:03 PM polprog: in fact i just sat at the keyboard
03:03 PM antto: is he exploiting you to test his code again?
03:04 PM Emil: no
03:04 PM Emil: :D
03:04 PM Emil: I know it works on my system
03:04 PM Emil: just wanted to share
03:04 PM antto: of course you'll say "no" >:/
03:04 PM polprog: heh
03:04 PM * polprog runs "ps -A | grep bitcoin" on his system just in case
03:05 PM antto: do you feel like a sandbox? ;P~
03:05 PM polprog: antto: dont worry, ill make him run my radar code when i finish it
03:05 PM polprog: both the avr part and the GTK gui
03:06 PM antto: ooh, sounds like two attack vectors
03:06 PM antto: Emil u so pwned!
03:06 PM Emil: antto: no, because I'll run the code inside the vm :D
03:07 PM antto: i'm sure polprog is using some spectre tricks
03:07 PM antto: he gon meltdown yer VMs and sh*zzle
03:07 PM polprog: the gui pops out a notice that lp0 is on fire
03:07 PM polprog: when emil goes to check it then i sneak into his lab and steal all the cool gear,
03:07 PM polprog: but sshh
03:08 PM antto: i won't tell him
03:08 PM polprog: thanks :D
03:08 PM antto: tell me when you're doing this, i'll distract him with some C++ stuff
03:08 PM polprog: :P
03:10 PM antto: hey Emil, check this out! this C++ code here compiles into LESS instructions than what you can do in C or even ASM, ha!
03:10 PM antto: ;P~
03:11 PM antto: the most optimal C/ASM code turns into one instruction, the C++ code turns into 10 times faster!
03:13 PM Emil: mfw you could have totally done that earlier when I had actions on ignore :D
03:13 PM Emil: also even if c++ was more efficient that c I wouldn't use it
03:15 PM * antto puts -std=c++11 into all of Emil's makefiles
03:16 PM Emil: gotchabitch!
03:16 PM Emil: I don't use makefiles!
03:17 PM polprog: gcc *.c
03:18 PM * antto replaces Emil's compiler with bash scripts which calls the compiler but injects -std=c++11 into the arguments
03:18 PM * antto throws away Emil's root password
03:29 PM MrFahrenheit: "the C++ code turns into 10 times faster!"
03:29 PM MrFahrenheit: I love when my code turns into faster
03:30 PM antto: just hide it from Emil coz he'll be annoyed ;P~
03:31 PM MrFahrenheit: he won't, it's c
03:31 PM MrFahrenheit: (and rust)
03:32 PM antto: then it's probably slow ;P~
03:32 PM * antto runs
03:33 PM MrFahrenheit: it's io bound
04:08 PM polprog: hmm
04:08 PM polprog: ill continue tomorrow
04:08 PM polprog: niters
04:22 PM Emil: good night
05:10 PM Ameisen: [15:08:50] <antto> hey Emil, check this out! this C++ code here compiles into LESS instructions than what you can do in C or even ASM, ha!
05:10 PM Ameisen: humans write some pretty shitty asm sometimes
05:11 PM Ameisen: more importantly, I've seen the compiler put out assembly that... is something I never would have written, but is faster than what I would have.
11:59 PM day__ is now known as day