<tabemann> hey guys
<tp_> crest wow!
tp_ is now known as tp
<tp> hi tabemann
<crest> tp: turns out the stm32l476-ra config doesn't match the nucleo board
<crest> the serial console doesn't work
<tabemann> the stm32l476 configuration is for the discovery board
<crest> tabemann: exactly
<tabemann> and it's unfortunate that you bought the nucleo board
jedb has joined #forth
<crest> i suspected as much from some of the comments
<tabemann> as for that same reason you won't be able to use zeptoforth without doing some porting work
<crest> it should be as simple as fixing the serial port setup or are there any other problems lurking after that?
<tabemann> because it's the same MCU, the flash controller should be the same
<crest> guess i have to study the datasheets first and figure out how to get USART2 mapped to PA2 and PA3
<crest> instead of PD5 and PD6
<tabemann> if you could just use a serial dongle and jumper cables
<crest> looks like those pins aren't exposed on the headers
<tp> crest that why the support hardware says "STM L476 Discovery"
<tp> crest it will only be a few changes to the assembly for a different usart
<crest> or i could port the swdcom bootstrap code to assembler on the blue pill
<crest> tp: just ther alternate function setup
<crest> to route usart2 to the right expected pins
<crest> but i'm not yet familar with the chip
<tp> crest, maybe it's just on different pins ?
<crest> maybe
<crest> i don't know
<tp> crest I'll grab the schematic and have a look
<tp> it's only a very minor issue
<crest> and because of that i'm thinking about porting the swdcom forth code to assembler
<tp> definitely no showstopper
<tp> wow, thats even better
<crest> but so far i have just written two instructions of thumb2 assembler and assembled those manually
<crest> to write >r11 and r11@
<tp> USART2 PD5 PD6 and the USB had a virtual com port
<tabemann> I'd prefer that approach, so that I don't have to change the zeptoforth kernel to support swdcom
<crest> that much i discovered in the getting started guide
<crest> tabemann: but a working serial port is still useful
<tp> so looks like PD5 PD6 to your 3.3v dongle and youre in business
<tabemann> crest: yes, you want a working serial port
<crest> but i didn't find a proper schematic for the board
<tp> oops thats on the discovery!
<tabemann> tp: crest is saying those pins aren't exposed on the Nucleo
<tp> yeah the bloody nucleo schematics are a damn disgrace
<crest> tabemann: no. i said i haven't found if they're routed to any pin
<tabemann> ah
<tp> tabemann, aha, I'm still looking for the schematic
<tp> the nucleo schematics are likely the worst schematics Ive ever seen in my life
<tp> thats how bad they are
<crest> this is what i've found so far: https://os.mbed.com/platforms/ST-Nucleo-L476RG/
<crest> tp: what makes them so much worse than the discovery boards?
TCZ has joined #forth
<tp> the discovery boards arent much better
<tp> they are both utterly usless
<tp> someone who knows nothing aboyt electronics did them
<crest> ?
<crest> that's not very precise
<crest> holy shit the reference manual has >1800 pages and 30MB
jedb has quit [Ping timeout: 264 seconds]
<crest> and is written in the same style as the old stm32f103 documention
<Zarutian_HTC> tp: what were the signs for that? just curious
<crest> looking for the instruction sequence required to configure some piece of the chip feels like a game of whack a mole
jedb_ has joined #forth
<crest> it almost feels like a DDoS attack on newbies
<Zarutian_HTC> or some overzealus IP defender got into the documentation making
TCZ has quit [Quit: Leaving]
<tp> back, phonecall
<tp> Zarutian_HTC, signs for what ?
<tp> crest, Ive learnt to LOVE the stm manuals, theyre a class above anything else Ive seen
<Zarutian_HTC> tp: that the board was done by someone clueless about electronics
<tp> Zarutian_HTC, ah. the fact that they dont atually draw a schematic is the clue
<tp> the discovery and nucleo schematics arent actually schematics
<Zarutian_HTC> tp: then you havent come across panasonic troubleshooting and service manuals. Those are quite goodþ
<tp> theyre a ah hoc list of signals placed on the page
<Zarutian_HTC> just, "pin 4 has these as possible signals" kind of list?
<tabemann> back
<crest> would it kill them to export the eagle/kicad/whatever files into pngs and pdfs?
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
<Zarutian_HTC> crest: probably
<Zarutian_HTC> there is one manifacturer that uses the internal hyperlink feature of pdf extensively and does it well
<Zarutian_HTC> click on a signal name on the schematic and you get the section on how to make it accessible
<Zarutian_HTC> that is show up on the pin
<tp> Zarutian_HTC, this is a schematic and pcb I did over 20 years ago https://mecrisp-stellaris-folkdoc.sourceforge.io/pcb.html#old-riaa-amp
<tp> thats what I know as a schematic
<tp> crest, youre right, theyre terrible, I will probably draw up a nucleo schematic soon
<tp> if each pin doesnt have a wire joining it to another pin(s) it's not a schematic, it's a list of signals
<tp> the schematic and pcb are all made by OSS apps btw
<tp> the original gEDA
<Zarutian_HTC> tp: the internal layout wasnt down to resistor, caps and transistors at that level. Think very detailed block diagram. The outlines of the blocks were hyperlinks to those kind of schematics in the document
<tp> Zarutian_HTC, gEDA has sub pages
<tp> thats nothing new
<Zarutian_HTC> otherwise you would get an A0 sized page were all the text is 6p and schematic symbols of equiv size
<tp> of course, but that was solved at least 20+ years ago, probably 40
<tp> depending on what package one used
<Zarutian_HTC> sure, but I hadnt seen the link usage and such in a pdf datasheet
<tp> ahh , good point :)
<Zarutian_HTC> schematic files sure but not this well done in a datasheet pdf
<tp> crest: TX is on PA2, RX on PA3
<crest> i know
<crest> that much is documented in the getting started guide in the section for the virtual com port
<crest> the problem is that mecrisp uses a different pin that isn't exposed on any of the headers
<Zarutian_HTC> and the component BOM list highlighting in board layout diagrams made troubleshooting breazy
<crest> table 16 of the datasheet tells me that PA2 / PA3 are an option as well
<tp> crest, ok, looking into it
<crest> it don't know enough about the i/o subsystem to fix this (yet)
<crest> i have to learn about the multiplexer connecting alternate functions to gpio pins
<tp> crest, looks like there is no PDx
<crest> there is in the reference manual
<tp> yeah of course, the ref manual covers all types of package
<crest> the nucleo board is confusing because it looks like they're reusing the arduino pin names for the arduino connectors
Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
<tp> but if the mcu in the nucleo is a small pinout package, it may not have enough pins to bring out port
<tp> D
<tp> crest, the nucleo is STMicros effort to support arduino
<tp> so it has arduino daughter board headers' and the old stm32 headers
<tp> it's also the the cheapest possible pcb as evidenced by the criminal lack of silk screening for pins
<tp> I have one myself
<crest> i'm just a programmer with no idea about PCB design
<crest> why is the silk screening so important?
<tp> so you can see the number of the pin you want to plug a wire onto
<tp> unless you like counting pins
<tp> all the discovery board pins are labelled
<tp> in comparison
<tp> I understand why they cut corners, afterall the nucleo is very cheap for what it offers
<tp> it just means more care and attention is needed
<tp> crest, if you port a standard Mecrisp-Stellaris to the nucleo and sent the files to matthias youll be imortalised in the contributors page!
<crest> ok the PD5/6 ping exist only in the parts >=100 pins and not on 64pin verions like the one on my board
<tp> yeah
<tp> that's how it works
<tp> a 205 pin package may have ports up to "G"
<tp> or even "H"
<tp> my 32 pin package has only ports A and B
<tp> crest, basically you edit terminal.s in the MCU directory in source
<crest> i did fiddle with that already
<crest> to test your terminal.s
<tp> that will involve checking if you can use the default AF1 as is or changing it if noy
<tabemann> back
<tp> does everyone have my latest L476 svd2forth files ?
<tabemann> I just realized a misfeature of my SET-ORDER functionality
<tabemann> it makes it really easy to not include forth-wordlist
<tabemann> and then you're fucked until you reboot
<tabemann> because without FORTH-WORDLIST one cannot call SET-ORDER again to reverse the change you made
<tabemann> I'm almost considering changing SET-ORDER that it forces the inclusion of FORTH-WORDLIST no matter what
<crest> damn it
<crest> the AF0-7 mappings are in the datasheet but *not* in the 2000 page reference manual
<crest> that explains why i didn't find them
<tp> no, theyre in the 'electrial' manual usually
<crest> i need AF7 for PA2 and PA3
<tp> it takes a little while to become familiar with what is where, but these are *very* complex devices, they cant be conddensed into a 100 page manual
<crest> of course not
<crest> but you could index them in useful ways
<crest> have an application note for normal USART use
<tp> crest, I've made an posted a tarball with a .s file for you, I'm waiting for sourceforge to make it live
<crest> an other one for USART with DMA
<tp> it has all the equate stuff you need
<crest> but most of it is "hidden" from C programmers in the support library
<tabemann> I hate the damn support libraries
<crest> if you write C against their library you call an API
<tabemann> they make searching for information on MCUs online impossible
<tp> the equate file has all the stuff you need to set up the alternate usart etc
<crest> the rest is just an implementation detail you don't have to know
<tp> in the terminal.s file
<tp> matthias wrote it so only the base file of the usart needs to be changed
<tp> all the usart registers are fine as is
<tabemann> cool
* tabemann just changed the search order in zeptoforth so it searches for words wordlist first, then by ram versus flash, rather than the other way around
reepca has joined #forth
<tp> ah
<tp> tabemann I like your word search feature
<tabemann> I think SET-ORDER is better than the traditional Forth-79 approach for a system with flash
<tabemann> as there is no need to maintain a branching tree of linked lists
<tabemann> rather there are two single linked lists, one for flash and one for RAM, in which each word is tagged with a wordlist
<tabemann> and for the wordlists, you just list he wordlists and the count and call SET-ORDER and presto! you now search those wordlist in that order
<tabemann> with the Forth-79 way of doing things... well... you set a single searched wordlist that links to a parent wordlist, and can't really change things around without chaining that wordlist to a different wordlist (something that is all but impossible with flash)
<tabemann> okay, I am getting tired, so I should go to bed
<tabemann> g'night
<rdrop-exit> Except for a few holdouts, Forth-79 fell out of favor when Forth-83 was published
dave0 has quit [Quit: dave's not here]
jsoft has joined #forth
Zarutian_HTC has quit [Ping timeout: 258 seconds]
dddddd has quit [Ping timeout: 260 seconds]
dys has joined #forth
APic has quit [Ping timeout: 256 seconds]
jedb_ has quit [Ping timeout: 265 seconds]
APic has joined #forth
gravicappa has joined #forth
jedb has joined #forth
_whitelogger has joined #forth
Zarutian_HTC has joined #forth
mtsd has joined #forth
rdrop-exit has quit [Quit: Lost terminal]
mtsd has quit [Quit: Leaving]
Zarutian_HTC has quit [Ping timeout: 264 seconds]
<tp> crest, ping, problem with Makefile "nothing to compile"
<jackdaniel> it should print somethign mroe consoling, like "All good."
<tp> Makefiles are like that, they have no heart
jedb has quit [Read error: Connection reset by peer]
jedb has joined #forth
mtsd has joined #forth
andrei-n has joined #forth
klys has quit [Ping timeout: 256 seconds]
klys has joined #forth
jedb_ has joined #forth
jsoft has quit [Ping timeout: 264 seconds]
jedb has quit [Ping timeout: 246 seconds]
gravicappa has quit [Ping timeout: 258 seconds]
WickedShell has quit [Remote host closed the connection]
andrei-n has quit [Quit: Leaving]
<crest> tp: pong
<crest> cd swdcom && gitpull && make clean && make
<crest> you also have to run the latest bootstrap.fs
iyzsong has joined #forth
dddddd has joined #forth
mtsd has quit [Quit: Leaving]
iyzsong has quit [Quit: ZNC 1.8.0 - https://znc.in]
gravicappa has joined #forth
WickedShell has joined #forth
jedb_ has quit [Ping timeout: 256 seconds]
Zarutian_HTC has joined #forth
Zarutian_HTC has quit [Client Quit]
Zarutian_HTC has joined #forth
Zarutian_HTC has quit [Remote host closed the connection]
dave0 has joined #forth
andrei-n has joined #forth
reepca has quit [Read error: Connection reset by peer]
reepca has joined #forth
proteusguy has quit [Ping timeout: 256 seconds]
proteus-guy has quit [Ping timeout: 265 seconds]
proteusguy has joined #forth
proteus-guy has joined #forth
<crest> tp: did it work for you?
TCZ has joined #forth
Zarutian_HTC has joined #forth
X-Scale` has joined #forth
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale` is now known as X-Scale
<crest> tp: i got the serial port working
andrei-n has quit [Quit: Leaving]
<crest> damn it the virtual com port gets suck for some reason
<crest> oh shit even with ascii-xfr -s -l200 it gets stuck after a few lines
<crest> asci-xfr -s -c 10 works so far but is even slower
TCZ has quit [Quit: Leaving]
gravicappa has quit [Ping timeout: 260 seconds]
dave0 has quit [Quit: dave's not here]
dave0 has joined #forth