#avr Logs

May 24 2017

#avr Calendar

12:13 AM day__ is now known as daey
02:03 AM JanC_ is now known as JanC
02:58 AM day__ is now known as daey
04:47 AM julius: hello guys
04:48 AM noHitW_work: hello
05:05 AM Emil: g'day
05:09 AM Lambda_Aurigae: merninish.
05:52 AM julius: merninish, whats that?
05:55 AM Tom_itx: he's drunk and want's you to pass the mayonnaise
05:55 AM Lambda_Aurigae: mernin,,,morning
05:56 AM Lambda_Aurigae: and I'm serfictly pober!
05:56 AM julius: ah of course, a morning thing
05:59 AM cehteh: o/
11:30 AM day__ is now known as daey
11:42 AM Tom_itx is now known as Tom_L
12:50 PM JanC_ is now known as JanC
02:10 PM Emil: Hmmmmm
02:11 PM Emil: So I have 16MHz 7pF smd crystals :D
02:11 PM Emil: If we apply the C=2*Cl-2*Cs with 7pF stray
02:11 PM Emil: we get 0
02:11 PM Emil: ":D"
02:37 PM Emil: Anyone know the pin capacitance on avrs?
02:38 PM xentrac: depends on the package, I imagine?
02:38 PM Emil: Well
02:38 PM Emil: sure
02:38 PM Emil: for tqfp?
02:41 PM polprog: it gives recommended range for each freq along with cksel in the datasheet,
02:41 PM xentrac: dunno, maybe 0.2 pF? http://www.ti.com/lit/an/snoa405a/snoa405a.pdf may be of use to you here
02:41 PM xentrac: maybe as high as 1 pF between adjacent pins
02:41 PM xentrac: at the corner
02:41 PM polprog: not sure about that because i never used a crystal
02:44 PM xentrac: https://www.amkor.com/go/LQFP also gives some figures in the 0.2 pF range for LQFP leads
03:03 PM Emil: polprog: I know
03:31 PM slidercrank is now known as Guest70698
06:08 PM Tachyon` is now known as Tachhm
06:18 PM Jan-: does the SPI clock pin on an atmega328p idle high or low?
06:22 PM timemage: Jan-, usually high. but there's an option for clock polarity.
06:22 PM Jan-: I'm having some trouble driving shift registers with the SPI hardware.
06:22 PM Jan-: it sort of works, but my data is getting out of sync.
06:24 PM timemage: Jan-, well, look at the wikipedia descriptions of clock polarity and phase. and then in the datasheet check out the SPCR register. compare the timing diagrams with your shift register timing diagram.
06:24 PM Jan-: they're 595s, so they clock in on the falling edge.
06:24 PM Jan-: I think
06:26 PM timemage: Jan-, "Data is shifted on the LOW-to-HIGH transitions of the SHCP input."
06:26 PM Jan-: oh hm okay my bad
06:27 PM Jan-: I'm not sure how that compares to the AVR SPI
06:27 PM timemage: Jan-, "SPI" is unfortunate in that it seems to imply there's more standard than there is.
06:28 PM Jan-: y..ers, I got that
06:28 PM timemage: Jan-, to that end the avr is *configurable* with respect to clock polarity and phase. which is why i'm trying to point you at those thing above.
06:29 PM timemage: Jan-, iirc, the defaults in SPCR would be correct for clock polarity for a 595 shift register. but you can figure that out for yourself easily enough.
06:29 PM Jan-: I'm setting SPCR |= (1<<SPE) | (1<<MSTR) | (1<<SPR0);
06:30 PM Jan-: my own comments tell me that's just enabling SPI and selecting clock / 16 as the clock rate
06:31 PM timemage: Jan-, what are your comments telling you about the bits that you aren't setting?
06:31 PM Jan-: nothing, I'm looking it up
06:31 PM timemage: good!
06:33 PM Jan-: Unfortunately I can't see the timing diagrams
06:33 PM Jan-: but I'm not setting CPOL or SPHA
06:33 PM Jan-: er CPHA
06:36 PM Tachhm is now known as Tachaway
06:36 PM timemage: Jan-, wikipedia has a diagram showing how CPHA and CPOL affect the waveforms.
06:37 PM Jan-: yeah, I can't see pictures, I'm doing this with a screenreader
06:44 PM Jan-: It's sort of strange, it's going in and out of sync
06:44 PM Jan-: I guess I can just randomly try some clock phase stuff.
06:52 PM timemage: Jan-, CPOL=0 CHPA=0 seems correct for the 595 from what i can cell.
06:55 PM timemage: Jan-, so in answer to the original question, it would idle low rather than high, assuming you have CPOL=0; CPHA=0 configured, which they would default to. so it seems what you have is correct as far as it goes.
07:21 PM Jan-: timemage: thanks.
07:21 PM Jan-: it's behaving very weirdly.
07:21 PM Jan-: the situation is that I have to 595s connected to two 7 segment displays
07:22 PM Jan-: I'm clocking in 0x01, 0x01 then a 500ms delay, then 0xFF, 0xFF. The 1 should illuminate the decimal points on the displays.
07:22 PM Jan-: So what you should get is the decimal points continuously on, and the other segments flashing at 2 hz
07:22 PM Jan-: And it does sort of do that sometimes.
07:22 PM Jan-: otherwise there are quite long periods of blankness and it is essentially random
07:23 PM Jan-: we can't detect a pattern in what it's doing so we suspect it's something that's being randomly determined
07:23 PM Jan-: (which makes it very hard to fix)
07:24 PM timemage: Jan-, i would guess that you have something floating, or near enough.
07:24 PM Jan-: that or some sort of clock patching issue.
07:25 PM Jan-: so it's seeing edges fleetingly
07:26 PM timemage: Jan-, hmm. does it get better or worse or no change if you don't divide your clock by 16?
07:26 PM Jan-: that's the (1<<MSTR) thing isn't it?
07:27 PM timemage: Jan-, i'm going based on what you said earlier. with that SPR0
07:27 PM Jan-: I have SPCR |= (1<<SPE) | (1<<MSTR) | (1<<SPR0);
07:28 PM timemage: Jan-, i would say remove SPR0 then.
07:28 PM Jan-: pin 10 on the 595 is !MR
07:28 PM Jan-: which presumably we want tied high
07:28 PM Jan-: that presumably being master reset
07:28 PM timemage: Jan-, yeah, although once the avr is running it shouldn't be floating anyway.
07:29 PM Jan-: er yeah.
07:29 PM timemage: Jan-, i see, you're not using at all then?
07:29 PM Jan-: forgot to tie !MR high on 595 #1
07:29 PM timemage: Jan-, that could certainly cause that sort of problem.
07:29 PM Jan-: so it was spontaneously resetting probably through coupling at random times.
07:29 PM timemage: Jan-, right.
07:29 PM Jan-: now we have flashing 8s.
07:29 PM timemage: Jan-, so, not what you expected by stable, yeah?
07:30 PM Jan-: nono it's all good now
07:30 PM timemage: Jan-, ah, okay.
07:30 PM Jan-: I basically have this: https://pastebin.com/i3PeU810
07:31 PM Jan-: it happens that the lsb is wired to the decimal point on the display, so we're alternating " . ." and "8.8." twice a second.
07:31 PM timemage: Jan-, usually you would select/deselect around each transaction.
07:32 PM Jan-: *shrug* can do.
07:32 PM Jan-: seems to work OK on this and on a nordic rf radio module.
07:32 PM Jan-: now I have to define a "font" so we can actually display numerals.
07:34 PM Jan-: I even have notes on how it's wired. It should be GFABEDC then the DP
07:34 PM timemage: Jan-, is select operating the latch signal?
07:34 PM Jan-: No it's using a 4011 nand gate to gate off the clock.
07:35 PM Jan-: I need the latch for other purposes.
07:35 PM Jan-: we need to preload these things then flip the latch to do a very clean display update, it's a precision timing application.
07:36 PM Jan-: AVRs are backwards, right, so 0x01 is 0b00000001?
07:36 PM timemage: Jan-, that's backwards?
07:37 PM Jan-: yers.
07:37 PM timemage: Jan-, from what?
07:37 PM * Jan- thinks 0x01 should be 0b1000000
07:37 PM * Jan- is constantly screwed up by this
07:37 PM * Jan- waves her arms
07:37 PM timemage: Jan-, lol. uhh well, it's pretty normal for the least significant bit to be notated on the right. that's what school children are taught.
07:38 PM timemage: Jan-, s/bit/digit/
07:38 PM Jan-: yeah yeah yeah.
07:38 PM Jan-: :)
07:38 PM Jan-: now I have to figure out which bits to turn on to form a viewable numeral
07:39 PM timemage: Jan-, there are different "bit-endians" used in serial connections. you don't normally notice this at the level of an AVR though.
07:39 PM Jan-: I can use 0b notation in the arduino ide, right?
07:39 PM timemage: Jan-, usually the 7 segment displays are labled somethnig like a through g then dot. i think the typical arrangement is a:0 g:6 dot:7
07:40 PM timemage: Jan-, you can in newer ones at least. iirc it's a feature of c++11 or c++14. not sure in c.
07:40 PM timemage: Jan-, iirc, it wasn't in c99.
07:40 PM Jan-: these are wired GFABEDC
07:41 PM Jan-: so for a zero I want spi_transact(0b01111110);
07:41 PM timemage: Jan-, if you look at it long enough you'll probably find a rational having to do with routing.
07:41 PM Jan-: G is the horizontal one in the middle
07:41 PM Jan-: a rational what
07:42 PM timemage: Jan-, rationale
07:42 PM Jan-: on the final board I've said he can do whatever he wants, we'll just patch it up in software
07:42 PM Jan-: the "font" can be anything
07:42 PM Jan-: just make the layout easy
07:43 PM timemage: Jan-, anyway, it's fairly normal for programmers to mentally convert between hex nibbles and binary and octal. there hasn't been such a push for binary literals. i'm sort of surprised the ended up doing it.
07:43 PM Jan-: well I guess you don't do it much outside of microcontrollers and very low level hardware-hammering
07:45 PM timemage: Jan-, well, i can look at you 0b01111110 example and pretty much instantly see 0x7E. once the numbers get to a certain size it's almost easier to read hex because even when thinking it bits because of how it groups them. although in newer versions of c++ you can separate digit groups also.
07:45 PM Jan-: I notice that some of the commercial bcd to 7 segment drivers have digits 0-9 and the letters H E L and P. I'm not sure why.
07:46 PM Jan-: Presumably some lost to history reason
07:48 PM timemage: Jan-, probably modeled after some well known device. i would expect "LOAD" to be another.
07:48 PM Jan-: can you really do D
07:49 PM timemage: Jan-, lowercase
07:50 PM Jan-: oh yes.
07:50 PM Jan-: I may need characters to say "no signal"
07:50 PM Jan-: or at least "N0 SiG"
07:50 PM Jan-: perhaps battery low, er, "bAt L0"
07:51 PM timemage: Jan-, they cheat. i had what amounts to a protable dvd player and for some reason they used a lower case r shape for the 'a' in 'load'. so we always used joke that it was complaining about crappy dvds.
07:51 PM Jan-: dEAdBEEF etc
07:52 PM Jan-: I think I may have hit something that I can't reasonably do, however.
07:54 PM Jan-: hm is there something odd about the way the SPI clocks things out
07:54 PM Jan-: because in this case, sending 0x01 *does* match sending 0b10000000
07:55 PM timemage: Jan-, i don't understand.
07:55 PM Jan-: if I send 0x01 the decimal point lights up
07:55 PM Jan-: if I send 0b10000000 the decimal point lights up
07:56 PM timemage: Jan-, those are different values though. so i'm not sure what to tell you. if you want to prove that to yourself, do if (0x01 != 0b10000000) { /* blink led or whatever */ }
07:57 PM timemage: Jan-, binary is not different from decimal hex or octal in the order of significant digits.
07:57 PM Jan-: that's what I thought.
07:57 PM Jan-: maybe it's some off by one error
07:57 PM timemage: Jan-, yes
07:57 PM timemage: Jan-, something more like that anyway.
07:59 PM timemage: Jan-, in a typical compiler, the lexer would convert 0b1000000 and 0x80 to the same internal data well before it even got to the level of interpreting syntactic structures. there just isn't even an opportunity for the greater part of the program to distinguish between the two.
08:00 PM Jan-: I wonder how I should arrange the font.
08:00 PM Jan-: for numbers, I can put it in an array.
08:00 PM timemage: Jan-, what are you going to provide besides numbers?
08:00 PM Jan-: I'm not sure.
08:00 PM Jan-: At least somethingl
08:01 PM Jan-: I guess I'll just put it in an array and deal with looking it up as required.
08:01 PM Jan-: last thing you want is a sparse array on a micro with 2kb of ram :)
08:01 PM timemage: Jan-, well, if they're consequative somethings in ascii code it makes things simpler.
08:01 PM Jan-: well that's what I thought, since the display_show() is likely to take ascii.
08:01 PM Jan-: but I'm not sure if C can do sparse arrays like that
08:02 PM Jan-: since I don't want to use 128 bytes for it
08:03 PM timemage: Jan-, yeah, it doesn't. you would need some statement to piecewise map the ascii code value onto the offsets into the font array.
08:03 PM Jan-: Urgh.
08:03 PM * Jan- doesn't think the atmega328p has enough ra
08:03 PM Jan-: is it me or are these things strangely under-RAM'd
08:03 PM Jan-: or is ram hard to put on a tiny processor die like this
08:03 PM timemage: Jan-, lol, for this it's got plenty. besides even if you wanted to get lazy/sloppy you could put a full table in flash.
08:04 PM Jan-: Oh it's doing a crapload of other things too.
08:04 PM Jan-: It's decoding linear timecode, which is an audio signal, and running an nrf24l01
08:04 PM Jan-: I'm already about halfway through main memory just in globals, if the compiler is to be believed.
08:04 PM Jan-: and I haven't even done the settings menu yet.
08:04 PM timemage: Jan-, right, well, do you have string literals?
08:05 PM Jan-: Only in functions, not globally.
08:05 PM Jan-: But yes lots in functions. There's one particularly huge bit of nrf24 debug that is very large
08:05 PM timemage: Jan-, as in "hello world" <- a literal not just an array of char ?
08:06 PM Jan-: as in uart_send("\r\n (XP) RF ambient >-64dBm: ");
08:06 PM timemage: Jan-, right. so that's actually taking up 30-something bytes of sram to keep that literal.
08:07 PM Jan-: Well yes.
08:07 PM Jan-: It does get a lot smaller if I don't call nrf_print_status
08:08 PM timemage: Jan-, you can implement a uart_send_P or something of that sort, that accepts a uint_ptr_t (or whatever numeric type you want). put your literal as an initalizer to a static storage duration PROGMEM qualified array. so it will go into flash. then pass that to the uart_send_P which you have use pgm_read_byte to retrieve the string characters.
08:10 PM timemage: Jan-, if you've seen F() used with Serial (Print)'s print/println on the arduino, that's what is going on. F() is some fuglieness to create something like a statement expression that has a static local progmem array and then casts it something that allows an overload of .print/.println to recognise it as a flash stored string. internally it uses pgm_read_byte to pull the string from flash. so instead of 30-something bytes of sram and flash
08:10 PM timemage: (since it needs the initialization value) you use only flash.
08:11 PM timemage: Jan-, something similar to look at it probably avrlib'c source of any of the _P versions of normal string.h functions.
08:13 PM Jan-: The only way to do a sparse ascii compatible thing would really be in a big old switch case statement, no?
08:14 PM Jan-: oh sorry I missed your comments
08:14 PM Jan-: err yes I am aware of "PROGMEM all the things!"
08:19 PM xentrac: Jan-: you can put your table in a function too
08:19 PM xentrac: like in a switch statement
08:20 PM Jan-: well yes.
08:20 PM Jan-: that uart_send call I posted is in a function.
08:20 PM Jan-: I'm not sure if all functions it in static ram the whole time, or if they're loaded from program memory on demand.
08:20 PM timemage: Jan-, well, if you wanted to represent 0-9 A-F, it would be simple enough to do something like size_t font_index(char c) { if (c >= '0' && c <= '9') { return c - '0'; } ... you do something similar through 'a' - 'f' and 'A' - 'F'
08:20 PM xentrac: at startup
08:20 PM timemage: Jan-, it would be fairly small.
08:21 PM xentrac: because the compiler can't always tell when you're going to retain a pointer to the array in RAM
08:21 PM timemage: Jan-, this is what i mean by "piecewise map" and "if they're consequative somethings"
08:21 PM Jan-: well yes.
08:21 PM Jan-: you can do most of them in a sequential fashion
08:21 PM xentrac: the string literal in your function gets copied into RAM at startup time
08:22 PM Jan-: and stays there?
08:22 PM xentrac: yup
08:22 PM xentrac: the compiler can't tell if uart_send is going to save a pointer to it and use it later
08:22 PM Jan-: oh.
08:22 PM xentrac: I mean it could if it was looking at the source to uart_send
08:22 PM Jan-: that would be why my RAM consumption goes down when I don't call nrf_print_status
08:22 PM Jan-: because it prints out all of the registers on the nrf24l01, with lots of descriptive text ;(
08:22 PM xentrac: but it probably isn't looking at the source to uart_send because it's probably defined in a different file
08:22 PM Jan-: oh no this whole project is one 1200 line file.
08:23 PM * Jan- is a terrible programmer
08:23 PM xentrac: (and I don't think that optimization is implemented anyway, but it at least theoretically could be in that case)
08:23 PM xentrac: 1200 lines is fine
08:23 PM xentrac: most of the source to vim is in files bigger than that
08:23 PM Jan-: it really should be split up
08:23 PM Jan-: but anyway
08:24 PM xentrac: timemage's advice is good
08:24 PM Jan-: I'm a bit confused.
08:24 PM Jan-: I'm not really a programmer.
08:24 PM xentrac: heh, you can't say that any more :)
08:24 PM Jan-: I've done all I can anyway. Phil has gone to bed so I have no idea if my display font code is right but I'll have him check tomorrow.
08:25 PM Jan-: if it's not it'll just be a case of flipping some bits around#
08:25 PM xentrac: cool :)
08:25 PM xentrac: congratulations!
08:26 PM Jan-: as we say on the internet, frist time using the 74hc595 :D
08:27 PM xentrac: haha
08:27 PM xentrac: everybody's favorite replacement for having enough fucking pins!
08:27 PM Jan-: well I need an 8 digit 7 segment display
08:27 PM Jan-: few things would have enough pins :)
08:28 PM xentrac: this 68332 I dug out of the trash has uh
08:28 PM Jan-: well that's 64 pins
08:28 PM Jan-: I guess some fpgas would
08:29 PM Jan-: Hmm, I also guess I need to do a cut-down I-to-A function for this. I have one already, but I don't want to use it to drive the 7-segment display, as I don't want to go from int to ascii to int and then look up another int which represents the segment pattern.
08:30 PM xentrac: I think 140 pins on the 68332
08:30 PM Jan-: showoff
08:31 PM xentrac: there's also a Spartan XCS10 on the board but it has fewer pins
08:31 PM xentrac: I didn't make the board! Or the processor!
08:31 PM Jan-: So how do I get from a uint8_t with the value, say, 23, to the values 2 and 3. Division, I guess.
08:31 PM xentrac: and I don't even havei it working
08:31 PM Jan-: but division by 10 is not nice
08:31 PM xentrac: yes, division
08:32 PM Jan-: is there a quick way of doing divide by 10 that won't cause a huge floating point library to suddenly drop into my codebase like an ACME 1-ton weight from a roadrunner cartoon?
08:32 PM xentrac: maybe use itoa
08:32 PM xentrac: it won't use floating-point
08:32 PM Jan-: I have a basic itoa that I wrote
08:32 PM xentrac: I odn't think
08:33 PM timemage: Jan-, not sure why float would be involved at all.
08:33 PM xentrac: the bigger issue is that division is really slow
08:33 PM Jan-: https://pastebin.com/dkhLqfm5
08:33 PM Jan-: but it has division
08:33 PM Jan-: and modulo
08:34 PM Jan-: which is presumably division wearing a false moustache and a funny hat.
08:34 PM xentrac: yeah, same instruction
08:34 PM xentrac: you could imagine an accidental false dependency on floating point by pulling in some .o that contained both itoa and floating-point math, but I would think avr-libc would try to avoid that
08:34 PM Jan-: I'm not using the default itoa
08:35 PM Jan-: mine just does what I need and is probably smaller
08:35 PM xentrac: that should be easy to test
08:35 PM Jan-: either wa
08:35 PM xentrac: do you know about the `size` command?
08:35 PM xentrac: if you can use the default itoa you don't have to debug yours
08:36 PM Jan-: Sure, I guess.
08:36 PM xentrac: "really slow" is something like 50 cycles I think?
08:36 PM Jan-: anyway I shall read up on how to divide by ten quickly.
08:36 PM Jan-: I don't really want to end up with ascii characters, I guess. Or do I. Hmm. Jury's out.
08:37 PM xentrac: gcc is probably pretty good at dividing by ten quickly
08:37 PM timemage: Jan-, anyway, what's the concern with division?
08:37 PM Jan-: speed, I guess.
08:37 PM Jan-: but dividing by ten won't be that slow, I assume.
08:37 PM xentrac: depends on the context
08:37 PM timemage: Jan-, you're using this to control a display though, yeah?
08:37 PM Jan-: uhhuh
08:37 PM xentrac: you probably can update the display infrequently enough that it won't be a problem
08:38 PM xentrac: if you can arrange for your number to be one byte instead of two, it'll probably be faster still and also less code
08:38 PM timemage: Jan-, yeah, find out exactly how fast you need it to be. i suspect your beyond the flicker fusion rate.
08:38 PM Jan-: we're preloading all this anyway.
08:38 PM Jan-: In fact, what am I saying
08:38 PM Jan-: it's smpte-12m linear timecode
08:38 PM Jan-: it actually supplies the numbers as BCD, with a tens group and a units group.
08:39 PM timemage: Jan-, yeah. most people have problems before trying to solve them. =P
08:39 PM Jan-: Oh but then again no. that doesn't completely help me as I need to do math on the numbers
08:40 PM Jan-: anyway that's for tomorrow, I'm going to sleep
08:40 PM Jan-: nini all