Back
[00:25:55] <nilc> hi hi
[00:26:07] <nilc> I'm trynna learn some attiny13 programming.
[00:26:18] <nilc> Wonder if someone would critique my code.
[00:26:35] <N1njaneer> Pastebin it
[00:26:44] <Roklobsta> too many tabs.
[00:26:48] <Roklobsta> use less tabs
[00:26:55] <N1njaneer> More cowbell()
[00:27:06] <nilc> https://github.com/colinmeyer/fourbinerone/blob/master/fourbinerone.c
[00:27:15] <nilc> It's working reasonably well.
[00:27:41] <nilc> Got some CTC for a display timer. Four LEDs, homemade pwm (four bits worth).
[00:28:07] <N1njaneer> Seems well commented and well layed-out. Certainly a lot better than a lot of stuff that hits this channel. :)
[00:28:17] <N1njaneer> And if it's working, that also puts it way ahead :)
[00:28:25] <nilc> The trouble is in timing.
[00:28:29] <N1njaneer> Because most code people post is broken. :)
[00:28:41] <N1njaneer> Is it running too slow?
[00:28:44] <nilc> I count one "click" for each display interrupt.
[00:28:54] <nilc> And every 1000 clicks, I rotate the display.
[00:29:13] <N1njaneer> Does it seem to be running at an eighth of the speed you expect? :)
[00:29:18] <nilc> It runs as expected, except for that every 21 or 22 iterations of display rotating, it suddenly runs fast for one iteration.
[00:29:24] <nilc> A kind of stutter.
[00:30:02] <nilc> No, the speed is about right; see my comment to see if I've understood the spec sheet for clock speed and timer speed.
[00:30:12] <nilc> It's just not quite consistent.
[00:30:14] <nilc> Maybe it
[00:30:29] <nilc> 's the 16 bit int overflow, but I don't think so.
[00:31:05] <N1njaneer> Hazarding a guess without delving in too deeply, but you may need to add some atomic sections if you are setting anything in your main while() that is interacting with things in the ISRs.
[00:31:24] <N1njaneer> Is the problem absolutely deterministic, or is it rather random in occurance?
[00:31:33] <Roklobsta> yeah atomics
[00:31:52] <nilc> So the ISR is doing an atomic increment of clicks.
[00:32:01] <nilc> And I'm just reading clicks from the main routine.
[00:32:25] <N1njaneer> Yes, but you have a split test/set in main
[00:32:32] <nilc> The display is double buffered, to avoid update jitter.
[00:32:41] <nilc> Ah, interesting.
[00:32:58] <nilc> So, by "atomic", do you mean turn off interrupts, then turn back on?
[00:33:12] <nilc> Or is there some other atomic operation that I don't yet understand?
[00:33:50] <N1njaneer> Remember that if the ISR is updating something like clicks, the if() can do the test, come up with the result, ISR swings in and changes clicks, then main resumes and uses the test result version of the if() -- can cause all sorts of weird stuff to happen :)
[00:34:24] <N1njaneer> Yes, basically just calling cli()/sei() pairs will do it, though there are some useful atomic macros if you want to use a less direct notation.
[00:34:25] <nilc> Yes, I understand that. I don't yet have a good feel for the speed of the instructions vs. how often my ISR will fire.
[00:34:38] <N1njaneer> http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html
[00:34:49] <nilc> Cool, I'll go have a look.
[00:35:51] <N1njaneer> The speed isn't the issue - the concern is that ANY clock-cycle can basically be split by an ISR, and at the worst of times. A truely terrible one would be in the midst of copying a 16-bit value like a short. If the ISR first and modified a variable involved in the middle of a 16-bit copy, then half the byte may be corrupted.
[00:36:23] <N1njaneer> Worse yet, you may not ever see the problem happen in your application till after you deploy, if you get really lucky/unlucky. :)
[00:37:32] <nilc> It's interesting to me how regular the jitter is. Every 21 iterations of rotating the display (= 4000 clicks or ISR executes).
[00:37:53] <nilc> At least that's as best as I can count it. It may actually vary some, beyond my perception.
[00:37:53] <N1njaneer> So just from a general good coding practice you want to use atomics when dealing with data that needs to be exchanged reliably between threads/interrupts. There are certain circumstances you can ignore them (such as unidirectional data-flows) but you have to be careful.
[00:38:16] <Roklobsta> nilc: with avr a bunch of C code can turn into 4 opcodes
[00:38:17] <N1njaneer> If you are getting an absolutely regularly occuring problem like that, you may have a timing conflict going on elsewhere.
[00:38:24] <Roklobsta> don't swaet the number of opcodes
[00:38:48] <nilc> I do sometimes read the assembler output of gcc, to understand what it's generating.
[00:39:07] <nilc> My crappy pololu ISP doesn't support debug wire.
[00:40:53] <nilc> Ok, the example for util/atomic.h is about copying a uint16_t, which is exactly what I'm doing.
[00:40:58] <nilc> I'm going to play with that.
[00:42:38] <N1njaneer> Yeah, it's a good example on how stuff can get mucked up with the ISR's. Hopefully it may help.
[00:43:25] <N1njaneer> Also, keep in mind variables likes 'flags' also can suffer this.
[00:44:23] <nilc> Hmm, really? Yes, I suppose that clearing a flag can take several ops.
[00:44:45] <nilc> Reading a bit from a uint8_t should be ok, right?
[00:44:47] <N1njaneer> You are updating flags in the ISR, and you are also updating it in switch_fb() which is called in your mainline loop. The switch_fb() is subject to the same ISR splitting. "flags ^= FRAME_BUFFER" is probably not compiling down in to a single instruction.
[00:45:01] <nilc> Yep
[00:46:43] <N1njaneer> nilc: You could read/copy a bit in a single instruction (assuming a 1-cycle instruction), but you cannot act on that operation until the next cycle occurs, at which point a split could have occured. You have to anaylze your logic to figure out of that could ever possible cause a problem. If yes, it needs an atomic section.
[00:47:08] <N1njaneer> Unfortunatly the AVRs don't have any atomic test-set instructions in the opcode set.
[00:47:28] <nilc> Ok, gotcha. Good stuff. This is an aspect of AVR programming that I haven't yet thought about.
[00:48:14] <N1njaneer> It's subtle, but it can realllllly bite you in the ass at times. You are following all of this really well, though, so I'm sure you'll have it mastered in no time.
[00:48:53] <nilc> I've been playing with these things for a few months now, nothing serious, just fun little progs.
[00:49:56] <N1njaneer> They're quite addictive.
[00:54:32] <nilc> zoop zoop! that did the trick very nicely!
[00:54:37] <nilc> https://github.com/colinmeyer/fourbinerone/commit/b99f4477cf1e7abcfa4aebee764db5a8efbdef41
[00:54:55] <nilc> :D thanks very much, N1njaneer.
[00:55:02] <N1njaneer> Sweeeet!
[00:55:15] <N1njaneer> You are very welcome!
[00:55:16] <nilc> I'm going to go and add an atomic block around the flag manipulations.
[00:58:40] <N1njaneer> And see, when you code more stuff in the future with ISRs, you'll immediately think about adding atomic operations, and thus your code foo will be strong and you will destory problems before they are problems!
[01:00:13] <nilc> Sure enough, one bit xor in my flags var is four opcodes.
http://pastebin.com/b0snzHTL
[01:02:12] <N1njaneer> Yeah I suspected that may be the case.
[01:38:03] <vsync_> mornin
[01:39:40] <N1njaneer> Mmm I should probably head home and to bed. G'night all!
[04:16:38] <vsync_> ahhh tomorrow i'll be getting a few sta013's
[04:18:00] <vsync_> was also thinking of the new vs chip 1003 i believe it was. But i don't need the recording capability
[05:23:53] <Valen> I found the problem with my USB on the mega32u4, it was the #@$#@%@#$% mother#@$#$#@ usb cable!, I used 2 different cables, they both sucked
[05:26:43] <theBear> hehe, one of us shoulda thought of that, sorry :) been a while since i had a dodgy usb cable, but it's ALWAYS the problem when you can't workout the problem :)
[05:28:46] <Valen> 2 of them
[05:28:51] <Valen> with the same fault
[05:29:04] <Valen> both new
[05:29:13] <Valen> much screaming was done
[05:29:21] <Engen> store bought or online?
[05:29:56] <theBear> i've had 4 in a row when dealing with stupid ft232 windows driver balls.... i was not happy
[05:31:41] <Valen> DX ones
[06:26:41] <dsaw> I have such SPI master signal
http://oi44.tinypic.com/298mty.jpg and I use avr as slave, I need to set the slave as CPHA = 1, CPOL = 0, right?
[06:26:59] <dsaw> the blue signal is the sck, red one is the message ( 0x7F)
[08:35:10] <Fleck> fuse "setter" for linux - gui - anyone?
[09:31:59] <Casper> Fleck: avrdude don't do the job?
[09:33:30] <megal0maniac> Fleck:
http://www.engbedded.com/fusecalc and then avrdude
[10:00:50] <megal0maniac> Quick C question
[10:01:02] <megal0maniac> I have variable x in main()
[10:01:55] <megal0maniac> I pass it by reference to function1() with function1(&x), function1's header is function1(int *bleh)
[10:02:26] <megal0maniac> Now how would I pass this on to function2(), in order for function2 to modify the int located in main()?
[10:02:56] <megal0maniac> The "obvious" answers are not working. I am on level n00b still
[10:02:58] <ambro718> the same way
[10:03:24] <megal0maniac> So no need to dereference first in function1?
[10:03:36] <twnqx> no
[10:03:37] <ambro718> function2(int *bleh) { *bleh = 5; } function1(int *bleh) { function2(&*x); }
[10:03:48] <ambro718> and &* is the same as nothing
[10:03:48] <twnqx> ... why &*x
[10:03:56] <twnqx> exactly, just function2(x)
[10:03:58] <ambro718> so he can see it's really the same way
[10:04:28] <megal0maniac> Okay, that's what I thought. Well that kinda sucks, because now I don't know what the actual problem is :)
[10:04:32] <megal0maniac> Thanks
[10:05:34] <twnqx> you could let us laugh at your code :P
[10:05:48] <megal0maniac> No it's okay :P
[10:05:51] <megal0maniac> For now
[10:06:17] <megal0maniac> I want to try first. If I really get stuck, I'll shout for halp
[10:06:48] <theBear> maybe variable x is a kind that doesn't exist across 'function boundaries'
[10:06:59] * theBear is being careful not to use a specific keyword
[10:08:24] <twnqx> bah, it's just an interrupt handler and he forgot the volatile keyword
[10:08:46] <ambro718> I never use volatile, never had problems before
[10:09:17] <ambro718> cli/sei includes a memory clobber, so as long as you sync with cli/sei there shouldn't be race conditions
[10:09:32] <twnqx> ever heard of compiler optimizations?
[10:09:49] <twnqx> if you don't tag the variable volatile, the compiler can safely assume that it does not change, period
[10:10:02] <ambro718> yeah, the memory clobber is what avoids reordering of memory accesses
[10:10:06] <twnqx> so a while (!locked) can be legally optimized to while(1)
[10:10:30] <twnqx> ratherm a locked=0; while(locked) {} can be legally optimized to while(1)
[10:10:31] * megal0maniac puts blinkers on
[10:10:49] <twnqx> !locked*
[10:10:51] <ambro718> twnqx: yeah, this is a problem, because you didn't sync with cli/sei
[10:10:58] <twnqx> how can i sync
[10:11:06] <twnqx> i am waiting for an interrupt handler to change the flag
[10:11:53] <twnqx> while (!triggered) { sleep (); } is a standard part of almost all of my µC programs
[10:12:07] <ambro718> while (1) { cli(); int x = locked; sei(); if (!locked) break; }
[10:12:19] <ambro718> sorry, while (1) { cli(); int x = locked; sei(); if (!x) break; }
[10:12:20] <Casper> megal0maniac: why not define it as a global variable then?
[10:12:21] <RikusW> megal0maniac: you're passing a pointer actually
[10:12:34] <twnqx> ... yeah, that clearly makes more sense than volatile itn locked;
[10:12:37] <Casper> then no need to pass it as a pointer or at all?
[10:12:44] <RikusW> passing by reference is for C++ as in void funtionX(int &i)
[10:13:18] <ambro718> twnqx: I was just trying to demonstrate that when access is synchronized with cli/sei, volatile is not needed. If this is too much overhead use a volatile then....
[10:13:59] <twnqx> i would say
[10:14:01] <RikusW> then calling functionX(somevar);
[10:14:18] <twnqx> that memory barriers PLUS extra variables PLUS turning off interrupts is too much overhead in any case
[10:14:26] <twnqx> Casper: and global variables are bad.
[10:14:40] <ambro718> sometimes you have to do cli/sei anyway, in that case you don't *also* need volatile
[10:14:51] <RikusW> twnqx: it depends on how you use them
[10:15:44] <twnqx> RikusW: nah, they are mostly bad :P
[10:16:00] <RikusW> how about goto's :-P
[10:16:10] <twnqx> mostly bad, too
[10:16:17] <RikusW> I find them useful on occasion
[10:16:20] <twnqx> "mostly" as in "there are a few legitimate uses"
[10:17:05] <RikusW> Steffan-: doing the weekly #avr inspection ? :-P
[10:17:39] <Steffan-> no i was looking for someone
[10:19:48] <megal0maniac> RikusW: We immediately fail if we use global variables
[10:20:16] <RikusW> ouch
[10:20:16] <megal0maniac> Or gotos :P
[10:21:58] <RikusW> megal0maniac: int i; int *p = &i; *p = 5; // i is now 5
[10:22:37] <megal0maniac> I've got that down, now something else is wrong :/
[10:24:01] <megal0maniac> btw hi RikusW :)
[10:24:09] <RikusW> hi
[10:24:14] <RikusW> paste the code ?
[10:24:35] <RikusW> maybe its something obvious to me ;)
[10:26:49] <megal0maniac> Okay one sec
[10:33:58] <megal0maniac> Oh great
[10:34:07] <megal0maniac> fixed some unrelated errors and now it compiles
[10:38:20] <theBear> don't sound unrelated to me
[10:38:49] <theBear> compiling is a complex thing, specially when optimization is involved
[10:44:37] <Casper> grrrr need to tell yet another client that her antivirus is junk and is what cause the issues (freeze at shutdown)
[10:44:47] <Casper> isp provided antivirus....
[10:44:58] <Casper> guess what base is behind it...
[10:45:02] <Casper> … AVG !!!
[10:45:06] <megal0maniac> NEVER!
[10:45:09] <megal0maniac> AVG IS PERFECT
[10:45:15] <Casper> yeah, sure...
[10:45:17] <megal0maniac> (and nobody lies on the internet)
[10:45:22] <megal0maniac> and all that :)
[10:45:38] * megal0maniac uses Avast. Getting a bit noisy, but still works pretty well
[10:46:09] <bss36504> http://i0.kym-cdn.com/photos/images/newsfeed/000/428/075/30a.jpeg
[10:46:32] <megal0maniac> Casper: I tend to have pretty tight relationships with my clients, and typically get to replace AVG with something else before it becomes a problem ;)
[10:48:21] <theBear> before that ms stuff existed avg with sensible non-default settings was both the most reliable and least resource intensive av around, both free and commercial versions
[10:49:15] <theBear> course now i don't care, but i hear that the ms one works fine, and if i know one thing about modern ms os's, it is not to mess with them and avoid 3rd party software at all costs
[10:49:28] <theBear> wait, 2 things, they are a steaming heap of shit also
[10:54:43] <Casper> megal0maniac: what's your free love in the AV world?
[10:57:21] <megal0maniac> Avast, generally
[10:59:13] <theBear> avast not only misses a LOT, but uses stupid resources !
[10:59:56] <megal0maniac> Better than AVG
[11:00:25] <megal0maniac> And I've had no issues with it personally, or on client machines.
[11:01:56] <theBear> i've had many machines come to me virused while running a perfectly oblivious avast over MANY years including recent ones, not to mention seen it using stupid amount of cpu for no apparent reason (on different occasions of course) .... if i see it on a machine that is 'broken' the first thign i do is remove it
[11:02:10] <theBear> i'm talking literally hundreds of machines
[11:02:17] <theBear> all with competely different backgrounds
[11:02:33] <vsync_> yay software nerds wanking in circles
[11:02:37] <theBear> and it's not always 'current' viruses, some of them i known by name for over 15 years
[11:03:06] <theBear> vsync_, fuck you, and if it wasn't for people like us you couldn't be here right now
[11:03:34] <vsync_> doubt it
[11:03:39] <vsync_> but thanks
[11:03:52] <megal0maniac> theBear: Well like I said, personally no issues. And it's currently using 5.5mb of RAM and no CPU time. YMMV :)
[11:04:20] <megal0maniac> And some older versions were full of crap, granted
[13:58:54] <Fleck> Casper, megal0maniac_afk cool, but app would be great - read fuses, set fuses...
[14:22:17] <ColdKeyboard> jadew: Do you have the time to take a look at my SUMP metadata? :)
[14:28:25] <jadew> ColdKeyboard, I'm during work hours now, so I can't, a bit later maybe
[14:29:28] <megal0maniac_afk> Fleck: Write one :)
[14:29:59] <ColdKeyboard> jadew: Ok, great. Whenever you get the time, it's no rush :)
[14:31:33] * megal0maniac_afk sends IRC log to jadew 's boss to show how well behaved he is
[14:35:13] * jadew sends his boss' email address to megal0maniac_afk
[14:39:33] <execi> Okay so i'm hooking up an atmega32 to an sd-card. Since I'm running atmega at 5 volts i need to do a bit of tinkering... I take it sd-cards aren't 5v tolerant? Cause i've seen some schematics with just a series resistor. Then I've seen a few with resistor dividers, with 1.8k in series and 3.3k to gnd. However, doesn't this equal in ~1.7V?
[14:40:02] <execi> is this just a mistake of my calculations or understanding, or is that enough to be detected as high for the sd?
[14:40:31] <execi> I'm just breadboarding this. When I'll put it together i might use a logic level converter, but can't access one right now
[14:52:33] <N1njAway> execi: Generally you can just put a single resistor in-line with the 5v->3V dataflow (like a 50-12 ohm) and that will suffice, but the more ideal way would be to use a level-shifter like a 74LX125 or similar. You can potentially get in to some problems with high-speed/impedence with two-resistor voltage dividers with larger values.
[14:52:43] <N1njAway> +50-120 ohm
[14:53:44] <megal0maniac_afk> http://www.pjrc.com/teensy/sd_adaptor.html
[14:53:59] <megal0maniac_afk> Nice, simple implementation with the 74LX125
[14:54:51] <execi> yeah, as stated, i cannot access one right now
[14:55:31] <execi> so a single resistor in series should do? 50-120 ohm sounds awfully small though...
[14:55:33] <N1njAway> execi: The series-resistor trick works well in the case that the 3.3V input device has clamping diodes in it. I believe SD-Cards do, but you'd have to check the spec to be sure.
[14:55:46] <execi> Yeah I know that, was wondering whether they do...
[14:56:00] <execi> cause i've seen some schematics with just a series resistor but iirc they are far bigger than 50-120 ohms
[14:56:06] <execi> or were you talking kilos
[14:56:20] <N1njAway> No, just ohms.
[14:56:25] <execi> really?
[14:56:43] <N1njAway> You can also add the clamping diode externally.
[14:57:03] <execi> yeah can just use a 3v3 zener
[14:57:30] <execi> problem is can't get those now either hah
[14:57:46] <execi> I'm gonna try with just a series resistor
[15:00:05] <N1njAway> Damnit, why has copy and pasting links from Google gotten so damn difficult as of recent
[15:01:00] <N1njAway> execi: This may be of some help --
http://goo.gl/8Afeb1
[15:01:08] <N1njAway> Rok: Welcome back!
[15:01:42] <N1njAway> execi: See Tip#10 for details on the series resistor / diode clamp
[15:02:34] <N1njAway> Rok: Welcome back!
[15:02:43] <jadew> N1njAway, most likely because they're trying to fit in there all your browsing history, your social security number, number of siblings and what kind of food you like
[15:03:20] <Roklobsta|2> yeah stupid wifi
[15:03:22] <Roklobsta|2> thanks
[15:03:50] <N1njAway> execi: Tip #12 explains the relationships on doing the two-resistor divider and how it affects rise/fall times and power dissapation. Again, the ideal way is with a level-shifter chip. The other solutions require some further consideration. :)
[15:04:20] <N1njAway> Rok: You fell off last night a bit before it, but that guy with the LED ISR code... atomic sections immediately fixed the problem!
[15:06:11] <Roklobsta|2> oh good. they always do
[15:07:03] <N1njAway> execi: Hopefully that document gives you some insight. :)
[15:08:06] <Roklobsta|2> i worked at a company that complained the compiler was buggy because optimisation always made the (deployed) embedded system crash. When I a) added 'volatile' in the right places b) judicious use of enabling and disabling interrupts (atomic) suddenly -O2 worked like a champ
[15:11:32] <N1njAway> lol wow
[15:17:56] <N1njAway> I wish you could combine pick and place feeders to make new sizes.
[15:18:04] <N1njAway> Like, if I could put some 8's together to make 16's
[15:22:13] <Roklobsta|2> i wishes were fishes...
[15:23:41] <jaldunate> Hello; a little question: ¿does any avr has a persistent memory that doesnt have an endurance limit such as EEPROM?
[15:24:02] <jaldunate> i mean persistence for not being deleted when voltage is off
[15:24:20] <specing> no
[15:24:31] <specing> there exist no such magic memory
[15:24:58] <jaldunate> but an SD card, for example, it has a endurance limit as EEPROM?
[15:25:15] <twnqx> flash is flash
[15:25:19] <specing> EEPROM has a much higher endurance limit (1000x higher)
[15:25:48] <djms> what is the default value of the SPCR register?
[15:25:55] <djms> is it 0?
[15:25:56] <specing> djms: datasheet
[15:26:49] <jaldunate> thx.
[15:35:44] <djms> specing, where exactly it mentions? I don't see any info about its default value
[15:39:37] <megal0maniac_afk> djms: Search the datasheet for "SPCR"
[15:39:57] <megal0maniac_afk> Find the section titled "SPI Control Register - SPCR"
[15:40:24] <megal0maniac_afk> Then look at the table. Under each bit is an "initial value"
[15:40:32] <megal0maniac_afk> Have a nice day :)
[15:40:59] <megal0maniac_afk> (Spoiler: It's 0x00)
[15:41:15] <djms> megal0maniac_afk, I did not notice that one on the figures, thanks a lot
[15:42:00] <megal0maniac> Who was bitching about FPGAs being closed? Specing?
[15:42:06] <megal0maniac> specing rather
[15:42:39] <megal0maniac> What this is?
http://www.freerangefactory.org/site/pmwiki.php/Main/Software
[15:43:19] <megal0maniac> And what's missing? Something must be missing. Xilinx doesn't share all their secrets
[15:44:19] <twnqx> all the important stuff
[15:45:25] <twnqx> step a) for fpgas is a compiler that creates an intermediate form of RTL - basically function for input->output mapping and the flip flops in between
[15:46:01] <twnqx> second step is to break those down so they fit the function blocks in the real fpga
[15:46:22] <twnqx> third step is to place and route - like a PCB - those function blocks and their interconnects
[15:46:50] <twnqx> rip up & reroute until performance constraints are met
[15:47:25] <twnqx> fourth step is to generate an FPGA configuration bitstream from the result
[15:47:53] <twnqx> verilog/vhdl compilers and interpreters are old. i used iverilog 10 years ago for that
[15:48:14] <twnqx> and from there on xilinx' tools...
[15:49:41] <megal0maniac> Hmmm... I guess it won't be viable to use anything other than ISE/Quartus until Xilinx/Altera change the way they do things
[15:49:59] <megal0maniac> And strictly speaking, the way they do things is why they're successful.
[15:50:14] <megal0maniac> Also, was my condescending tone too subtle? :P
[15:50:29] * megal0maniac resisted the urge to go *pat pat*
[15:50:30] <twnqx> it sounded rather clueless.
[15:50:48] <megal0maniac> It was what it was
[15:50:54] <twnqx> and in fact it's open
[15:51:00] <megal0maniac> To a point
[15:51:05] <twnqx> iirc xilinx has the bitstream format documented
[15:51:22] <twnqx> which gives you free access to the fpga
[15:51:58] <twnqx> dunno if they still do it for the latest, but it was public for the older ones
[15:52:18] <twnqx> also i think synopsis can handle them all as third party tool
[15:52:34] <twnqx> and there are better optimizing vhdl/verilog compilers
[15:53:51] <twnqx> i seem to remember we used synplify to compile verilog at university
[15:56:53] <specing> megal0maniac: Maybe CERN can do something about it
[15:57:03] <specing> doubt they will though, it is too expensive.
[16:00:20] <megal0maniac> Yeah, I doubt so too. Especially given the myriad of tools that the Xilinx ISE comes with, even with the free license. (The license agreement doesn't stop you from blocking WebTalk with your firewall - they just suggest disconnecting from the internet)
[16:00:36] <megal0maniac> They'd have a lot of catching up to do to come up with something similar
[16:00:45] <megal0maniac> Or even vaguely competitive
[16:00:57] <twnqx> altium designer supports all FPGAs, btw :P
[16:05:02] <twnqx> fpga.v: ../fpga.ucf fpga.edf
[16:05:03] <twnqx> rm -f fpga.ucf
[16:05:03] <twnqx> ln -sf ../fpga.ucf fpga.ucf
[16:05:03] <twnqx> ngdbuild fpga
[16:05:03] <twnqx> map -detail -k 8 -ol high -cm speed -timing fpga.ngd
[16:05:03] <twnqx> par -ol high -xe c -w fpga fpga
[16:05:05] <twnqx> trce -e -u 10 -l 10 -a fpga
[16:05:07] <twnqx> bitgen -w fpga
[16:05:09] <twnqx> netgen -ofmt verilog -sim -w -ngm fpga.ngm -ism -pcf fpga.pcf fpga.ncd fpga.v
[16:05:23] <twnqx> you can just use the command line tools from ISE which don't talk back :P
[16:20:53] <megal0maniac> Ah, cool. Didn't know that :)
[16:22:09] <twnqx> no idea how much documentation exists on the needed things.
[16:40:02] <N1njAway> If anyone on here uses Twitter, we've just created a humerous account for one of the pick and places.
https://twitter.com/Quadtholemew
[16:45:03] <megal0maniac> N1njAway: Cute :P
[16:46:57] <juri_> anyone here have a gplv2+ bootloader for the 8535?
[16:53:36] <juri_> i hacked something together out of the ARC bootloader, but its not handing over to the firmware image i flash onto the unit correctly..
[16:54:31] <megal0maniac> Group project. 1st guy does his documentation in good time. 2nd guy is supposed to write code based on the documentation. 2nd guy mails me this afternoon, he's stuck. I send him the program I threw together in my spare time as a reference, because it mostly works. I go out for 3 hours, come back and he's added a description to my program and couldn't fix the problem. I fix the problem. Now I'm re-doing all the documentation as well because i
[16:54:46] <megal0maniac> Oh, and deadline is in 20 minutes
[16:55:01] <juri_> my suspicion is that i'm not flashing right, and overwriting my bootloader every time i'm trying to flash my program code onto it.
[16:55:03] <N1njAway> Group projects are bad.
[16:55:34] <N1njAway> Good luck, btw! :)
[16:56:42] <megal0maniac> N1njAway: On the plus side, it seems like it's no longer a group project at all :P
[16:57:40] <N1njAway> True!
[18:58:53] <braincracker> h
[19:10:20] <juri_> hio. :)
[19:11:34] <braincracker> sup?
[19:12:04] <braincracker> everybody kept busy at concentration camps?
[19:13:48] <Fornaxian> we can't have concentration camps these days.
[19:14:00] <Fornaxian> everybody is ADD or ADHD and can't concentrate
[19:14:04] <braincracker> oh okey
[19:14:16] <braincracker> google "fema camps" then
[19:14:29] <Fornaxian> and the government won't pay for our ritalin anymore.
[19:15:05] <Fornaxian> tummy very full.
[19:15:19] <Fornaxian> just cooked up a pair of 1.5 pound porterhouse steaks.
[19:15:31] <Fornaxian> that was good food.
[19:16:17] <braincracker> sounds ok, was it pig?
[19:17:12] <Fornaxian> no...cow.
[19:17:15] <Fornaxian> beef
[19:17:17] <Fornaxian> steak.
[19:17:21] <Fornaxian> MEAT
[19:17:23] <Fornaxian> FOOOOD!
[19:20:18] <Fornaxian> http://dangerousprototypes.com/2013/10/16/hackadays-arduino-clone-opens-beer/ finally, a useful ardweeny!
[19:20:24] <Sevalecan> I want a hamburger now
[19:20:58] <Fornaxian> sorry.
[19:21:25] <braincracker> ;/ hamburger
[19:21:47] <braincracker> Fornaxian
https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXino-MICRO-4GB/
[19:22:07] <braincracker> new netbook/programming pc
[19:22:08] <braincracker> :)
[19:22:40] <Fornaxian> hehe.
[19:22:46] <Fornaxian> but it can't open a bottle of beer!
[19:23:01] <braincracker> well, it has more than 64 ios too
[19:23:30] <braincracker> hook up a 10 axis robot arm to it maybe
[19:27:57] <Valen> I found the problem with my usb
[19:28:00] <Valen> friggin cables
[19:28:06] <Valen> 2 bad ones in a row
[19:28:13] <Valen> passed continuity
[19:28:15] <Fornaxian> https://www.olimex.com/Products/OLinuXino/A13/A13-OLinuXino-WIFI/open-source-hardware I like this one in that it has wifi....but,,,
[19:28:17] <Valen> but not usb
[19:28:20] <Fornaxian> oops.
[19:28:27] <Fornaxian> cheap cables are worth half what you pay for them.
[19:29:04] <Fornaxian> I have a pile of usb cables from a project some years back where I installed a bunch of UPSs...
[19:29:30] <Fornaxian> each one had a cable but they didn't want them connected to the computers for active control.
[19:29:33] <Fornaxian> so I kept the cables.
[19:29:42] <Fornaxian> they have usb A on one end and an rj45 on the other.
[19:29:57] <Fornaxian> I just cut the rj45 off and solder the wires to my board directly.
[19:30:18] <Fornaxian> haven't had a bad one yet out of a dozen or so I've used.
[19:30:24] <Fornaxian> probably have 30 or 40 left.
[19:30:33] <Valen> I may need to make a usb A-A cable soon ;->
[19:30:46] <Valen> I put the wrong port on the board lol
[19:32:12] <Fornaxian> hehe.
[19:32:15] <Fornaxian> have one of those too.
[19:32:26] <Fornaxian> I have an old pic programmer that needed it.
[19:32:40] <Valen> 50/50 on that, I may just cut up another cable and run it out of the box
[19:32:56] <Valen> I'm using usb sockets for connecing a bunch of doohickies, that aren't usb ;->
[19:33:27] <N1njAway> Valen: Did you get your USB connection working?
[19:33:31] <Valen> yes
[19:33:40] <Valen> !@#$@$!%@#^(@%*$%@()#*$%^(@#&^%!#$*&%(&"(!%$#)()@$!_%*)&^(!)+_@)#^*&@*$(ing usb cables were crap
[19:34:57] <Fornaxian> that the way the serial data came across them?
[19:35:10] <N1njAway> LOL well, easy solutions.... And it forced you to check a bunch of other things in the process :)
[19:35:16] <Valen> thats me swearing gratuitously
[19:35:26] <Valen> I would have been happy not checking them ;-P
[22:17:28] <Tom_itx> Valen
[22:17:34] <Tom_itx> did you get your issue fixed?
[22:17:59] <Valen> yeah it was #@$#@$@# usb cables
[22:18:04] <Valen> 2 duds out of 2
[22:18:25] <Valen> passed continuity, worked with a camera but not with my board
[22:18:28] <Tom_itx> i guess i could have read the logs :)
[22:18:36] <Tom_itx> that sucks
[22:18:40] <Valen> eh asking is easier ;->
[22:18:46] <Valen> 2 friggin days
[22:19:01] <Valen> anyway i'm off to finish this and have breakfast now its 2 pm
[22:22:21] <N1njAway> I would have suggested checking your cables, but that seemed like it would have been insultingly obvious.
[22:22:37] <N1njAway> "Hello IT! Have you tried turning it off and back on again?"
[22:34:47] <Roklobsta> valen what are you making?
[22:37:50] <N1njAway> Rok: A USB cable tester from what it seems :)
[22:38:13] <N1njAway> But one that can be used For Great Justice beyond just testing cables! :D
