Back
[03:35:32] <STS_Patrik> template <typename T>
[03:35:33] <STS_Patrik> T FetchPayload()
[03:35:33] <STS_Patrik> {
[03:35:33] <STS_Patrik> T Val = 0;
[03:35:33] <STS_Patrik> for(size_t i = 0; i < sizeof(T); ++i)
[03:35:33] <STS_Patrik> Val += (CANMSG << (8*i));
[03:35:34] <STS_Patrik>
[03:35:34] <STS_Patrik> return Val;
[03:35:35] <STS_Patrik> }
[03:35:42] <STS_Patrik> cant get this function to work :/
[03:36:23] <STS_Patrik> FetchPayload<uint32_t>(); only manage to extract the two first bytes
[03:43:22] <STS_Patrik> i TX 0x55 0x44 0x33 0x22 but my fetch result is 0x00004455
[03:49:24] <STS_Patrik> same with uint64_t, only first two bytes appear. CANMSG is set to auto-increment index on readout
[03:50:20] <twnqx> C++ in 8bit AVRs...
[03:50:35] <megal0maniac> STS_Patrik: I'm not awake enough to look at it properly, but if you pass by reference (so an array for example) then sizeof() gives you the size of the pointer, not the data
[03:50:43] <twnqx> i'd cast CANMSG to T before shifting
[03:51:14] <megal0maniac> Had the same issue with UART, trying to shift out a char array and only ever getting 2 bytes out
[03:52:45] <megal0maniac> So I parse the array as well as the size of the array to the function
[03:52:50] <STS_Patrik> twnqx, that worked :) thank you
[03:53:10] <twnqx> so the type of canmasg was too small
[03:53:19] <twnqx> on wider shifts the bits are "shifted out"
[03:54:29] <STS_Patrik> how come two bytes made it out of CANMSG? it's a 8-bit register afaik
[03:54:45] <hypermagic> hello my friends
[03:54:51] <twnqx> probably another case of implicit cast t "int"
[03:55:01] <twnqx> int is 16bit on 8bit avrs still
[03:55:08] <STS_Patrik> i c
[03:55:25] <twnqx> canmsg should be an array of byte, iircs
[03:55:39] <twnqx> but i don't have access to my code, wrong OS atm :P
[03:55:52] <hypermagic> twhy not use (u)int(x-xx)_t ?
[03:56:12] <twnqx> templates
[03:56:22] <twnqx> and yes, castign was the soluion :)
[03:57:13] <twnqx> STS_Patrik: is that even C++? not sure if C11 brought templates to C as well
[03:57:27] * megal0maniac refers to K&R
[03:57:43] <twnqx> K&R didn't have much to do with C11
[03:58:27] <megal0maniac> You're right. It's ANSI
[03:58:31] * megal0maniac closes book
[03:58:57] <twnqx> and personally i use some features of C11 (or well, at least some features that were only standardized with C11)
[03:59:16] <twnqx> anonymous unions in structs or something like that
[03:59:20] <hypermagic> megal0maniac, whyyy ? one never close the bible ? lol
[03:59:56] <twnqx> better not open it :P it's obsolete as K&R's C standard :P
[04:00:03] <hypermagic> :)
[04:00:29] <hypermagic> c is obsolete, but we have nothing better now
[04:00:43] <twnqx> meh i really should read up on C11 more
[04:01:03] <twnqx> the threading part is "interesting" - just not so much for AVRs...
[04:01:26] <hypermagic> threading is dumb btw
[04:01:34] <twnqx> yes and no
[04:01:38] <STS_Patrik> I share some code with a colleague who is using C++ on 32bit AVR so I don't get away with using only C so it's a bit of everything in my software
[04:01:40] <twnqx> it simplifies writing blocking code
[04:01:59] <hypermagic> we need programmable logic arrays for creating parallel logic.
[04:02:07] <hypermagic> no other way
[04:02:27] <twnqx> i disagree. PLAs can't get into interesting clock regions, ever
[04:02:44] <hypermagic> i disagree with you too
[04:02:51] <hypermagic> PLA's do not need a clock
[04:03:04] <twnqx> good luck with that
[04:03:21] <twnqx> if you do simple input->output functions - ok
[04:03:39] <twnqx> as soon as state comes into play you need to know when the result is correct
[04:03:45] <twnqx> and need to save the state
[04:03:57] <hypermagic> did you say impossible? i do things like that all the time :P
[04:04:48] <twnqx> i wrote my diploma thesis on comparison between FPGA and CPU implementations of an image processing algorithm
[04:05:06] <hypermagic> http://en.wikipedia.org/wiki/AMULET_microprocessor
[04:05:35] <twnqx> yeah, heard of that
[04:05:52] <hypermagic> very bad thing only hear about this
[04:05:54] <twnqx> i wonder how many MIPS it has in the end
[04:06:04] <hypermagic> atmel should only have this cpu.
[04:06:22] <hypermagic> about 70-80% of the clocked.
[04:06:46] <hypermagic> it is just, self clocked, only eats power if it actually does something.
[04:07:01] <hypermagic> makes perfect sense to me, i don't know about you
[04:07:24] <twnqx> i'll admit i'd have no idea how to design this
[04:07:47] <twnqx> but i laugh at arm's non-performance anyway :P
[04:07:58] <twnqx> still haven't seen 3-4ghz arms
[04:07:59] <hypermagic> dont worry, it is supressed from public because it is too good
[04:08:36] <hypermagic> i have seen THz transistors already been here for >15 years
[04:09:01] <twnqx> sure, but transistor switching frequency is one thing
[04:09:12] <hypermagic> do you think darpa's quantum computer runs win8 on an i7 ?
[04:09:20] <twnqx> thz transistors are afaik not yet available in silicon
[04:09:30] <twnqx> still germanium or the like
[04:09:37] <hypermagic> no, because they are not made of Si
[04:10:21] <twnqx> FPGAs can also switch at GHz rates
[04:10:22] <hypermagic> Advanced stuff use stuff like SiC, C
[04:10:37] <twnqx> yet you don't get designs in that clock domains out of them
[04:11:00] <hypermagic> who needs that anyway for civilian use ?
[04:11:06] <twnqx> what? ghz?
[04:11:08] <twnqx> i do.
[04:11:25] <hypermagic> how about making a logic that refreshes screen at 100kHz rate ?
[04:11:49] <hypermagic> it is useless, ok, it is good if you have 100kHz oled display
[04:12:02] <twnqx> if i look at the output of today's computer games compared to c64 times, i'll keep my multi-ghz multi-core CPUs and massive parallel TFLOs GPU, thank you very much
[04:12:09] <hypermagic> you will not see any strobe effect at high speed moving things
[04:12:25] <twnqx> TFLOPs*
[04:13:03] <hypermagic> idc what you ply with, you are attacking me because i told you i dislike dumb systems
[04:13:36] <twnqx> all i am saying is that the asynchronous cpus do have issues, or they would have wider use
[04:13:57] <twnqx> and it's not because of politics or suppressing information
[04:14:27] <twnqx> all SoC manufacturers for mobiles e.g. would jump that ship if it would be usable, since lower power dissipation is what they need the most
[04:15:15] <twnqx> and i doubt that companies like google or apple wouldn't at least explore that area
[04:16:18] <hypermagic> relax dude, i know you want to believe you know it better
[04:16:34] <twnqx> no, the opposite. i like to learn new things
[04:17:00] <hypermagic> you seem very conservative though
[04:17:17] <twnqx> i have some trust in the market
[04:17:45] <twnqx> especially when it comes to technical optimization that could give a manufacturer an edge
[04:17:45] <hypermagic> the cpu i linked was already made third generation 10 years ago and fully equivalent of the std arm.
[04:18:04] <hypermagic> market is business, you are the product.
[04:18:17] <twnqx> yeah, but even the standard arm is maybe a benchmark for power efficienency, not raw power
[04:18:35] <twnqx> e.g.: it SUCKS for how low its performance is in absolute figures
[04:18:54] <twnqx> sure, there are a few things where it's good enough
[04:19:03] <twnqx> but nothing more than that.
[04:19:16] <hypermagic> i'd be happy with 80% processing power with same ized die that takes 1 microwatts while waiting for data to be processed.
[04:21:35] <twnqx> yeah, but that cpu has about... umm
[04:21:46] <twnqx> 1% or so of my PC's CPU power
[04:22:00] <twnqx> probably less
[04:22:31] <twnqx> but sure, if your main application is processing data every now and then, that cpu would do
[04:22:36] <hypermagic> yes, damn bad for 1uW idle right ?
[04:22:48] <twnqx> see
[04:22:52] <hypermagic> how much your pc consumes idling waiting for input data ?
[04:22:54] <twnqx> you focus on idle power consumption
[04:23:14] <hypermagic> power is free you know
[04:23:20] <twnqx> see: i don't care that much about idle power, as long as the power is there when i need it
[04:23:33] <twnqx> so i care about peak performance more than idle power.
[04:24:02] <hypermagic> 100x 1uW = 100uW btw.
[04:24:15] <twnqx> and i wouldn't want a 130mhz-equivalent-single-core-arm in my full hd mobile, either...
[04:24:48] <twnqx> hey, i bet they could get idle power down further if they left the 350nm process for a, say, 22nm process
[04:25:30] <twnqx> how do you do instruction timing on that thing btw?
[04:26:09] <twnqx> i mean, to write code that does some protocol in software like we do all the time on avrs
[04:26:27] <hypermagic> i never liked any clocked protocol.
[04:26:39] <hypermagic> but you can make a clock using a gate and an xtal
[04:26:46] <hypermagic> and turn it on if you need it
[04:29:54] <twnqx> not clocled
[04:30:13] <twnqx> but there are single wire protocols that require you to be +-150ns exact
[04:30:40] <twnqx> also, i think there are 8bit avrs that are in the 1µW idle power range, no?
[04:31:29] <twnqx> i wish they'd have more info on the basics of self-timed deisgns on their page :/
[04:32:59] <twnqx> wth, their pdf on self-timed ALU is... backwards
[04:33:59] <hypermagic> http://electronics.stackexchange.com/questions/7624/can-an-fpga-design-be-mostly-or-completely-asynchronous
[04:35:03] <hypermagic> "You can ignore the flipflops completely and build it all out of LUTs. And/or you can use the state elements of most Xilinx FPGAs as (level triggered) latches instead of (edge-triggered) flipflops."
[04:35:05] <hypermagic> "It irks me that people reject asynchronous design techniques, even though they theoretically have several advantages over synchronous design techniques, merely because (as others here have said) asynchronous designs are not as well supported by the available tools."
[04:35:28] <hypermagic> you are only limited by yourself.
[04:37:55] <hypermagic> http://www.ee.washington.edu/faculty/hauck/publications/MontageJ.pdf
[04:39:37] <hypermagic> http://etd.dtu.dk/thesis/211821/ep08_26.pdf
[04:40:28] <hypermagic> http://www.ecei.tohoku.ac.jp/hariyama/papers/C201207_ERSA_Asynchronous_FPGA_Based_on_Dual_Single-Rail_Hybrid_Architecture.pdf
[04:41:14] <hypermagic> http://vlsi.cornell.edu/~rajit/ps/fpga2.pdf
[04:48:43] <hypermagic> http://web.cecs.pdx.edu/~mperkows/CLASS_573/febr-2007/p20-mocho.pdf
[04:49:11] <twnqx> just reading the thesis doc on the ALU
[04:49:26] <twnqx> personally i don't see an advantage over clock gating
[04:49:50] <twnqx> (yes, i know, that's a big DON'T in fpgas...)
[04:49:53] <hypermagic> http://www.eecs.ucf.edu/~mingjie/ECM6308/papers/Asynchronous%20FPGA%20architecture%20with%20distributed%20control%20.pdf
[04:51:12] <hypermagic> well the design tools are not made to handle the timings the way you'd need to make your creation of asynchronous logic simpler
[04:51:45] <hypermagic> but there is always some magic one can do
[04:52:57] <hypermagic> http://ceit.aut.ac.ir/~pedram/Papers/Paper-Compy Element.pdf An Asynchronous FPGA logic cell implementation
[04:53:41] <hypermagic> Globally Asynchronous Locally Synchronous FPGA
http://pdf.aminer.org/000/215/715/globally_asynchronous_locally_synchronous_fpga_architectures.pdf
[04:53:51] <hypermagic> so, like, tradeoffs, hacks
[04:55:07] <twnqx> hm ok
[04:55:18] <twnqx> so the logic kind of works as i expected
[04:55:30] <twnqx> by presenting "ready" signals
[04:55:43] <twnqx> just the ready detection works different from what i expected :)
[04:56:17] <twnqx> just wonder why it's so slow
[04:56:35] <twnqx> 9-23ns for an addition...
[04:56:52] <hypermagic> last link
http://apt.cs.manchester.ac.uk/projects/processors/amulet/AMULET3_uP.php
[04:58:00] <twnqx> i wonder how fast it would be on a modern architecture
[04:58:51] <hypermagic> "The Caltech Asynchronous Microprocessor (also know as CAM) is the world-first asynchronous microprocessor. It was fabricated in 1988 by our research group at Caltech."
[04:59:04] <hypermagic> "The CAM was ported to Gallium Arsenide by Jose Tierno in 1993. The GaAs version ran at 100 MIPS, which was quite impressive at the time. The description of the GaAs design can be found in this paper."
[04:59:16] <hypermagic> does this answer your question ?
[04:59:18] <twnqx> no
[04:59:26] <twnqx> GaAs is a dead end
[04:59:36] <twnqx> far too heat and ESD sensitive
[04:59:40] <hypermagic> ofc 100 MIPS is useless.
[04:59:47] <twnqx> basically you look at it and it dies
[04:59:48] <hypermagic> it is so slow
[05:00:01] <twnqx> 20 years ago it was ok, i guess
[05:00:05] <hypermagic> :)
[05:00:11] <hypermagic> aha...
[05:00:27] <hypermagic> when you had a 386 with 20MHz ?
[05:00:33] <twnqx> never had that
[05:00:43] <twnqx> in 1993 i had at least a 40mhz 386 :P
[05:01:01] <twnqx> but i think that was 1992, so.. 66mhz 486 dx/2 i guess
[05:01:31] <hypermagic> and darpa had 350GHz cpu
[05:01:41] <twnqx> in 1992? doubt that
[05:01:45] <hypermagic> ok
[05:02:07] <twnqx> i am pretty sure that maybe 10ghz cpus are in research stage at darpa
[05:02:27] <twnqx> it's the same problem as the domino logic they describe in their async ALU
[05:02:41] <twnqx> you have dependencies in switching, and that causes delay
[05:02:55] <hypermagic> rule#1 you don't give a weapon to people as good as yours.
[05:03:01] <twnqx> which is the single reason you can pipeline consecutive stuff in fpgas
[05:03:14] <twnqx> but only for extremely repetitive things
[05:03:44] <twnqx> e.g. you can build a pipelined bitwise serial adder which will be extremely fast in clockrate, but has a high latency
[05:04:28] <twnqx> or you can wait for the whole thing to stabilize and live with the resulting drop in clockrate
[05:04:50] <twnqx> which probably powerwise is the better solution thanks to CMOS' dynamic power consumption
[05:06:11] <twnqx> do you have an idea what's keeping 10gbit ethernet from the mass markets?
[05:06:27] <twnqx> the serdes switching frequency and power consumption.
[05:07:57] <twnqx> and look how stagnant even IBM's power cpus are, frequencywise. they should be the closest to various limit (some of them even speed of light :P)
[05:08:09] <hypermagic> do you need 10Gbit/s link in your pc ?
[05:08:45] <twnqx> i'd love to have one
[05:08:56] <twnqx> it takes about two days to duplicate my file server with gbit only
[05:08:57] <hypermagic> speed rating applies a speed limitation on you anyway.
[05:09:19] <hypermagic> usb and ethernet's hardware layer is borderline retarded
[05:09:34] <twnqx> IBM Power 6: 4.2/4.5/5Ghz
[05:09:50] <twnqx> IBM Power 7: up to 4.1
[05:09:51] <hypermagic> shit by design
[05:10:01] <twnqx> IBM Power 7+: up to 4.42
[05:12:36] <twnqx> on what do you base that oppinion? the fact that it's synchronous, again?
[05:23:12] <hypermagic> partially
[05:23:27] <hypermagic> not just synchronous, but x ppm precision carrier.
[05:23:47] <hypermagic> that is simply a limitation.
[08:46:25] <hypermagic> oh yea the fundamental shaped artificial sandwitch
http://yummy-tales.blogspot.hu/2012/11/the-sandwich-guy-hexagon-shaped-sandwich.html
[09:21:32] <rue_more> I thinkthat would give me a headache
[09:27:06] <hypermagic> the possibility is quite high, though we must admit it looks good
[09:27:31] <hypermagic> it just requires you to grow some vegetables, and make your own
[09:28:14] <hypermagic> do we need that bread anyway...
[10:42:16] <twnqx> hmmm
[10:42:20] <twnqx> does any of you
[10:42:45] <twnqx> know about mixing materials? e.g. putting tin or beryllium or whatever plated jacks directly into a copper bar?
[10:42:55] <twnqx> (screwing them in, to be precise)
[14:24:27] <LeoNerd> So I've been using KiCad for approximately 15 minutes. Already I like it
[14:24:38] <LeoNerd> I -really- hate that middle-click-drag isn't pan/scroll, but I can probably patch that in somehow
[15:02:54] <apo_> Uhm.
[15:03:45] <apo_> If I use the USI on attinys as TWI, will it change the DDR for the SDA pin to input, or just pull it high?
[15:03:56] <apo_> for 1 bits, that is
[15:04:06] <apo_> for 0 using it as a drain is of course okay
[15:08:40] <LeoNerd> The USI will set the DI/DO/CLK pins correctly
[15:09:28] <apo_> so it'll actually release it instead of driving it high
[15:09:28] <apo_> okay
[15:09:30] <apo_> thanks
[18:24:00] * apo_ grumbles
[18:24:55] <Lambda_Aurigae> what'd you break?
[18:25:20] <apo_> Can't get USI TWI master to work
[18:27:39] <Lambda_Aurigae> hmm.
[18:27:44] <Lambda_Aurigae> never tried that myself.
[18:34:38] <tunixbsd> When i use the avr-gdb and try to print the value of a global variable a receive "Cannot access memory at address 0x1000100". Can someone help me ? Here is the code and the output from simavr and avr-gdb:
http://pastebin.com/w6atWdHV
[18:55:48] <apo_> ugh
[18:56:25] <LeoNerd> I'm starting to like KiCad here...
[18:56:32] <LeoNerd> One or two glitches but on the whole fairly good
[19:08:11] <apo_> http://p.0au.de/a3d4dce5/main.c anybody feel like taking a look at this? It's toggling the SCL line happily, but SDA stays low...
[19:16:05] <apo_> oh fun, in my tests I removed the line that actually sets the data register
[19:18:11] <Tom_itx> so use your backup copy
[19:20:52] <apo_> ._.
[19:20:56] <apo_> Or I could just put the line back
[19:23:53] <timemage> LeoNerd, the interface is as little inconsistent. but once you learn all its weirdness it's okay.
[19:48:39] <apo_> :o
[19:48:50] <apo_> Looks like it's writing out its stuff just fine now!
[20:23:44] <apo_> needs almost 125 µs to do START, clock out a byte, test for ACK, and send STOP :D
[21:42:58] <Shavik> I've checked out the product matrix but looking more for opinions. I'm currently using the atmega328 in a few devices but for this new device I need 2 uarts.
[21:43:14] <Shavik> Was leaning towards a 1284p but didn't know if anyone liked another chip better that'd fit the bill
[21:44:46] <umquant> Shavik: Would you be willing to bitbang one of the uarts? Or do you really need two hardware uarts
[21:44:58] <Shavik> Not willing to do that
[21:45:13] <Shavik> For various "reasons"
[21:45:36] <umquant> Gotcha. The only reason I asked is because a lot of people use a dedicated uart for serial debugging
[21:45:41] <Shavik> I'm in a major time crunch for one and I just need a solution that will work. I'd imagine my uart lib i wrote for the 328 would be fairly easy to port
[21:45:50] <Shavik> I have the primary used for a 485 communication bus
[21:45:56] <Shavik> and i need a second for planned near f uture use
[21:46:02] <Shavik> Medical application
[21:47:06] <Shavik> interesting the 324 has 2 uarts
[21:47:10] <Shavik> im sure its missing something else
[21:48:35] <Shavik> 644 might work as well i suppose
[21:48:37] <Shavik> :s so many choices
[21:49:44] <Shavik> umquant: Did I scare you away? :/
[21:50:17] <umquant> Oh no I was browsing the table haha
[21:50:21] <Shavik> oh :)
[21:50:38] <Shavik> Thought the "medical" mention might have. Thanks for helping
[21:51:04] <umquant> No worries. And that is awesome! Are you working for medical device company?
[21:51:08] <Shavik> Yes
[21:51:23] <Shavik> Not life support but connected to it
[21:51:25] <Shavik> Class 2
[21:51:35] <Shavik> Gonna cut off the info there :)
[21:51:44] <umquant> Oh wow. That's pretty intense.
[21:51:48] <Shavik> its fun
[21:51:53] <Shavik> "challenging"
[21:51:56] <umquant> I am working on getting my first embedded job
[21:52:03] <umquant> industrial devices
[21:52:25] <Shavik> I started off programming so the biggest thing i've learned about in hardware. mistakes can be EXPENSIVE :)
[21:52:55] <umquant> Anywhoo the 324 looks to be good. If that one doesn't match then I would just go with the 1284 just to be safe and have room for future growth
[21:53:14] <umquant> Oh yea you can't just recompile a PCB ;)
[21:53:24] <Shavik> So am i seeing this right? 324 is basically a 328 with 2 uarts?
[21:53:33] <umquant> looks to be
[21:54:24] <Shavik> dang
[21:54:27] <Shavik> they are all about the same price
[21:54:33] <Shavik> 324p, 644p, 1284p
[21:54:36] <Shavik> interesting
[21:54:43] <Shavik> (mouser)
[22:30:28] <Tom_itx> just more memory
[22:35:57] <Shavik> Yea, Tom_itx. looks like 644 and 1284 are about the same price but the 324 is about $1 cheaper at 50 qty
[22:36:14] <Casper> http://valotusvirhe.net/softbox/ wanna build that, but... I don't think those wooden dowel will hold well in place the way he did it...
[22:36:18] <Shavik> Guess it depends on how much i want to future proof
[22:36:23] <Casper> and seems easy to break...
[22:36:27] <Casper> but metal is heavy
[22:41:14] <Casper> the tripod I have for those are able to handle a camera of 10lbs... so I aim 5lbs max... ideally bellow 4... that include the 4 lightbulbs (2 for now)
[22:42:13] <Shavik> Oh! looks like the 324 644 and 1283 are all pin compatible. thats great news.
[22:45:27] <Shavik> Can't seem to spot the difference with the A variant.
[22:49:51] <Shavik> Found it.
http://www.atmel.com/Images/doc8190.pdf
[22:51:55] <Casper> so what is the difference?
[22:54:26] <Shavik> A is the improved version 30-50% less current consumption
[22:54:46] <Shavik> And funny thing is. at least with the 324PA. Its around $1.20 cheaper at qty per cpu
[22:54:50] <Shavik> So not sure why you wouldn't
[22:57:27] <Shavik> night all