Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
Zarutian_HTC has quit [Quit: Bye]
<tabemann> back
<tp> tabemann, only 8pm! you finish tea early ? ;-)
<tabemann> lol
<tp> I installed debian 10.4 last night on a spare pc so I could compile blackmagicprobe
<tp> debian failed at the HDD and asked me for a ISCSI and Im like WTF, and cursed it to high hell
<tp> then I had an epiphany and looked inside the pc ... no hdd <doh>
<tp> after that it was plain sailing, compiled BMP and it's working. Im just about to add RTS so I can use the virtual terminal for my serial connection
<tp> but I gotta say, the C code in that is pretty frightening, I've no idea how people actually work with that stuff
<tp> laced with library stuff and conditionals for every stm mcu under the sun
<tabemann> crest: you need to get rid of that warning stuff
<crest> i did
<tabemann> that's what I ran like one minute ago
<crest> have you pulled in the last few minutes?
<tabemann> yeah, it's up to date
<crest> did you change anything e.g. delete time.h?
<tabemann> cc -O2 -pipe -std=c99 -Wall -Wextra -Wno-unknown-pragmas -I/usr/local/include -I/usr/local/include/stlink -I/usr/include/libusb-1.0 -L/usr/local/lib -o swd2 swd2.c -lstlink
<crest> i think i found the problem
<crest> linux requires sys/timespec.h
<tabemann> I just changed -lstlink-shared to -lstlink and added -I/usr/include/libusb-1.0
<crest> tabemann: please try again
<tabemann> I got the problem
<tabemann> it's --std=c99
<crest> why is that a problem?
<tabemann> gcc doesn't define struct timespec by default when that's set
<crest> it does on freebsd because the system headers a different
<tabemann> why I haven't a clue
<crest> let's add the required includes and keep -std=c99
<crest> but why isn't sys/stat.h enough to define S_IFMT and friends?
<crest> let's add sys/types.h
<tabemann> I say strip out everything not essential to compiling the code
<tabemann> warnings, standard settings, defines, all of it
<crest> please try again
<tabemann> no, it doesn't like sys/timespec.h
<crest> which operating system are you running?
<tabemann> Debian
<tabemann> the official solution is to add a particular define
<tabemann> but I'd rather just eliminate -std=c99 because it's unnecessary
<crest> guess i have to spin up a debian vm
<crest> the defaults are gnu89 or gnu99 depending on the gcc version
<crest> and i really don't want to support c89 or gnu89
<tabemann> this is what I had to execute to make it all work:
<tabemann> cc -O2 -pipe -std=c99 -D_POSIX_C_SOURCE=199309L -D_DEFAULT_SOURCE -Wall -Wextra -Wno-unknown-pragmas -I/usr/local/include -I/usr/local/include/stlink -I/usr/include/libusb-1.0 -L/usr/local/lib -o swd2 swd2.c -lstlink
<tabemann> damn you gcc and damn you glibc
<tabemann> and damn you debian
<tabemann> -D_DEFAULT_SOURCE was needed for the S_IFMT stuff and usleep
<crest> that breaks the build on freebsd
<crest> which operating systems are the broken ones?
<tabemann> on the other hand, eliminating -std=c99 eliminates the need for those defines
<crest> damn it i followed the opengroup docs
<tabemann> so then the only thing that should break freebsd is the use of -lstlink
<crest> which stlink version did you install?
<tabemann> I'm on 1.6.0 right now
<tabemann> compiled from source
<crest> okay because i'm still on 1.5.0
<crest> because 1.6.0 was never packaged for freebsd
<crest> and 1.6.1 is too broken
<tabemann> it's 1.6.1 which breaks things horribly, not 1.6.0
<crest> yeah 1.6.1 is an embarrassing release
<tabemann> it's embarrasing that the developers defend it pointlessly
<crest> well they explained how it happend
<tabemann> like seriously, if you don't want people using your shared library... don't make one
<tp> but stink has a 'code of conduct' !!! so theyre the best!
<tabemann> codes of conduct can go to hell
<crest> tp: please let's not start this flamewar
<crest> a code of conduct has valid uses
<crest> but it can't replace quality code
<tp> tabemann, I'm with you here
<tp> ill leave you guys to it
<tabemann> codes of conduct don't replace being a developer who listens to one's users, who tries not to break things, who fixes things when they inevitably get fucked up, who is not a stuckup asshole, and so n
<tabemann> anyways
<tabemann> saying "we don't support X" to every complaint reflexively is a good example of the kind of thing that gets me, code of conduct or not
<tp> ok I found where to add RTS flow control to BMP
<tp> almost there
<tabemann> BMP?
<tp> tabemann, times have changed, once FLOSS developers would respond with thanks for a bug report and fix it right away
<tp> Blackmagic probe
<tabemann> ah
<tp> tabemann, it uses libopencm3
<tp> tabemann, and at least it compiles under debian 10
* tabemann would be happy that someone was actually using his software to the point that they could produce a bug report
<tp> tabemann, it fails badly under FreeBSD and openindiana
<tp> tabemann, exactly
<tp> once I have RTS on the BMP then I have a virtual term plus a virtual gdb server on the one USB connection
<tp> and it's ready to use in my existing system
<tp> no need for stlink or swd on the pc
<tp> all I need on the pc is gdb etc
<tp> then my bluepill equivalent simply replaces my $0.99 usb-3.3v dongle
<tabemann> right now the only issues I'm having are that I can't use stlink 1.6.1
<tabemann> I haven't had any problems with serial aside from the lack of RTS/CTS
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
<tp> well you have your ack/nak thingie ?
<tp> you dont need CTS on the target, all thats needed is RTS
<tabemann> ack/nak works fine for me with e4thcom
<tp> the target cant send faster than a PC can receive
<tp> do you want RTS ?
<tp> I'll get it going on the F407 if you want it
<tabemann> the problem is that the USB-serial dongle I have doesn't support RTS anyways
<tp> oh yeah
<crest> tp: or just ignore the bug report
<tp> I forgOt
<crest> and close it years later as "overcome by events"
<tp> crest, what are you on about ?
<tabemann> <tp> tabemann, times have changed, once FLOSS developers would respond with thanks for a bug report and fix it right away
<tp> well times have changed
<crest> e.g. mozilla has bugs that are over a decade old and still not fixed
<tp> people used to develop because they loved it, now many just want to be leet and cool programmers
* tabemann programs for his own purposes because he likes creating stuff, while he programs at work because he needs a job
<tp> crest, mozilla was always like that iirc, hardly a bastion of dedicated programmers, probably too commercial and always pushed to deliver with short timeframes ?
<tabemann> my job is all about short timeframes
<tp> tabemann, yeah your hobby work is awesome, youre easy to work with and consider all comments
<tp> tabemann, sign of the times at work ?
<tp> at least here on #forth people care about good programming, good code :)
<tabemann> at work they have the philosophy that if they set an amount of time to be set in a period, it will get done regardless of how big or small that period is, so they might as well make it really small so they can get more stuff done
<crest> FUZxxl reviewed my terminal.s and came up with a patch to decrease the code size even further
<tp> #forth keeps the old ways alive
<tp> crest, cool1
<crest> it made the code slightly harder to read
jedb has joined #forth
proteus-guy has quit [Remote host closed the connection]
* tabemann doesn't exactly understand what uxtb does
<tp> crest, have you considered using the blackmagic probe code on a bluepill as am all in one interface for swdcom ?
<crest> the 16bit version zero extends the lower 8 bits of the source to 32 bit
<tp> am = an
<crest> tp: i haven't looked at the blackmagic code
<tp> crest, that way people wont need to compile swdcom for their os
<tp> crest, it has the swd (and jtag) stuff
<tabemann> the thing with the blackmagic probe is that it requires separate hardware
<tabemann> i.e. the probe itself
<tp> crest, in fact you could do the swd interface to a virtual com port and people could just use a serial terminal of their choice
<tabemann> like I'd have to go and buy a blue pill and then arrange for it to be flashed
<tp> tabemann, thats true and one downside
<crest> it would be nice to use a blue pill as usb modem for swdcom
<crest> but reusing the stlink/v2 has other advantages
<tp> crest, but youll probably need debian to develop it
<tp> crest, and once developed you can reflash a stlink/v2 with the binary
<crest> it allows me to have a single always connected device that's used as console and programmer
<tp> tabemann, that's the other option, the binary can reflast the SWD programmer on a discovery or nucleo
X-Scale` has joined #forth
<tp> tabemann, so you wouldnt need a bluepill at all
<crest> and writing to flash requires a lot deeper knowledge about the chip than swdcom and its terminal.s
X-Scale has quit [Ping timeout: 258 seconds]
<tp> sure
X-Scale` is now known as X-Scale
<crest> as far as i can tell it stlink flashs the device by writing a bootloader into sram
<tp> ththe BMP has a virtual GDB server and you can flash with that
<crest> and one of the goals of swdcom was to get a fast "universal" console
<tp> crest, only on V2.1
<tabemann> back
<crest> ?
<tp> crest V2 just uses the on board stm32f103 swd interface to flash
<tp> crest, V2.1 does the ram upload stuff
<tp> V2.1 is crap, I wont use it
<crest> i use the stlink v2-1 on the nucleo
<tp> it's all about DND flashing for GUI users
<tabemann> that's what they must've broken
<crest> and a stlink clone for the for blue pill
<crest> tabemann: yes
<tp> sadly STM is catering for arduino users now
<crest> they added support for new chips and broke some (most?) already supported chips
<tp> I guess if it sells ....
<tabemann> isn't that what nucleo is?
<crest> with usb mass storage upload?
<tabemann> (i.e. trying to cater to the damned arduino people)
<tp> tabemann, yeah, plus nucleo is absolutely min cost
<tp> I looked for a STM programming example for their TSC touch screen sensor recently, the current one is all GUI, no real code
<tp> it's all click this setting, click that setting, click build, flash to target
<tabemann> I hate looking for source examples online
<tp> yeah, it's difficult
<tabemann> because it's all "use this API" or "use that API"
<tabemann> when I want to see "write into these bits in that register"
<tp> i find the best (tho often incomplete) examples are at the very end of the STM technical reference manuals
<crest> AAAARRRGGGHHHHH
<tp> theyre in C, but it's readable
<tabemann> was ist los?
<tp> ahh, finally building the Libopencm3 doc on the debian box
<tp> it's all well and good having libraries but if there is no API doc, one cant use them!
<crest> i'm tempted to go looking for the openocd ftdi232h code implementing swd
<crest> and use that in bitbanging mode
<tp> crest I believe FTDI have a free but closed JTAG library
<tp> rdrop-exit here uses it
<crest> looks like someone else came up with a similar idea: https://www.segger.com/products/debug-probes/j-link/tools/j-link-swo-viewer/
<tabemann> right now I'm just going to stick with 1.6.0
<tabemann> everything else seems more complicated and more difficult
<crest> but it looks like this uses optional parts of the debug hardware
<crest> and its unidirectional
<crest> just target -> host
<tabemann> yeah everything seems like either doesn't do everything we'd want, or is more elaborate, or requires purchasing more hardware and configuring it, or all of the above
<crest> i'm not against purchasing hardware as long as it isn't to expensive or hard to get
<tabemann> my problem is not the money but the wait
<tabemann> and I don't want to spend even more money on amazon prime
<crest> e.g. a ftid232h cable wouldn't be too hard to get (in germany)
<crest> gn8
<tabemann> unless it has a counterfeit chip in it, and ftdi's next windows update bricks it
<tabemann> nacht
<tp> yeah, counterfit is a real problem
<tabemann> and ftdi's bricking of counterfeit chips is why I won't buy from them
<tp> that was the stupidest move ever, it hurt them badly
<tp> the BMP has all kinds of SWD tips, even a SWD reader
<tp> I think it's worth a look
<tp> and genuine STM32F103s can be bought via various reliable channels
<tp> just not on ebay or aliexpress
<tp> I have 20 brand new genuine STM32F103's
<tabemann> i.e. one of STMicroelectronic's official dealers
<tp> tabemann, right
<tp> but mouser, avenet, arrow electronics are all reliable
<tabemann> yes]
<tp> just dont buy from asian companies if you dont want fakes
<tp> my STM32F103's came from AVENET
<tp> in texs
<tabemann> buy from companies who source their components directly from STM
<tp> Texas
<tp> yes, as you say one of STMicroelectronic's official dealers
<tp> ok rebuilding BMP with RTS enabled on the usart, will it work ?
<tabemann> we shall see!
<tp> it's abig build
<tp> C stuff is MASSIVE
<tp> the code is like a mad womans breakfast
<tp> how doe people work with this stuff, it cant be any fun
<tp> I feel tainted already
<tabemann> how does it even fit on an f103?
<tp> it needs 100KB of flash
<tp> and they all have 128 even if they dont advertise it
<tabemann> ah
<tp> so plenty of space
<tabemann> I was wondering, I thought the f103 had 64K of flash
<tp> the R8 model has 128KB
<tabemann> I see
<tp> but so does the 64 KB model, it's the worst kept secret
<tp> at some point STM used the die from the larger model in the smaller model and then set the flash size register to 64KB instead of 128KB
<tp> thinking no one would notice
<tp> and apps like stlink read that register so it think that only 64KB is available
<tabemann> cheaper for them than actually having to maintain two sets of masks
<tp> one just changes the stlink config
<tp> exactly
<tp> build hasnt bombed yet :)
<tabemann> good luck...
<tp> the debian machine is on a dual core amd slowpoke 'hp-miniserver'
<tp> well I followed the API that it was built with
<tp> honestly, it's so easy to configure RTS in assembler, I dont see the purpose for all this massive C palaver
<tp> easier in Forth
<tabemann> it's because stuff in C tends to be overengineered
<tp> but Ive learnt a lesson, build Linux stuff on a Linux pc, it's infinitely easier
<tp> forget trying to cross build, it's a frigging nightmare
<tp> especiall where Linux is involved
<tabemann> and I've learned from trying to build crest's code that trying to compile FreeBSD code on Linux is a nightmare
<tp> Exactly
<tp> it's a road to madness
<tabemann> even though I don't get why he insists on some things like -std=c99 and all the warnigns
<tp> thats why I recommend a BMP for his idea
<tp> no OS involvement
<tp> you just flash a binary to a blue pill (or equivalent, and there are plenty) and it's done
<tabemann> his code works fine provided one set up the proper build settings (no -std=c99) and one uses 1.6.0 not 1.6.1
<tp> thats why the BMP exists, people on windows, linux,mac,bsd all had trouble with openocd and gbd etc
<tp> one BMP fixed all those problems
<tp> hah it built!
<tp> now to test!
<tabemann> cool
<tp> Im thinking of moving to openindiana ... because I like it so much, but no stlink or openocd. But with a bmp I dont need them
* tabemann is sticking with Debian because there are certain programs he uses (e.g. Discord) that he isn't sure would be available on BSD or openindiana
<tp> oh yeah, all good reasons
<tp> I have a Linux box for Linux stuff now and Im keeping it as is
<tabemann> I don't like change when it comes to computing environments
<tabemann> okay, I'm falling asleep so I'm gonna hit the sack
<tabemann> g'night
<tp> night0!
_whitelogger has joined #forth
jsoft has joined #forth
jsoft has quit [Ping timeout: 260 seconds]
dddddd has quit [Ping timeout: 256 seconds]
crest has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
crest has joined #forth
gravicappa has joined #forth
_whitelogger has joined #forth
mtsd has joined #forth
andrei-n has joined #forth
xek has joined #forth
reepca has quit [Read error: Connection reset by peer]
WilhelmVonWeiner has joined #forth
proteus-guy has joined #forth
jsoft has joined #forth
<veltas> yunfan: FreeBSD or NetBSD or something uses Forth in its boot sequence
<tp> veltas, not any more, freebsd 12.2 uses LUA
<veltas> Booting from U-Boot should be quite easy, depends what you want to do though
<veltas> tp: makes sense
<yunfan> veltas: i want a full feature forth
<yunfan> veltas: also there were cellphone bootloaders, could a forth be boot by it?
iyzsong has joined #forth
<veltas> yunfan: u-boot is available on a very wide variety of systems, which one are you using?
iyzsong has quit [Quit: ZNC 1.8.0 - https://znc.in]
<yunfan> veltas: i am playing many boards :D
<veltas> What architecture?
<yunfan> pine64 a64/cubieboard2 rpi zero
<yunfan> also i have a csky board
andrei-n has quit [Ping timeout: 246 seconds]
jsoft has quit [Ping timeout: 246 seconds]
mtsd has quit [Quit: Leaving]
andrei-n has joined #forth
dddddd has joined #forth
jedb has quit [Ping timeout: 258 seconds]
jedb has joined #forth
tangentstorm has quit [Changing host]
tangentstorm has joined #forth
jedb has quit [Ping timeout: 260 seconds]
Zarutian_HTC has joined #forth
dave0 has joined #forth
xek has quit [Ping timeout: 265 seconds]
andrei-n has quit [Remote host closed the connection]
gravicappa has quit [Ping timeout: 246 seconds]
TCZ has joined #forth
TCZ has quit [Quit: Leaving]
Rakko has joined #forth
dys has quit [Ping timeout: 246 seconds]
clog has quit [Ping timeout: 264 seconds]
clog has joined #forth
Rakko has quit [Quit: Leaving]
<tp> in desperation I just asked for help on the libopencm3 irc channel
<tp> man ... is embedded C hard, it's amazing that people use it at all
<tp> everything is utterly abstracted away, it's a desert as far as hardware deatils are concerned
jedb has joined #forth
dave0 has quit [Quit: dave's not here]