#avr Logs
Aug 07 2019
#avr Calendar
12:09 AM Irrelium: Anybody ever have issues with Atmel Studio where it programs the device fine but then doesn't run the program?
12:14 AM Irrelium: I'm using an STK600 dev board with a AT32UC3C and it has no trouble programming the flash when I click debug but the code never starts, power cycling the board will cause it to run though
12:14 AM Irrelium: Run without debugging does the same thing
12:22 AM Irrelium: Looks like the STK600 doesn't actually support JTAG debugging
12:22 AM Irrelium: That's a bit dissapointing
01:49 AM rue_bed: your sure there are no breakpoints or anything?
01:50 AM rue_bed: debug via an io pin
01:50 AM rue_bed: if you progressivly write and test your code, it'll be fine
03:29 AM Miyu is now known as hackkitten
08:38 AM Thrashbarg_ is now known as Thrashbarg
09:39 AM basilic: hello all
09:39 AM basilic: anybody has compile a project from start.atmel using makefile on GNU?
09:47 AM cehteh: start.atmel?
09:51 AM cehteh: wtf browser based ide?
09:52 AM basilic: not it's a tool from atmel to generate a base project
09:52 AM basilic: you can use it on AVR studio
09:52 AM basilic: IAR IDE
09:52 AM cehteh: yeah i just figued and it can export makefiles
09:52 AM basilic: and from GNU Makefile
09:52 AM cehteh: .. but i never used it
09:52 AM basilic: I try it but Makefile seems not work
09:53 AM cehteh: then fix ot
09:53 AM cehteh: i am using my own makefiles
09:53 AM basilic: I'm not so good for do it
09:53 AM basilic: avr-gcc: error: ,: No such file or directory
09:53 AM basilic: seems try to compile a "," file
09:55 AM cehteh: possibly some configuration/path fuckup
09:55 AM cehteh: you have to debug and fix that
09:57 AM vmt: i take it, you're an intern in some startup?
09:57 AM cehteh: i dont know their makefiles but you should be able to see what make does
09:57 AM cehteh: haha
09:58 AM cehteh: usually i disable makefile spewing things to the user but thats configureable when you know how to
09:58 AM vmt: well, hobbyists hardly use IAR and non-interns should have mostly figured out how to use it
09:58 AM cehteh: make --trace may already help .. or actually reading that makefile and see
09:59 AM vmt: the latter seems like the way to go, really
09:59 AM cehteh: for example i have a MAKE_DEBUG=1 flag there which turns off parallel builds and shows what make does
09:59 AM vmt: i.e. do your job
10:00 AM cehteh: the boss saied "here click some cool app on that website and make me rich" :)
10:01 AM Fuchikoma: This start.atmel thing is kinda neat... though it doesn't seem to generate anything useful if you don't have atmel studio
10:01 AM cehteh: i didnt even know about it 10 minites ago
10:02 AM Fuchikoma: Me neither but it seems to be a wizard for configuring the device. Set clock speeds, select and configure periphrials, etc.
10:02 AM cehteh: and i doubt it helps with more than 1% of development, doing some boilerplate work .. so what? ... thats not hard anyway
10:03 AM Fuchikoma: Ah there's a generate code button
10:03 AM cehteh: when thats already a entry barrier to programming, then you better dont start at all
10:04 AM Fuchikoma: I think "barrier" is a bit overstating it
10:05 AM Fuchikoma: There's a difference between "can't do it even if I wanted to" and "it's easier to just click a few buttons and have the machine do it"
10:12 AM Fuchikoma: You know what, I'm going to try using this to configure my clock and UART and try comparing it to my own config, see if I can figure out why mine is so out of whack
10:13 AM cehteh: hah try it
10:13 AM cehteh: you have a -0 or -1 series there?
10:13 AM Fuchikoma: Nothing at the moment it's at home
10:14 AM cehteh: i just tihnking i have a parser for opening serial with custom parameters
10:14 AM cehteh: muos_serial_start (0, 115200, "8N1", -1, muos_lineedit);
10:14 AM cehteh: .. but its C :)
10:22 AM cehteh: Fuchikoma: ah, beside the baudrate calc, did you handle/set7clear the U2X flag as well? that may also explain when its off
10:23 AM Fuchikoma: Cleared it, but it's not 2X off it's nearly 100X off :p
10:24 AM cehteh: swapp low/high part of the prescaler bits?
10:25 AM Fuchikoma: I'm pretty sure I got it right; I'm using the aliases from the .inc file
10:25 AM cehteh: something must be wrong, else it would work
10:25 AM Fuchikoma: Since I got it in a working state, I've been doing actual application programming for now
10:26 AM cehteh: experience tells me that when something just works by chance and try'n'error it most likely slap you in the face some time later
10:27 AM Fuchikoma: I didn't say I had no plans to fix it :)
10:27 AM cehteh: you may wait for that to be happen ,, or figure out whats really wrong now
10:27 AM cehteh: yeah
10:27 AM cehteh: i know that :)
10:27 AM Fuchikoma: Just that I can make progress with other things in the short term
10:28 AM Fuchikoma: *especially* considering I'll probably use a different physical chip for the actual project
10:28 AM Fuchikoma: So andthing that's wonky with that specific silicon will change, and break everything
10:39 AM nohit: ST has a similar tool called CubeMX, its great. i think i tried atmel start once but it sucked, cant remember why it suckecd
10:40 AM nohit: you can have like a working usb mass storage device configured in under 20 mins
10:42 AM vmt: i hope they fixed cubemx. it had some serious bugs last time i used it
10:43 AM vmt: though that's years ago
10:43 AM nohit: its already integrated to the new IDE
10:43 AM nohit: Cube IDE
10:43 AM vmt: serious bugs meaning the startup code it generated was plain broken
10:43 AM nohit: its atollic studio + cubemx
10:43 AM vmt: alright
10:44 AM vmt: is stm stuff all HAL now or can you still use the older lib?
10:44 AM vmt: i forgot what that was called
10:44 AM nohit: the startup code it generates(crt0) is bit shitty, if you comapre it to the example file in arm-gcc toolchain
10:44 AM nohit: HAL
10:45 AM nohit: std peripheral lib is gone
10:45 AM vmt: yeah stdperiph
10:45 AM vmt: they didn't even have stdperiph for cm4/7 + f variants, if memory serves
10:45 AM nohit: yeah
10:45 AM vmt: but i always found stdperiph to be much nicer to use
10:46 AM nohit: there's also this LL now
10:46 AM vmt: what's that?
10:46 AM nohit: which is like a lite version of HAL
10:46 AM nohit: you might like that bbetter
10:47 AM vmt: yeah, haven't worked with mcus in some time now, and it looks like i won't be at least in the near future. maybe i'll check it out just to keep tabs on it a bit
10:47 AM nohit: havent used it but i guess its more banging registers and less structs
10:50 AM cehteh: maybe one of you has an idea: i have typedef typeof(SOMEREGISTER) register_type; to define the type of the register (which may be 8 or 16 bit)
10:51 AM cehteh: but its also defined volatile. how do i get rid of that?
10:51 AM cehteh: C not C++
10:52 AM vmt: GCC?
10:53 AM cehteh: yes
10:53 AM cehteh: typeof() is gnu iirc
10:55 AM vmt: so, i'm not sure if i follow. you know that the type of SOMEREGISTER has volatile qualifier?
10:55 AM cehteh: yes
10:55 AM vmt: but you want to typedef is as non-volatile?
10:55 AM vmt: it*
10:55 AM cehteh: yes
10:56 AM cehteh: not of that register, but i want to typedef a type with equal width
11:01 AM vmt: hmm. it could be done with a nasty macro
11:04 AM vmt: well, no, you don't actually need a macro
11:04 AM cehteh: how?
11:04 AM cehteh: i dont have a solution yet
11:05 AM vmt: typedef uint8_t my_type[sizeof(SOMEREGISTER)];
11:05 AM vmt: *don't shoot me*
11:06 AM cehteh: lol
11:06 AM cehteh: yeah thats something somewhat different :D
11:06 AM vmt: well, technically it does what you want
11:06 AM vmt: it's not pretty, i admit...
11:06 AM cehteh: except it retuerns a pointer
11:07 AM vmt: array
11:07 AM cehteh: well lets see how it optimizes
11:07 AM cehteh: mmg no wont work
11:09 AM cehteh: i cant assign a value then at least not without even more uglyiness and tons of casting which makes the whole typedef futile
11:09 AM vmt: yes i know;D
11:09 AM vmt: you would have to be somewhat careful using that
11:09 AM cehteh: well thne i dont need it alt all
11:10 AM vmt: at what point is the register width defined, though?
11:10 AM vmt: runtime?
11:11 AM vmt: i.e. when is it known
11:11 AM cehteh: in this case thats the timer, the user can configure in the makefile which timer to use, could be TCNT0 or TCNT1 etc .. depending on the part that may be 8 bit or 16bit timers
11:12 AM cehteh: ideally i wanted to derrive that somehow and being agnostic about the users choice
11:12 AM vmt: what's the benefit? you would just use that right off the bat
11:12 AM cehteh: i could add another config where one defines the type, but thats 2 points of maintenance
11:12 AM vmt: you could*
11:13 AM vmt: i mean you're going to add some ifdeffing but how bad would it be?
11:13 AM cehteh: could become out of sync user changes the timer from 0 to 1 but forgets to set the underlying type
11:14 AM cehteh: will break then
11:14 AM vmt: you would set the underlying type yourself when the width depends on the user's choice?
11:15 AM cehteh: i just want to infer it automatically
11:15 AM vmt: hmmh
11:16 AM cehteh: user just defines "MAIN_CLOCK=0" or MAIN_CLOCK=1 or whatever
11:16 AM cehteh: works so far, because currently the volatile there doesnt hurt
11:17 AM cehteh: but i just changed/added something where i noticed the deficiency
11:17 AM vmt: perhaps i'm dumb, but using that directly to infer the type i fail to see how it can get "off sync"
11:17 AM cehteh: if course i can add the config MAIN_CLOCK=0 MAIN_CLOCK_TYPE=uint8_t
11:17 AM cehteh: one then has to keep those in sync
11:18 AM vmt: when MAIN_CLOCK==1, type==uint16_t?
11:18 AM cehteh: some api's and other places need to know the underlying clock type and size
11:18 AM cehteh: whatever the hardware has there
11:18 AM cehteh: differs between differnt parts iirc
11:19 AM cehteh: thus i wanted to infer it to make it simpler and more bullet proof
11:19 AM cehteh: typedef typeof(TCNT0) hardware_clock_type;
11:19 AM cehteh: etc
11:20 AM cehteh: but i see no way to cast away 'volatile' from that in C
11:23 AM vmt: wait a sec
11:35 AM cehteh: http://paste.debian.net/1094820/
11:36 AM cehteh: to summarize it
12:07 PM nohit: i had a similar problem with xmegas, i couldnt use the defines offered in the header file with c++ templates becuase the way the defines were implemented. i cant remember the exact problem, but then i chose not to use templates.
12:17 PM vmt: sorry, had to run to an emergency
12:17 PM vmt: let's see, i think i have a way to do this, though it won't be pretty either
12:18 PM cehteh: i just let the user define the type .. i ithnk its impossible in C
12:29 PM vmt: myeah, this would require extreme macro fuckery and even then i'm not sure if it's possible
12:30 PM cehteh: i dont think thats possible with macros
12:30 PM cehteh: because macros cant decompose the type
12:31 PM vmt: no, but you would have to go around it knowing the possibilities of combinatorics wrt hardware
12:32 PM vmt: hardware and the user choice, i figure
12:32 PM vmt: or then you'd simply write a preprocessor of your own taking *some* input, dunno
12:32 PM cehteh: i did that somewhere else where its more irregular and varrying, having a table for possibilities and look that up
12:32 PM cehteh: but i cant look up types
12:32 PM cehteh: maybe with some helper .. moment
12:33 PM vmt: if it's something you might find use for later, you might want to write a small preprocessor that can do this for you
12:35 PM cehteh: typedef __typeof((__auto_type r = MUOS_CLOCK_REGISTER, r})) muos_hwclock;
12:36 PM cehteh: .. something along that, testing in a moment just have to fix other things
12:41 PM cehteh: nop
12:41 PM cehteh: expression statements must be inside functions
01:15 PM nohit: vmt: do you know any easy wireless solution for connecting sensor boards for AVR ?
01:17 PM nohit: like you have this main board that has AVR on it and then little boards that talk to that mainboard wirelessly
01:17 PM day: nohit: there are 433Mhz receiver/transmitter boards on ebay
01:18 PM Fuchikoma: There's also IR serial build right in but that's probably not what you're looking for
01:18 PM nohit: tahnks
01:18 PM day: afaik the wireless boards can be hooked directly to the TX/RX ports and you just do your usual usart
01:19 PM Fuchikoma: I know at least one such wireless module is like that, at least.
01:27 PM cehteh: pretty mch depends on what suits your needs best, security, distance, reliablility, bandwidth
01:27 PM cehteh: IR might be an option as well
01:28 PM cehteh: or use espXX instead avr's
01:30 PM cehteh: 433mhz and lots transmitters trying to talk at the same time sux as well
01:30 PM cehteh: bigier antennas as well .. but fpr low bandwidth they can be nice
01:30 PM day: some low power illegal frequency is certainly nicer @home :p
01:32 PM vmt: nohit: nordicsemi?
01:32 PM vmt: easy: yes, cheap: no
01:33 PM nohit: this is not my project and espXXX isnt an option
01:36 PM nohit: but those cheap ebay things will probably do the job
01:37 PM vmt: nordicsemi has some nice wireless solutions and the documentation is really good
01:37 PM vmt: buuut availability and pricing is a bit mehhh
01:37 PM nohit: yeah, if this was my project i would probably check out nordicsemi
01:37 PM day: vmt: if you are just looking for a chip not a ready to use module then there are tons of options. Ti has a huge portfolio
01:38 PM nohit: and use STM32, like any sane person
01:38 PM vmt: well i think the most painless solution is to use a module
01:39 PM day: of course. i think the rf part can be quite painful to design
01:39 PM vmt: seems like nordic has changed their portfolio though. not sure if they sell the nrf modules nowadays, seems like it's socs all the way down now
01:40 PM vmt: with embedded arm cores
01:40 PM day: i mean if you just need to hack something together, use two pairs of these https://www.ebay.de/itm/433-Mhz-Sender-Empfanger-RF-Funk-Modul-FS1000A-xy-mk-5v-Arduino-Raspberry-Pi/252713874815?hash=item3ad6ebb57f:g:7R0AAOSw7D1cP4go
01:40 PM nohit: we were actually at ST's workshop in february about their new wireless micros, but i have already forgot everything
01:41 PM vmt: haha
01:43 PM nohit: we were doing ble stuff
01:43 PM nohit: turning leds on/off with an android phone
01:44 PM day: was bluez involved?
01:44 PM nohit: hmm
01:44 PM nohit: probably
01:44 PM day: im super curious why this project seems rather big/well maintained but a total undocumented unusable clusterfuck
01:45 PM day: it's like it is intentionally obscure
01:45 PM vmt: what is? bluez?
01:46 PM day: bluetooth library
01:46 PM day: i believe THE bluetooth library
01:48 PM vmt: having done extensive xlib programming, foss documentation quality doesn't surprise me at all anymore
01:48 PM day: idk bluez has a special place in that
01:49 PM day: you find basically nothing. no examples, nada. The only tiny bit i found was in a intel edison tutorial :P
01:52 PM Fuchikoma: If they document it someone else might take it over heh
01:52 PM Fuchikoma: "The secret dies with me!"
01:52 PM day: i got as far as figuring out that it is maintained by companies iirc :P
01:53 PM Fuchikoma: Ah, so it's an IP thing
01:53 PM day: well it is opensource
01:53 PM day: but yes my assumption is that it is obscured on purpose
01:53 PM day: if you join the irc channel noone will answer you :P
01:55 PM day: there used to be an easy commandline extention/program to use the library. hcitool iirc. but that one got removed :D probably because it was usable
02:01 PM vmt: ah yeah i remember that
02:04 PM nohit: fun times is ahead when i have to learn bluetooth on iOS
02:04 PM nohit: apple dosnt allow serial port profile
02:04 PM day: meh i doubt it's difficult with the java confines
02:05 PM day: unless you try to do something that isnt allowed :D
02:05 PM nohit: what ?
02:05 PM nohit: java ?
02:05 PM day: isnt ios java?
02:05 PM nohit: nope
02:05 PM day: thought it's like android
02:06 PM nohit: C/C++/Objective-C/Swift
02:06 PM day: they are all equally well supported or is it like android?
02:07 PM nohit: to my knowledge yes
02:07 PM nohit: no JNI kinda thing
02:07 PM day: i see. i doubt i will ever develop something for ios
02:08 PM nohit: what i learned from doing the same thing on android, that java cannot be trusted
02:11 PM nohit: but yeah, you have to use BLE with ios
02:27 PM nohit: i never found out what the bug really was. it gave this CRC error at random times. but when i re-did the whole thing in C, it worked.
02:28 PM nohit: so java cannot be trusted
02:28 PM vmt: is the android ndk still a thing?
02:28 PM nohit: yes, that's what i finally used
02:29 PM nohit: and i will do everything with C from now on, everything that isnt related to android framework/ui
02:29 PM vmt: good. i really don't want to touch java even with a 10 ft pole
02:30 PM nohit: also java has signed byte type, its ridicilous
02:30 PM vmt: only*
02:30 PM vmt: if memory serves
02:30 PM nohit: yes
02:30 PM day: does the c code run universally on all phones?
02:30 PM vmt: in any case. i think android has some kind of a mechanism that it converts java to "native code" on play install
02:30 PM vmt: whatever native code might mean then.
02:30 PM vmt: but i'd still rather use the NDK
02:31 PM nohit: so anything byte level thing, like a checksum, you have to cast and AND everything to unsigned int first
02:31 PM day: because e.g. my phone uses a 32bit arm
02:31 PM nohit: its ridiciluos
02:33 PM vmt: no idea, thankfully i have never had to develop anything for crapdroid
02:33 PM vmt: though from what i hear of the general experience, it's like shoving splinters under your fingernails
02:33 PM nohit: int i = int (byte & 0x00FF);
02:33 PM nohit: you have to do that
02:33 PM nohit: to every byte
02:33 PM nohit: before you can use it
02:34 PM nohit: casting isnt enought
02:34 PM vmt: i am still amazed by the fact that java (at least over here) is taught very commonly as one of the first things in comp.sci
02:35 PM nohit: yeah, we were taught C
02:36 PM vmt: though, i've grown a somewhat of an aversion towards cs people
02:41 PM nohit: it just makes .so shared libraries of your C modules, its really good. most of the system functions are actually implemented that way, the java class doesnt have the implementations
02:45 PM nohit: im actaully learning open gl on android right now, i need to implement a custom shader
02:46 PM vmt: opengl es makes me a sad panda :(
02:47 PM vmt: i think vulkan is somewhat of an improvement in that regard, as i think the profiles are mostly compatible, but i don't know about the device coverage
02:47 PM vmt: and the fact that for vulkan you have to write a shit ton more boilerplate for init
02:58 PM nohit: have you ever written a big(multiple views) gui desktop application?
02:58 PM nohit: i have to make one with Qt
02:58 PM nohit: when i have time
03:02 PM nohit: i havent really done anything other than a simple serial port test program with few ui components
03:03 PM nohit: on pc
03:04 PM nohit: im thinking about using mapbox with Qt
03:07 PM nohit: i also would like to change all the google maps components in our mobile app to mapbox
03:08 PM nohit: OpenStreetMap gets updated faster than google maps
03:08 PM nohit: and google maps on android has quite limited api
03:16 PM nohit: Qt also has bluetooth class, so you dont have to do the serial port trick and you can pair the devices in the application
03:17 PM nohit: we had this korean intern this summer, she actually was suppose to do that application, but she couldnt handle it
04:26 PM nohit: day: version of the c code is compiled to every platform youre gonna support, so you might have multiple .so in your .apk
04:31 PM nohit: i think that's actually called fat binary
05:39 PM Smidge204: "For asynchronous operation, the BAUD register value is 16 bits (64 to 65535). The 10 MSBs (BAUD[15:6]) hold the integer part, while the 6 LSBs (BAUD[5:0]) hold the fractional part."
05:40 PM Smidge204: Okay so, what exactly does that mean?
05:40 PM Smidge204: 'cause apparently that can be interpreted the wrong way
05:44 PM timemage: Smidge204, meaning fixed point. 5:0 hold 64ths
05:44 PM Smidge204: That's how I interpreted it
05:45 PM Smidge204: Atmel's own configuration utility says that's wrong, though
05:45 PM timemage: Smidge204, hmm, what does it say?
05:45 PM cehteh: Smidge204: dunno whats wrong, but misinterpreting that perfectly explains your problem
05:46 PM Smidge204: In this situation, the calcuated value is 104.1667
05:47 PM Smidge204: But Atmel's config wizard thing put a value of 104 in the low byte only, using the 6 LSBs for that value
05:47 PM Smidge204: Discarding the 0.1667 part
05:47 PM Smidge204: And yeah that accounts for the hige difference :/
05:47 PM timemage: Smidge204, this wizard had to be informed as to which part you're using, right?
05:48 PM Smidge204: Yup
05:48 PM timemage: Smidge204, so it's been told that this is a 1-series (or whatever you're using)?
05:48 PM Smidge204: I didn't see an option for "series" on the part select
05:49 PM timemage: Smidge204, well, you chose whatever mcu you're actually using at least, yeah?
05:49 PM Smidge204: Yes, I just checked and the part numbers match exactly
05:49 PM timemage: Smidge204, i ask because not all avr have that fractional part in the baud rate register.
05:49 PM timemage: Smidge204, okay.
05:50 PM Smidge204: So maybe it's the datasheet I have that's wrong
05:50 PM timemage: Smidge204, that seems less likely. but you're can figure out which it is by putting the other value i suppose.
05:53 PM Smidge204: The version I was using and the one I pulled from the supplier's site are branded different (one Atmel the other Microchip) but they're identical, at least that one section.
05:53 PM Smidge204: oooookay
05:53 PM Smidge204: Gonna compare the clkctrl registers and see if that's messed up too
05:59 PM Smidge204: And there was an error setting the prescaler value, which is 100% on me for not being careful
06:00 PM Smidge204: But mostly it's the BAUD register value which ain't my fault! :)
06:00 PM twnqx: how do you set the baud register?
06:01 PM twnqx: could it be some size issue, e.g. uint8_t vs uint16_t ?
06:01 PM Smidge204: I'm doing it in assembler so there's no type issue
06:02 PM Smidge204: The datasheet says to split it into integer and fractional parts, but you apparently don't do that
06:05 PM timemage: Smidge204, cant do... ?
06:05 PM timemage: Smidge204, or don't do.... sort of confused. to be clear, i think the only reason why the phrase it that way is they're providing an equation for it.
06:08 PM Smidge204: Yeah and the equation works fine
06:09 PM timemage: Smidge204, okay.
06:13 PM Smidge204: The problem is either "interger part/fractional part" means something other than what's understood, or you *don't* store the fractional part in the 6 LSBs but just store the integer part only as a 16-bit word
06:15 PM timemage: Smidge204, i'm probably just not following. looking at the 816 datasheet, it's written BAUD = (64 * CLK_PER) / (S * F_BAUD) i take it the 64 is here because they're calculaing in 64ths.
06:16 PM Smidge204: Right
06:17 PM timemage: Smidge204, so if you're following this equation and storing the result in the entire register you *are* storing the fractional part in the 6lsbs, yeah?
06:17 PM Smidge204: https://i.imgur.com/iyQrc7b.png This is the math applied. I'm aiming for a 250KHz CLK_PER, so the BAUD register should be 104.1667
06:19 PM Smidge204: So my understanding of the sentence in the datashet; 104 is the "integer" part and is stored in the 10 MSBs, and 0.1667 is the "fractional" part and stored in the 6 LSBs
06:19 PM Smidge204: But this is not what the Atmel Start configured code does. It puts "104" in the 7 LSBs
06:21 PM timemage: Smidge204, that sounds correct given what's been said.
06:21 PM Smidge204: Then I don't understand the "fractional part" part
06:22 PM timemage: Smidge204, because the calculation is already being done in 64ths the 104 is literally 104 64ths
06:22 PM Smidge204: I need a drink
06:22 PM timemage: Smidge204, heh
06:23 PM timemage: Smidge204, it's like if we were told that something stored 3 decimal digits and the low order digit was tenths and we wanted toe store 1/3, we might 10*1 / 3 so we're doing the calculation in tenths
06:25 PM Smidge204: It makes sense now but that is not at all clear what's going on
06:25 PM Smidge204: From the datasheet
06:26 PM timemage: Smidge204, it seems clear to me, but that's how usually how goes once you have the interpretation locked in your head.
06:30 PM timemage: Smidge204, it may make more sense if you're just looking at: CLK_PER / (S * F_BAUD) S * F_BAUD because we're concerned with bit-samples, not bits. so CLK_PER / (S * F_BAUD) is how many peripheral clock-per-bit-sample. which would give us 250000.0 / (16*9600) about 1.628. but we want it in 64ths, so we could: (250000.0 / 16*9600) * 64. or, we could just put the 64 on the top along with the 250000, which is what they did in their
06:30 PM timemage: equation.
06:31 PM Smidge204: Or just ignore that one sentence entirely, and leave the one before it as-is: " For asynchronous operation, the BAUD register value is 16 bits (64 to 65535)"
11:14 PM [1]MrMobius is now known as MrMobius
11:48 PM day__ is now known as day