Back
[09:02:53] <LeoNerd> Is avr-gcc going to be sensible with struct { unsigned int x[4] : 2; } ?
[09:03:03] <LeoNerd> I'm hoping it will store the four values efficiently in 1 byte
[09:23:57] <GeneralStupid> LeoNerd: you should use uint8_t instead…
[10:23:03] <Lambda_Aurigae> how would you store 4 unsigned int in one byte?
[10:23:13] <Lambda_Aurigae> oh...2 bits worth..
[10:23:18] <Lambda_Aurigae> it might.
[10:23:44] <Lambda_Aurigae> but use uint8_t, definitely...as int is not 8bit as I recall.
[10:26:17] <Tom_L> 2c worth
[10:26:21] <Tom_L> is that the same?
[10:28:11] <specing> or use Ada :)
[11:06:27] <carabia> specing: how much avr stuff have you actually done with ada?
[11:06:44] <carabia> or any "embedded"?
[11:07:07] <carabia> led blinking doesnt count
[11:17:25] <jben> /b/b 2
[11:42:33] <twnqx> leonerd: i'd say unlikely :P
[11:43:00] <twnqx> +
[11:44:38] <Lambda_Aurigae> I know it can do bitstuffing
[11:44:46] <Lambda_Aurigae> but dunno if it will work that way.
[11:59:42] <specing> carabia: 0
[11:59:49] <specing> carabia: I haven't even done blinking
[13:04:25] <LeoNerd> Hrm. I suspect I have a timing failure somewhere in my i2c master impl. :( If I put enough printfs to the uart in, it doesn't fail
[13:04:29] <LeoNerd> if I remove some, it fails
[13:07:58] <LeoNerd> Ah, in particular, it seems if I putc (and therefore delay) before the start code, then all is fine. I wonder if I'm not waiting properly for back-to-back transactions
[15:22:48] <NicoHood> is it more common for spi to first init the SS pins and then the peripheral or vice versa?
[15:22:48] <NicoHood> or in other words does the order matter?
[15:31:01] <Tom_L> if you need to send commands to the slave the SS must be enabled first
[15:49:30] <carabia> NicoHood: 99% time doesn't matter i suppose, but if you're paranoid you can always use a pullup on it to ensure its disabled on reset
[15:49:40] <carabia> on the ss that is
[15:50:17] <carabia> some devices are active high i guess so in that case a pulldown
[15:50:35] <NicoHood> i am just asking because the source i found did it different
[15:50:47] <carabia> ?
[15:51:55] <NicoHood> first init the ss then init the spi peripheral
[15:51:59] <NicoHood> i wanted to do it different
[15:52:16] <NicoHood> cause one of my device needs to send some commands in its begin function
[15:52:26] <NicoHood> however thats possibly also not that clever
[15:54:26] <carabia> well use a pullup/dn ensure its disabled on reset and then init it at your leisure
[15:54:53] <carabia> then the code doesnt mattaer
[15:54:55] <carabia> matter*
[15:55:26] <NicoHood> 4k7 to gnd
[15:55:55] <carabia> is it active high ss?
[15:56:03] <NicoHood> no
[15:56:05] <NicoHood> thats weird
[15:56:23] <NicoHood> but thats for the 5->3.3v conversion
[15:56:38] <carabia> im not following you...
[15:56:50] <Tom_L> the device must be 3.3v
[15:57:06] <Tom_L> and his master is 5v or vise versa
[15:57:08] <NicoHood> https://github.com/limpkin/mooltipass/raw/master/kicad/mini/schematics.pdf
[15:57:43] * limpkin sighs
[15:58:06] <NicoHood> when SS is LOW the chip is active
[15:58:23] <NicoHood> limpkin can you solve this? why does the PCB has a pulldown not up?
[15:58:52] <Tom_L> so you want the pin pulled high in software unless you plan to enable the slave
[15:58:53] <limpkin> all the ICs you are looking at use 3.3v signal levels
[15:59:06] <Tom_L> i didn't click
[15:59:50] <carabia> it's a voltage divider
[16:00:09] <NicoHood> and the line to gnd?
[16:00:13] <NicoHood> isnt this a pulldown?
[16:00:39] <NicoHood> I never did such a conversion with resistors
[16:00:45] <carabia> no
[16:01:13] <carabia> well, grab some resistors and a multimeter and see for yourself.
[16:01:30] <carabia> also google is known to help with issues such as these
[16:01:39] * limpkin facepalms
[16:02:02] <NicoHood> well if i dont know what to search for that gets hard. thx for the help
[16:02:14] <NicoHood> so i can treat this as "no pulldown" basically?
[19:54:10] <LeoNerd> func_P(1,2, (uint8_t[]){1,2,3,4,5,6})) <== how do I apply PROGMEM to this array?
[19:55:34] <LeoNerd> Ah; (PROGMEM uint8_t[]) ...
[19:59:11] <LeoNerd> Hrmmmm... the syntax compiles but I'm not sure if it's working
[20:01:01] <cehteh> just make the array much bigger, and check the program size
[20:01:40] <cehteh> i think it should work, but otherwise just make the array static outside of the func and use it there
[20:02:24] <LeoNerd> Ahhh... tricky. This is an array literal though
[20:02:25] <cehteh> gcc's statement expressions could work too
[20:02:30] <LeoNerd> I don't know as if it can be static
[20:03:22] <cehteh> func_P(1,2, ({ static PROGMEM uint8_t[] t = {1,2,3,4,5,6}; t}))
[20:03:32] <cehteh> fugly :)
[20:04:01] <cehteh> but .. iirc the first thing you brought up should work
[20:04:31] <cehteh> func_P(1,2, (uint8_t[1000]){1,2,3,4,5,6}) ... check if the text segment becomes roughly 1000bytes bigger
[20:04:48] <cehteh> eh with PROGMEM of course
[20:05:06] <cehteh> newer gcc has also a __flash keyword
[20:05:24] <LeoNerd> Hah.. oops
[20:05:28] <cehteh> not as ugly as PROGMEM because its an actual memory specifier
[20:05:30] <LeoNerd> error: compound literal qualified by address-space qualifier
[20:05:30] <LeoNerd> }
[20:06:01] <cehteh> i think i do that somewhere
[20:06:26] <cehteh> note that you need to read the flash byte by byte later
[20:06:43] <LeoNerd> Sure; I have *that* part working
[20:06:48] <LeoNerd> Ijust don't have the data storage.
[20:06:54] <LeoNerd> but it seems a statement-expression solves it
[20:07:07] <LeoNerd> text segment is now 52 bytes smaller
[20:07:15] <LeoNerd> and my code works :)
[20:10:23] <cehteh> smaller?
[20:10:26] <cehteh> should be bigger
[20:11:53] <cehteh> #define PSTR(s) ((const PROGMEM char *)(s))
[20:12:07] <cehteh> ... thats how avr libc does it for strings
[20:12:46] <cehteh> should work with arrays too mhm
[20:13:18] <cehteh> ah .. maybe you need to give the size
[20:13:46] <cehteh> foo[] is a pointer while foo[size] is the array in C
[20:14:31] <LeoNerd> Er.. sorry. bss segment is smaller
[20:14:44] <LeoNerd> anyway, it works
[20:15:06] <cehteh> :) .. i mean i expected the statement expressions to work .. but just a cast would look cleaner
[20:15:20] <LeoNerd> Iwonder if it's suitably static
[20:15:25] <LeoNerd> i.e. that Ican have lots all called 'icon'
[20:16:34] <cehteh> because of name clashes?
[20:16:52] <cehteh> just concat __LINE__ to it then
[20:17:56] <cehteh> .. but again first try the array with size, that may work