Back
[01:55:44] rue_house changed topic of
#avr to: 8 bit atmel microcontrollers. suggest a hilight for the day to Rue_house. Todays hilight:
http://www.avrprojects.net/
[02:00:55] <rue_house> rue_house,
http://www.instructables.com/id/Led-Cube-8x8x8/
[02:17:52] <carabia> good job
[02:34:13] <rue_bed> ?
[02:34:16] <rue_bed> not i
[02:35:31] <_ami_> building led cubes require lots of patience ! :P
[02:47:11] <carabia> no
[02:50:24] <_ami_> carabia: you did make one of those?
[03:04:55] <carabia> not 8x8x8
[03:05:26] <carabia> waste of time
[03:06:07] <_ami_> lol yeah :)
[03:06:13] <carabia> world's supposed to be green. so don't waste precious energy on silly things
[03:06:17] <carabia> support al gore
[03:06:21] <_ami_> haha
[03:06:32] <carabia> i wonder how much that nigger made money out of "green energy"
[03:06:47] <carabia> presumably more than i'll make in my lifetime
[03:39:53] <_abc_> Hello. Does anyone know what asm code principle avr-libc uses to implement PGMEM stored constant tables? I assume Z addressing and SPMCR? Or does it inline constants? Or both? If anyone knows, please tell, or link to page. I will set up a test case ...
[03:39:57] <_abc_> ... later and see what is actually going on (generated code).
[03:43:57] <_abc_> *PROGMEM
[03:49:16] <_abc_> http://ww2.tiki.ne.jp/~maro/AVR/old/tips.html golden tidbits, some old, on avr-libc + asm use, tediously found on google after days.
[03:56:01] <skz81> _abc_, I just avr-gcc a sample code (just a const static char long_str[] PROGMEM = "Hello World"; actually) => seems to rely on .section for storage
[03:56:12] <skz81> .section .progmem.data,"a",@progbits
[03:56:25] <skz81> avr-gcc -S even ;°)
[03:57:30] <_abc_> skz81: thanks. My question is more along the lines "will optimized C code rely on one way always, or will optimization cause several kinds of PROGMEM stored constant access as needed". I.e. Z + SPMCR mixed with ldiw, ldi, and a few others as needed
[03:58:10] <_abc_> Clearly ldi is more efficient then Z + SPMCR. After my adventures with surprizing optimization yesterday and before I have learned to ask.
[03:59:40] <skz81> hu, ok, no clue then, sorry :)
[04:00:02] <_abc_> Nah, thanks for looking skz81. It helped.
[04:39:37] <Jartza> _abc_: umm, why should it use SPMCR?
[04:39:43] <Jartza> flash data is loaded with LPM
[04:40:15] <Jartza> Z acting as pointer to flash address
[04:40:28] <_abc_> err yes that.
[04:40:37] <_abc_> I have to go now, laters, thank
[04:40:39] <_abc_> s
[09:26:21] rue_house changed topic of
#avr to: 8 bit atmel microcontrollers. suggest a hilight for the day to Rue_house. Todays hilight:
http://www.instructables.com/id/Led-Cube-8x8x8/
[10:57:41] <grafi_> Are there any ARM channels similar to this one here on freenode..?
[11:06:46] <sabor> #arm is pretty empty, i guess you get more answers when you ask your question here
[11:11:17] <cehteh> tried ##arm ?
[11:15:52] <sabor> that looks better, thanks :)
[11:32:19] <carabia> stm32 comes to mind, too bad it really is filled with retards and clueless people, and combinations of both
[11:32:29] <carabia> #stm32, that is
[11:32:44] <Lambda_Aurigae> stm32 channel is not a good place overall in my opinion.
[11:32:57] <Lambda_Aurigae> specially if you ever thought about using anything but expensive commercial software.
[11:33:02] <Lambda_Aurigae> they hate open source there.
[11:33:08] <carabia> channel is probably fine. just that the active inhabitants are idiots
[11:33:18] <Lambda_Aurigae> which is kinda odd being the server that the channel is hosted on.
[11:33:31] <Lambda_Aurigae> the channel consists of the people in the channel.
[11:33:39] <Lambda_Aurigae> :}
[11:33:58] <grafi_> I'm trying to get into ARM dev coming from AVR. I've played around with CMSIS, but what framework/layer is recommended to start with?
[11:34:00] <carabia> no the channel is a concept which may or may not be devoid of users
[11:34:08] <grafi_> I see some is using HAL(cube?), CubeMX, rtos etc, and I see a number of other framework as well such as chibios, libopencm3. I'm a bit confused
[11:34:28] <carabia> grafi_: cmsis, or mf provided libs
[11:34:52] <carabia> chibios is not a framework, so to speak. it's an rtos.
[11:35:46] <carabia> as you're speaking of CubeMX, I guess you're doing stm32. CubeMX is also not a framework, really, it's a tool for generating init code
[11:36:30] <grafi_> ah, ok, i see, thanks for the clarification
[11:36:32] <carabia> it's quite handy when you're getting familiar with the chips. Lets you set up clocks and enable peripherals. also it has a pin mapping tool
[11:38:25] <twnqx> i'd use the same framework i use on avr
[11:38:28] <twnqx> emacs, gcc, make
[11:38:31] <twnqx> :3
[11:39:19] <carabia> grafi_: iirc you can use the std periph library for most (if not all) except the couple of cm7's they have
[11:39:28] <carabia> the std periph lib is very straightforward
[11:39:42] <carabia> use that, and cubemx to get some init code running, very fast prototyping
[11:40:02] <carabia> for cm7 you need to use the very annoying HAL library
[11:44:35] <carabia> grafi_: I guess they kind of changed the naming for hal libs on all chips. Probably is the same thing anyway. get the cubefx package for example code and the libs
[11:44:58] <carabia> x being the chip family
[11:48:58] <carabia> also st provides a packaged eclipse with arm-gcc, openocd and gdb + the libraries, which is a good choice to get started with, even though eclipse is sluggish
[11:50:49] <carabia> the alternative is to pull compiler options and linker script from examples and use whatever, but eclipse has the added benefit of being a visual frontend for gdb.
[11:52:19] <grafi_> HAL is the new version of stdperiph lib?
[11:53:51] <carabia> I think they're the same thing renamed.
[11:54:07] <grafi_> oh, i didnt know ST had its own eclipse ide. So far I've used the gnuarmeclipse.github.io setup, too bad i cant afford uVision
[11:54:28] <carabia> just that for the high-end (cm7) chips they never provided anything called standard peripheral library
[11:54:59] <carabia> well, it's not really a "customized" eclipse
[11:55:18] <carabia> it's just eclipse packaged with the necessary stuff and their libraries
[11:55:46] <carabia> http://www.openstm32.org/
[11:55:56] <carabia> it's called system workbench for stm32
[11:58:17] <carabia> well, if you're working professionally with arm chips, then your employer should probably have KEIL licences :)
[11:58:33] <carabia> or, you should persuade them to get some.
[11:59:09] <carabia> if you're a hobbyist, there's no reason at all to get one
[12:00:02] <carabia> even professionally, you can really make do without keil/iar/crossworks
[12:08:24] <grafi_> nothing professional at all :] i'm still a student and my school is only using avr, so i do not have access to any tools regarding arm
[12:12:23] <carabia> avr development is cheaper overall. i don't know many commercial alternatives for avr, IAR comes to mind being the biggest I guess. Point being, steering away from gcc is not as popular with avrs
[12:55:54] <grafi_> I have to say, the stm32 hal syntax is pretty ugly
[13:12:56] <carabia> you mean, C syntax? =D
[13:13:52] <carabia> it's quite a change coming from fiddling with avrs, but the structs provided are helpful, cause there's a lot of configuration to do.
[13:16:20] <carabia> if you steer away from the library, read the datasheet very carefully when enabling peripherals on what steps you must go through.
[13:17:11] <carabia> was debugging voluntarily some silly cm0 problems some guy was having who later on turned out to be majorly overlooking (read: too lazy to rtfm) these things
[13:31:02] <grafi_> hehe XD
[13:46:17] <grafi_> it looks like the online mbed IDE is the best choice so far, if I want to be productive that is
[13:53:39] <bss36504> grafi_: Why not just use Atmel studio and an atmel ARM?
[13:54:28] <bss36504> Then when you buy an Atmel ICE you can program and debug every chip they make, AVR(/32) and ARM
[14:02:07] <grafi_> bss36504: mostly because of the price and availability. And i'm a bit curious on the stm32 series since i see it almost everywhere
[14:02:31] <grafi_> but yup, kind of miss atmel studio now
[14:02:43] <bss36504> Well, I'd suggest assigning a price to your sanity and time then
[14:03:48] <bss36504> If you're just trying to learn arm, but you already know the tools for Atmel, I'd say go with that rather than trying to learn two new things concurrently
[14:03:59] <bss36504> If it were me in your position, that is.
[14:33:09] <grafi_> hm, you may be right. I see a pretty inexpensive cm7 board from atmel
[14:44:52] <bss36504> Oh yeah, you can go that route too. The xplain boards have a built in debugger.
[14:45:07] <bss36504> And they're not super expensive from what I remember.
[14:46:04] <bss36504> Why cm7?
[14:50:45] <grafi_> eventually I want to interface a camera, so I'm looking for a platform that have some sort of a camera interface and is fast enough to process images at 15fps
[14:51:22] <bss36504> Ah I see.
[14:51:31] <bss36504> cm7 is no joke
[14:58:05] <grafi_> is it very different from cm4? except the obvious
[14:58:53] <bss36504> I'm not sure, beyond the obvious
[14:59:03] <bss36504> I just meant it's a serious processor, just based on specs.
[15:00:02] <bss36504> I think m7 is the top of the line m-series microcontroller you can buy before you get into a-series microprocessors. Might be mistaken though.
[15:02:07] <bss36504> Ooh, so in searching for a better answer I found that ARM offers the M0 (not the M0+) IP core for free, which is pretty ballin.
[15:02:28] <specing> what
[15:02:44] <bss36504> specing:
https://www.arm.com/products/designstart/
[15:03:26] <carabia> bss36504: an stlink(v2) clone will flash and debug every chip in the stm32 family, with a price tag of ~$5
[15:03:52] <bss36504> Well that's fantastic
[15:03:55] <specing> bss36504: but $40k for prod license
[15:04:11] <bss36504> specing: That's peanuts if youre trying to get a chip off the ground
[15:04:32] <specing> bss36504: for m0 no
[15:04:50] <specing> you can make your own microcontroller for a grand
[15:04:50] <bss36504> How much is an M0+ IP core?
[15:05:04] <bss36504> ARM charges for the licensing plus a royalty on every device sold
[15:05:20] <carabia> bss36504: grafi_ also, atmel's arm "framework" is WAY different than what their similar avr-ones are. In essence, i's not really STMicro vs Atmel, it's avr vs arm.
[15:05:25] <shangul> hi. do DASA programmers(those one that connect to serial port) need external power supply?
[15:05:41] <shangul> which DASA programmer is better for me to make?
[15:06:16] <carabia> grafi_: no it's not very different compared to cm4
[15:06:17] <shangul> i also don't get first part of ""There is a transistor used to invert the reset line. If you have active reset circuitry, and if that circuitry is open collector, this programmer will draw less current from DASA
[15:06:26] <shangul> "
[15:06:40] <bss36504> carabia: Well, the Atmel ARM framework looks a lot more like the Xmega framework, which is vastly superior to the mega's framework
[15:06:57] <carabia> sure does, but I don't think he's been playing with xmegas
[15:07:17] <carabia> xmegas are marrrggggiiinnnaalll at the very very very best
[15:07:37] <bss36504> Well yeah that may be the case, but if he's learning ARM anyway, it doesnt really matter what vendor, the libs will be different than AVR
[15:07:39] <carabia> and even then, st's framework looks a lot like atmel's framework. :)
[15:07:58] <bss36504> I'm not saying xmegas are amazeballs, btw. Just that the framework is much better than avr
[15:08:07] <carabia> i hope so!
[15:08:27] <bss36504> I mean, they are objectively better chips than something vanilla like a 328
[15:08:38] <carabia> my opinion may be biased, as i've mentioned a couple of hundred times in the past, i have really bad vibes off of asf :)
[15:08:39] <bss36504> and objectively faster than any other mega/tiny
[15:09:23] <carabia> grafi_: if you want cm7, i suggest the AMAZINGLY cheap stm32 cm7 discovery board, which has everything you've ever wanted :) I have a few. they are amazeballs.
[15:09:26] <bss36504> is your bias towards the Atmel Studio integration of ASF or of ASF itself? Cause technically if you've used any sort of lib from atmel ever, it was just a (potentially older) version of ASF
[15:09:49] <bss36504> grafi_: carabia knows way more about ARM boards than I do, especially ST
[15:10:38] <carabia> I have /tried/. out of my (granted, very old) asf-experience was concluded in me thinking a) the user interface sucked (in AS), the documentation was wanting at best, which lead to confusion in the example code itself
[15:10:39] <bss36504> I was only pointing out that if it were me, and I wanted to get started quickly, I probably wouldnt change the tool and the target architecture all in one fell swoop. That is to say, you're comfortable with AS, might as well keep using it.
[15:11:10] <carabia> yes, AS is very nice in the sense that you have a uniform IDE across all of your chips if you stay in the atmel family
[15:11:16] <bss36504> ASF code and documentation are not quite 100% IMO, but compared to the old shit, it's much better. I'd give it an 8.5/10
[15:11:36] <carabia> and for a graphical IDE, MSVC blows eclipse out of the water 7 days a week
[15:11:43] <carabia> MSVS, even.
[15:11:54] <bss36504> And the other bonus of using AS is that if you buy an Atmel ICE, it covers every chip in their entire portfolio, which is great when you want to spin a custom board.
[15:12:17] <carabia> yeah, that's an added bonus, too
[15:12:33] <bss36504> And I know we're all penny pinchers, but the ICE is like $100
[15:12:34] <grafi_> carabia: I actually have a stm32 cm7 board (STM32F746G-DISCO) available, but I'm still struggling with the IDE and framework since I dont have any Keil license. I'm looking at the ATSAME70-XPLD now, though
[15:12:53] <carabia> grafi_: that's the exact board, yes
[15:13:01] <carabia> it's amazing. I tell you.
[15:13:13] <grafi_> looks good at least :p
[15:13:26] <bss36504> I tend not to stick on dev boards very long. I get bored and want to roll it into my own board almost immediately.
[15:13:27] <grafi_> I've only used it with the mbed.org IDE so far
[15:13:29] <carabia> i can help you out with it if you're running into insurmountable difficulties
[15:13:44] <carabia> bss36504: but that board is something with which you can prototype almost anything
[15:14:11] <grafi_> eexcept the lack of IO pins?
[15:14:39] <carabia> well, sure if you want a lot of IO it's not your thing
[15:14:56] <carabia> let me see how much io there was exposed
[15:15:00] <bss36504> Oh look it also has an ardunio header
[15:15:08] <bss36504> fucking yay
[15:15:08] <bss36504> jk
[15:15:14] <grafi_> and thats about it :p
[15:15:30] <carabia> meh, there's some IO available
[15:15:35] <grafi_> besides the DCMI
[15:15:38] <carabia> broken out on header, that is
[15:16:04] <carabia> for a camera i/f i can't imagine where would you need a lot of broken out io
[15:16:38] <carabia> bss36504: yes it does!
[15:16:41] <carabia> hahah
[15:17:09] <bss36504> Lets strap a ESP8266 and an RPi header into that Arduino interface.
[15:17:38] <bss36504> Or better yet, just an ESP8266 and the DIMM connector for the Pi compute module
[15:17:39] <grafi_> well, its not ideal with broen out io's, but it makes it easy to interface cheap obsolete cameras from ebay
[15:18:44] <bss36504> I'm just being a snob. Whatever works for you. I have no present need for an M7, I keep my projects simple and, more importantly, easy to assemble. BGA? No thanks. (at least until my reflow oven is up and running).
[15:20:04] <carabia> grafi_: sure
[15:22:13] <carabia> bss36504: well sure, but they're high-end chips. For quite niche applications...
[15:22:58] <carabia> as one could justify an arm ca SoC in lieu of this, even though they are way more complex.
[15:27:16] <carabia> grafi_: of course having the ffc connector limits your options, but I don't think cameras with it are that expensive off ebay, can probably get some ~2Mpx cams less than 5 buckaroos US
[15:27:40] <carabia> +for in there somewhere
[15:30:32] <grafi_> yop, you're probably right, i bet they cost about the same. But I've only orderd the one with IO pins since I haven't found my dev board yet, hehe
[15:31:09] <carabia> sure
[15:31:45] <carabia> mind you however, as you haven't played around with arms yet, starting out with a cm7 is really going off the deep end
[15:31:55] <carabia> manufacturer be as it may...
[15:33:49] <Jartza> evening
[15:34:38] <carabia> anyway i'm gonna retire for tonight. If you want to get up and running with your stmicro board, get the sw4stm32 (openstm32.org), it has everything you need installed. And then get CubeMX with which you can spit out init code and export it as a project to eclipse.
[15:34:42] <grafi_> yep, thats what I'm afraid, so I'm currently testing a stm32 cm4
[15:34:54] <carabia> cm4's pretty much the same thing.
[15:36:55] <carabia> there's a few caveats with cubemx. you need to make sure whatever peripherals you map in the pin mapper, corresponds to the provided schematic. cause peripherals can be mapped in more than one way.
[15:38:24] <grafi_> the cubemx GUI is the best way to approach this?
[15:38:30] <carabia> also last time i used it, i think it was last summer it had a stupid lil' bug that required you to make it generate separate headers for the init source files, otherwise it effed something up, I can't exactly remember what. But it's a mundane thing, a box to tick in the options, really. Perhaps they have fixed it already
[15:39:04] <carabia> cubemx is just an easy way to map peripherals and generate init code for them, and set up necessary clocks, too
[15:40:07] <carabia> it generates the necessary init files for you, which you can import as a project to eclipse if you wish to do so
[15:41:51] <carabia> all peripheral inits, clock setup and interrupt config
[15:42:25] <carabia> and whatever other misc inits there might be, of which i'm too tired to think of right now, as I should've been in bed two hours ago!
[15:45:36] <grafi_> i will give it another shot, thanks for all the input!
[15:45:58] <carabia> also before doing any real testing i suggest reading either manufacturer-specific OR general-purpose documentation of the cortex-m clock system
[15:46:16] <carabia> it will save a lot of frustration and/or debugging time
[15:48:05] <carabia> yeah. toodles.
[16:02:04] <carabia> oh i forgot. Lambda_Aurigae did you manage to figure out reported flash and sram sizes?
[16:02:19] <carabia> perhaps i can finally get off now. nn
[17:08:21] <Lambda_Aurigae> carabia, no...haven't gotten the other software configured...was having a problem connecting to the boards...turns out it was 3 usb cables that were giving me problems.
[17:08:27] <Lambda_Aurigae> they are all power only charging cables.
[17:08:45] <Lambda_Aurigae> finally got one that has the data lines connected.
[17:08:56] <Lambda_Aurigae> but just have not futzed with it since then.
[17:09:07] <Lambda_Aurigae> working 10+ hour days and all.
[17:38:27] <chisight> did they clean up cubemx imports finally? last time i tried was a year or so ago and you had to jump hoops including running a 3rd party python script but it did work.
[17:42:18] <grafi_> chisight: have you done any cm7?
[17:42:21] <grafi_> or 4
[17:47:02] <chisight> not yet, but i use hal so they should be pretty transparent mostly. I'm using m0 so far.
[18:24:44] <grafi_> chisight: oki, do you know of any (good) hal examples to learn from?
[18:37:19] <chisight> sorry, not really.
[19:18:22] <grafi_> any examples that are more advanced then blink is welcome, hehe
[21:10:50] <rue_house> http://ruemohr.org/~ircjunk/tutorials/elex/fsmflash/main.html
[21:15:33] <rue_house> (pov is a great next step after blinking an led)
[23:39:40] <Levitator> Does anybody know of a site that explains how to link an MCU program so that it is self-updateable, as in OTA?
[23:40:39] <Levitator> I think it somewhere along the lines of linking the app in different sections and then using objcopy to copy the variable section and just update that.
[23:41:37] <Chillum> the esp8266 can do it
https://elementztechblog.wordpress.com/2016/06/28/over-the-air-update-for-esp8266-using-arduino-ide/
[23:42:55] <Funklord> What do you mean self-updateable?
[23:42:55] <Levitator> My question is; how do you link the app so that the boot section is at the beginning, and so that the boot binary doesn't change?
[23:43:07] <Funklord> I think the procedure will vary depending on which specific MCU, where you put the bootloader etc.
[23:43:08] <Levitator> So that you can do update over-the-air.
[23:43:57] <Levitator> I don't think it should be MCU-specific. Basically, you have one executable, but it has to come in two parts. A static boot section, and a variable application section.
[23:44:38] <Funklord> I think you can look at any bootloader project for that specific MCU to find out, they'll probably include a script to link an example program to make it compatible
[23:44:55] <Levitator> You want to be able to rebuild this app in such a way that the boot section is always built deterministically, with all symbols at the same address.
[23:45:01] <Casper> Levitator: boot loader
[23:45:25] <Levitator> I've seen how the 8266 does it, and it's not intuitive.
[23:45:36] <Casper> for example, for avr, at the top of the flash you have a second program space
[23:45:58] <Funklord> AVR8 is probably much easier, or at least easier to understand
[23:46:06] <Casper> the avr can start from 0x0000 or start from the bootloader area, ex: 0xC000
[23:46:12] <Levitator> Yeah. I want to be able to implement that again, in my own app, so that it can update itself not through the UART, but OTA.
[23:46:30] <Casper> you basically put an updater program in the bootloader area at factory
[23:47:08] <Levitator> But there isn't some way to tell the linker "This stuff gets built at the beginning/end at the same addresses every time"?
[23:47:21] <Casper> then when you want to update, you jump to that area or reboot to it and make sure that the "update" condition are met (press a button, write to eeprom, ....)
[23:47:48] <Casper> once the bootloader start, it can do anything
[23:47:54] <Levitator> Come to think of it, I bet the way it's done is using a ton of linker-script magic.
[23:48:01] <Casper> it can write to the main program area
[23:48:08] <Funklord> there shouldn't be any difference in the way you *need to* format it for different bootloaders, but the way the bootloader works and memory is laid out does matter
[23:48:47] <Funklord> fuse settings etc. And a wireless bootloader is surely larger than a serial one
[23:49:12] <Levitator> I know the 8266 has a bunch of code in ROM, and the way that works is that there is a linker script entry for each function. It looks really tedious.
[23:49:31] <Casper> if you need to update the bootloader... you basically do it in 2 pass, first, the bootloader start, erase the main application area, write a bootloader updater application at the main app space, run the main code, update boot... then restart the bootloader, write the new main app...
[23:49:38] <sabor> Levitator: there are linker configurations telling it which section to put where
[23:50:10] <sabor> you can also define which functions goes to which section
[23:50:31] <Levitator> It's not enough to have different sections, though. You have to be assured that the boot section is built with deterministic addresses.
[23:50:39] <sabor> it depends a bit on the compiler/linker you use and on the cpu type
[23:50:53] <Levitator> So that if the app needs to call into the boot section for network routines, it can find them.
[23:51:32] <sabor> then you have to put a function table into that section
[23:51:58] <Funklord> sabor: Are you aware of any AVR8 bootloader project where the other code calls functionality from the bootloader?
[23:52:05] <Levitator> sabor: Yeah, I guess you could place a function table at a specific address.
[23:52:30] <sabor> Funklord: yes, i remember a post of some usb bootloader i think which does that
[23:53:12] <Funklord> Useful for OTA update projects, where you simply can't fit two copies of the network stack etc.
[23:53:27] <Casper> Levitator: google bootloader
[23:54:43] <Levitator> Ok. Well, thanks, all.
[23:55:54] <Funklord> http://www.avrfreaks.net/sites/default/files/bootloader_faq.pdf
[23:59:52] <sabor> here might be some pointers too:
https://forum.arduino.cc/index.php?topic=332191.15