Back
[02:27:36] <l9> crap i need new regulator for my arduino board ams1117 5.0 should i replace it or get the same one?
[03:16:27] <Snert> it's hard to buy less than 10 of those lol
[03:19:25] <Snert> I'd just get the same one.
[04:08:54] <Haohmaru> is it normal to have ~4.3kOhms resistance between i2c SCL and SDA?
[05:57:40] <twnqx> Haohmaru: is you have ~2.15k pullup resistors from each, yes.
[05:57:54] <twnqx> if*
[06:00:50] <Haohmaru> right.. i'm dumb
[08:48:12] <bss36504> Howdy folks
[08:51:55] <bss36504> I managed to let the magic smoke out of an AVR this weekend. It's on a new board design. I powered it up, and tried to get the programmer to recognize it, but no luck. So I started probing around, and the reset pin had 1.8ish volts on it (VDD=3.3V) which I thought was odd, since there was a 10K pullup to VDD. So I left it powered for a bit longer a
[08:51:55] <bss36504> s I probed around, and then suddenly it started smoking and that was all there was to it. I haven't desoldered it yet, but it looks like the micro is now internally shorted from VDD to GND. Any thoughts? It wasnt just the reset pin that was at an odd level, a lot of the IOs were at strange levels.
[08:53:04] <Casper> congrat!
[08:53:14] <Casper> you succeded to do something hard to do
[08:53:28] <bss36504> haha and what is that?
[08:54:14] <Casper> the avr is quite tolerant
[08:54:28] <Casper> check the polarity
[08:54:41] <bss36504> Yeah, I've never had this happen, and this aint my first rodeo either.
[08:54:55] <bss36504> The polarity of VDD? It's good, the VDD rail was a solid 3.3V
[08:55:10] <bss36504> +3.3V w/ respect to the GND pin :)
[08:57:57] <Casper> first time powered on?
[08:58:47] <bss36504> Not exactly, but first extended runtime. I did power from a bench supply at first and didnt see any high currents being drawn. Whole board was only sucking about 80mA
[08:59:18] <bss36504> This is an xmegaE if that helps
[08:59:50] <l9> Snert: yeah i noticed :P bought a few of ebay
[09:00:00] <bss36504> To me it seemed like it was being powered through an IO or something, but I double and triple checked that the power pins were connected properly.
[09:14:41] <twnqx> 80mA through a esd protection diode wouldn't even be enough to destroy it...
[09:15:34] <twnqx> so.. mr. altium user around today? :>
[09:16:28] <bss36504> twnqx yeah that was what I figured. Now, I am not sure if the fault was just slow to develop, since when the smoke came out, It was under USB power.
[09:16:59] <twnqx> usb is 5V though. feeding a regulator?
[09:17:03] <bss36504> Yes
[09:17:27] <bss36504> Wish I had the schematics handy, but they are at home and I am not...
[11:41:46] <lem> Hello. You know that level of frustration you can reach where you catch yourself literally starting to pull your own hair out? That's where I am. All I want is to get FatFs working on this ATmega328p. Everything works with the Arduino SD card examples, but when I try to adapt FatFs so I don't have to use Arduino things... nothing works. I can't find any tutorials. I can't find any help that isn't 4+ years old. I'm at my wits end. Is anyone
[11:42:15] <LeoNerd> What are you attempting to do on FAT?
[11:42:34] <LeoNerd> I have a non-Arduino implementation of FAT16, suitable for reading, creating or appending files
[11:42:49] <LeoNerd> It can't perform other write operations though - no random-offset seeks, no mkdir/rmdir/etc...
[11:43:12] <LeoNerd> It also doesn't currently support FAT32, or SDHC/SDXC cards
[11:44:31] <LeoNerd> It also doesn't suffer that stupid Arduino limit of only allowing one open file at once :)
[11:44:41] <lem> I just typed out a long explanation but realized I can make it much shorter: Basically, data logging. Writing ~10-15 bytes per line every 5 minutes. The issue is that it has to do this for 3+ months in a remote village in Africa with no one able to troubleshoot anything. Then they'll pull out the SD card, put in another one, and email us the file(s) on the old SD card.
[11:45:17] <LeoNerd> Yah.. that's what mine does
[11:45:24] <LeoNerd> Data logging.. useful for append-only files
[11:45:43] <lem> The problem is that this has to be capable of taking just about any SD card they stick in there. The system needs to be getting us data for the next few years, and if they lose the SD cards we give them, they'll need to be able to plug in just about anything they can get their hands on, which may be SDHC/SDXC cards that are pre-formatted with FAT32.
[11:46:03] <LeoNerd> Right. Yah that could be the kicker currently
[11:46:17] <LeoNerd> I mean it shouldn't be *hard* to add support for those, but by that time you might have found some other solution
[11:46:26] <LeoNerd> Plus if you don't need multiple files open, you might find one of the others nicer
[11:46:45] <LeoNerd> I wrote this largely because I wanted to keep two files up at once - my main data log and a separate battery log
[11:47:35] <lem> That's why I was leaning toward FatFs, it seems to handle a lot of this stuff just fine, or should, if it worked. I've tried the easy demos with no luck, and those just bit bang the card. I need a more complex version to work but I have no idea how to really start implementing it.
[11:47:46] <lem> maybe this is a relatively trivial problem and I just don't know where to start. *sigh*.
[11:48:21] <LeoNerd> The trouble with a lot of arduino-based things is they tend to be arduino right the way down
[11:48:21] <lem> Thank you though!
[11:48:37] <LeoNerd> It becomes a sortof infectious thing that takes over and makes it hard to extract the logic back out again
[11:49:24] <lem> Ya, that's why I'm trying to get away from the Arduino implementation right away in the code. I have two things written actually, the non-Arduino code (but with no SD stuff, just dummy functions), and the sample Arduino SD card stuff that I used to verify that the SD card reader is working. I want to get a basic FatFs version of the latter working, and integrate it into the former.
[11:50:02] <lem> LeoNerd, exactly. That's why I want to steer clear of the Arduino things for this program, especially as we're likely to open source it at some point.
[11:50:09] * LeoNerd nod
[11:50:28] <LeoNerd> There's quite the number of -other- AVR-based FAT implementations around. I found several while I was looking
[11:50:41] <LeoNerd> If you don't need multiple files at once, probably any of those would be fine
[11:51:43] <lem> Just one file.
[11:52:58] <lem> it needs to be able to format an SD Card though. As in, the SD card they stick in may have already been formatted in some way... for example, they may just buy a random SD card from someone with a camera who is visiting a local village. This system needs to work with that, and we can't know ahead of time anything about how that SD card is formatted, or its size, or anything.
[11:58:55] <LeoNerd> Ohright.. SD card formatting is a whole new level of fun :)
[11:59:03] <LeoNerd> You definitely want to look at one of the others then
[11:59:12] <carabia> lem, the fat white paper describes identifying a given fat-fs quite nicely
[11:59:36] <carabia> and it also describes formatting processes thoroughly too
[11:59:51] <carabia> so you could either just id the fs and roll with it, or format it completely. up to you
[12:00:02] <carabia> https://staff.washington.edu/dittrich/misc/fatgen103.pdf
[12:00:18] <lem> carabia: The code will likely id the fs and format if not FAT32.
[12:00:57] <carabia> really 16 and 32 are very nice. 12 is the only painful one.
[12:01:14] <carabia> because of the alignment issues
[12:02:05] <LeoNerd> 12 is terrible. But fortunately you're unlikely to encounter it on SD cards
[12:02:13] <lem> I'm also stuck with the issue that this needs to be working by, well... tomorrow. I can come up with an excuse and likely have until Monday... but this needs to be done ASAP, which means I really need something where I can tell it the proper pins, and then use simple functions (like FatFs) to do what I need. Unfortunately it also needs decent error reporting so that I can have the program do proper error handling (e.g. checking the fs type)
[12:03:11] <lem> this is for a non-profit company, which.. blah blah blah, this has come down to me, for an independent study course. and the timeline for everything got moved way up. so now i'm in a rush to get something working that I've never dealt with before :(.
[12:03:59] <lem> so if i don't get this.... i don't pass the class. and i'm supposed to do my thesis with this prof. and she doesn't understand how long this stuff takes. so i'm kind of fretting.
[12:04:22] <LeoNerd> Well you said it worked with Arduino, so could you just stick with that?
[12:05:30] <lem> I don't really know. The non-profit is going to open source the code, so I don't know if I can be stuck with Arduino functions. The prof specifically said to have it non-arduino specific, but i'm sure she'd rather have it have arduino code and WORK, rather than not work at all.
[12:06:06] <LeoNerd> I think that's a discussion you should have ASAP
[12:08:37] <lem> Me too. I'm fairly unhappy with how all of this has suddenly turned out. Lots of stuff got shifted around and they just sort of assumed I could magically pull code out of my ass in a day :(. Unfortunately the decision makers aren't available until tomorrow.. when they want this code.
[12:11:23] <lem> I wouldn't mind using the arduino sd card stuff, I just cant compile it in Atmel Studio, and other parts of the project (that I'm not doing) are all relying on that.
[12:12:47] <LeoNerd> Ah that's awkward
[12:13:05] <LeoNerd> I wonder what it would take to recover it. Probably not an -awful- lot - I suspect it's just using the SPI interface, right?
[12:13:14] <LeoNerd> Perhaps you could provide your own SPI object to stand in place of that?
[12:13:54] <lem> I've started digging into that, and each *.h calls another, and another, and another.... everything is arduino, all the way down.
[12:14:08] <_ami_> while flashing bootloader, do i need to set lfuse/hfuse everytime?
[12:15:03] <LeoNerd> _ami_: fuses are nonvolatile; they remain until you explicitly change them again later
[12:18:25] <_ami_> aha, it should be like that. i think i did some mistkae in my code.
[12:19:15] <_ami_> oh boy, i forgot to set IVCE & IVSEL :/
[12:20:06] <bss36504> lem, I got FatFs working ok on AVR, what seems to be the issue? (Disclaimer: I'm no expert on the library or FAT). Is it just not reading and writing properly or what?
[12:20:34] <bss36504> I do recall spending a ton of time trying to get the thing to work only to find out I wasnt initializing the SD card properly.
[12:21:14] <lem> bss36504: Honestly, it is just that I'm not even sure where to start. The "foolproof" tutorial doesn't really use FatFs the way it is supposed to, and any examples I can find of how to begin implementing FatFs into a project are using old versions, so the code they point out just doesn't match. I guess I'm just not sure of where to start.
[12:21:37] <bss36504> Do you have a debugger?
[12:21:57] <bss36504> Or at the very least a serial connection?
[12:22:10] <lem> Not really. I'm running on a cheap CH340G, so I do a lot of printf's for debugging :)
[12:23:03] <bss36504> Well as a sidenote, just buy an atmel ice already. They're great. But anyway, I would suggest making sure you are initializing the SD correctly by printing back it's responses. Then go from there.
[12:24:43] <_ami_> LeoNerd: those male usb A type header are not robust. :/ its fell out after 1-2 days of work. :P
[12:24:51] <carabia> lem, I think you need to properly manage your time, then
[12:25:22] <carabia> there's no way you'll implement it reliably by tomorrow. Just the way it is
[12:25:42] <lem> bss36504: I'm not even sure of the order of events that I need to do to with FatFs. Initiliazing, opening, closing... I can't find anything to help me with this. I'm sure there is stuff out there, I just can't find it.
[12:26:04] <carabia> Did fatfs even have a low level driver for the actual card?
[12:26:10] <carabia> I don't know, cause I wrote my own
[12:26:24] <bss36504> I think it provides function stubs that you fill in.
[12:26:29] <carabia> so, no
[12:26:31] <bss36504> I might be mistaken.
[12:26:32] <lem> carabia: Agreed. I'm going to stick with the arduino stuff for now, I think, and get it working with that. I can always explain why it is the way that it is, and if necessary, dive back in at a later date and switch functions over to FatFs or whatever.
[12:27:07] <lem> bss36504: It does, but I don't know what order ot use them in or anything. That's why I'm frustrated that I cant find a simple example of working code anywhere.
[12:27:28] <bss36504> Did you look at this page?
http://elm-chan.org/fsw/ff/en/appnote.html
[12:27:42] <carabia> lem, shouldn't probably be anything else but to call the init and you're good to go
[12:28:27] <bss36504> It pretty clearly shows that the low level drivers are called via the high level fat API. So once you write you low level drivers correctly, you shouldnt need to directly access the card drivers anymore. my issue was that my drivers were not correct, thus it took a little bit of debugging
[12:28:38] <carabia> That page pretty much suggests there are no drivers for the card
[12:28:59] <carabia> yeah, you beat me to it
[12:29:45] <bss36504> Right, that said, however, the guy who wrote it seemed to like AVRs, and I think he has an AVR example somewhere on the site with full MMC drivers.
[12:29:58] <bss36504> It's just not strictly part of the core FatFS lib
[12:30:29] <lem> bss36504: he has two examples for AVR, one is the "foolproof" one which just bit bangs the sd card, and one is more complex. much more complex. complex to the point that i don't have time to figure it out.
[12:30:53] <bss36504> Did the foolproof one work?
[12:31:24] <lem> I did see that page, and I understand the inter-dependencies and all that, or at least i think I do. I'm just running on too little sleep and under too much of a time crunch to figure out what things to call in what order.
[12:31:42] <lem> bss36504: No. The arduino SD card examples work, but the foolproof did not.
[12:32:07] <lem> I think I'm just too crunched for time to think clearly about what I'm doing. I may just be wasting my own time, and possibly yours.
[12:32:12] <bss36504> We've all been there. Try to get the foolproof one to work. You said you're writing 10-15 bytes every few minutes (i think) so who cares if it's bit banged.
[12:32:41] <bss36504> Now, if anyone can help me brainstorm why I smoked an xmega, that would be great :P
[12:33:08] <LeoNerd> _ami_: mm?
[12:33:09] <carabia> lem, what's the actual hardware like?
[12:33:22] <lem> I couldn't get the foolproof to work because it could never initialize the card. oh well.
[12:34:09] <bss36504> Man, that sounds very similar to my issue...I'm trying to remember what the problem was. I do remember it involved three days of headdesking though haha
[12:34:17] <lem> CH340G (arduino nano clone) hooked up to an SD card (with some 5V<->3.3V level shifters appropriately between them). That's it. Arduino SD card stuff works, "foolproof" example for FatFs does not.
[12:34:36] <carabia> What's the "level shifter"?
[12:34:44] <carabia> a buffer of sorts for sure, but what?
[12:36:09] <carabia> I'm looking at the "mmc_avr_usart.c" written by fatfs-guy, and it wants to clock the bus at 20mhz, i couldn't get a cd4050b working reliably at 20mhz
[12:36:30] <carabia> though, for init the bus is clocked at 400khz so it should still be able to pull the card out of idle
[12:36:38] <lem> level shifter is one of these. I can't find an exact model without tearing up this circuit.
https://www.google.com/search?q=qifei+level+shifter&safe=off&source=lnms&tbm=isch&sa=X&ved=0ahUKEwjMq7-Z6NzNAhWLbT4KHZ-2CjAQ_AUICCgB&biw=1920&bih=989
[12:37:11] <bss36504> Oooh, it may have been related to the init clock speed. I might have dialed that down a bit to around 100khz and then it worked
[12:37:40] <carabia> for init you need to run the bus at 400 khz or slower, yea
[12:37:49] <lem> someone else on the project just let me know they can't get their stuff working (they had to write a MODBUS protocol library from scratch) without the Arduino SPI.h file (they could but just not today) so it looks like we may be already using Arduino.h. I'm just gonna go wtih that for now.
[12:37:50] <carabia> same with 4-bit i/f
[12:38:14] <bss36504> carabia I think there is actually a minimum spec of 100Khz too. So it HAS to be between 100 and 400
[12:38:27] <carabia> probably yea
[12:38:38] <lem> when I inevitably return to get rid of arduino code remnants, i'll remember to try tuning it down. Thank you both!!
[12:38:54] <carabia> anyway, another issue that you might be facing is that if elm's code doesn't account for HC-cards
[12:39:00] <bss36504> No problem boss. Hope it works for you.
[12:39:04] <bss36504> Oh yeah that too
[12:39:16] <bss36504> the foolproof example was pretty bare bones. might only work for MMC even
[12:39:39] <carabia> hc cards need to be sent a cmd8 before acmd41 (switching to ready-state)
[12:40:01] <carabia> otherwise the card always replies idle-state to acmd41
[12:40:19] <lem> that may explain why the foolproof isn't working but the arduino stuff is. i'll get this working with arduino code for now, and if I have ot change it later, i'll dive back in. when i do, i'll start by learning properly how to work with a FAT file system, and then dive into the FatFs stuff. I want to learn it all anyway for my own projects :)
[12:40:55] <carabia> and also, you need a long loop with acmd41's, from my own experience it might take hundreds of polls before the card is actually ready
[12:41:19] <LeoNerd> Mmmm ACMD41
[12:41:39] <carabia> mmm?
[12:41:42] <LeoNerd> If it's any use to you, you could have a look at my code /anyway/
[12:41:47] <LeoNerd> I account for some of these bits at least
[12:42:04] <lem> I wont' have time to go over it until much later but i'll happily hold onto a link/copy somewhere.
[12:42:05] <LeoNerd> There's some particular cornercases of SD cards that don't easily fall out of the specs
[12:43:37] <lem> one other question: These data loggers are going into an solar powered emergency power backup system I've helped design/build for a hospital in africa whose power goes out like half of the week. one of these data loggers is going to be hooked to an RTC and just plugged into the wall via an AC adapter. When the power goes out, it needs to have enough residual power to write to the SD card a timestamp of when the power went out... and it ne
[12:43:53] <lem> so we were gonna throw a supercap across the MCU's power rails. thoughts?
[12:44:04] <bss36504> lem My guess is it is not the file system. once I got my card to actually respond, the FS lib was flawless. The init was tricky though since I was originially working with a 256MB/FAT12 MMC card (which worked) but later switched to a 16GB/FAT32 SDHC(or XC maybe) card. I thought that the lib was screwing me over, turns out I just needed to modify my
[12:44:04] <bss36504> drivers to support the HC card.
[12:44:15] <lem> I guess that isn't really a question. More of a "please share your thoughts because you all clearly know a hell of a lot more than i do"
[12:44:26] <LeoNerd> http://pastie.org/10899578 <== my SDcard driver. Not included here is the actual spi.c but it should be relatively obvious how to provide the required functions ;) They just take/return uint8_t
[12:44:43] <bss36504> Supercaps are cool and all but still way lower power density than a lipo. Also, a lipo charge circuit is not hard to build
[12:44:51] <lem> Thanks LeoNerd !
[12:44:52] <bss36504> So I'd say use a lipo
[12:45:09] <LeoNerd> Line 53 in particular is highly nonobvious from the specs
[12:45:27] <lem> bss36504: I'm tempted, but we need only, I don't know.. half a second of power. this particular unit will be recording ONLY when the power goes out and comes back on. that's it.
[12:45:31] <LeoNerd> I have some cards here (I tested quite a random bunch) that needed at least 4 bytes of idle stuffing /after/ a valid R1 response, or they'd ignore the next command on the wire
[12:46:09] <bss36504> lem: oh well if you plan to sleep in between then yeah it's probably fine.
[12:46:18] <bss36504> math it out though
[12:46:48] <bss36504> if you know your peak current draw and the duration, you can calculate if the supercap has enough energy to support it
[12:47:23] <lem> the system will be sleeping, and will wake on an interrupt. the interrupt will be when the logic level goes 1 to 0 on some pin. that level will just be from a voltage divider so that it corresponds to whether or not the main system has power. when that drops, the system will wake up, write the timestamp of the power outtage to the sd card, and then just.. die.
[12:47:55] <bss36504> Oh i see. Is this like a power monitor?
[12:48:02] <lem> actually. i wonder if it would be better to write it to, um, non-volatile memory, and then once there IS power, write the timestamp. that may be far less power hungry.
[12:48:06] <bss36504> or power outage monitor, perhaps?
[12:48:15] <bss36504> Oh definitely.
[12:48:19] <lem> bss36504: Basically, yes. A power outage monitor.
[12:48:47] <bss36504> I don't think you'd have problems doing it the way you propose though. Just math it out and pick a big cap.
[12:49:19] <lem> The initial data logging system I was describing is/was for the solar powered emergency power backup system for a hospital in africa. Their power randomly goes out multiple times a day. They don't have a working backup generator because they are too remote and people steal the diesel. Our systems provide enough power to power some critical hospital stuff for a few hours, enough to stabilize someone. (cont)
[12:49:58] <lem> the data logger is going to grab data from the charge controller (such as PV panel voltage/current) via MODBUS, and will use some circuitry to see which devices that are plugged in are drawing power, and record how much. (cont)
[12:50:47] <lem> we're also adapting a version to be a power outage monitor. Every few months, hospital staff will pull out the old SD cards, put in the replacements (we'll give each unit two), and then drive 200km to a computer, and email us the .txt files with the data.
[12:51:26] <lem> we'll look at the emergency power backup system usage statistics and correlate it with when the power was out with the power outage monitor, and it will tell us how quickly they can deploy one of our units, what gets used the most, etc.
[12:51:32] <lem> we can use that data to make these units better in the future :).
[12:51:38] <bss36504> Neato!
[12:51:47] <bss36504> Well, per your supercap idea:
http://electronics.stackexchange.com/questions/4951/how-do-i-calculate-how-fast-a-capacitor-will-discharge
[12:51:51] <lem> http://www.gvsu.edu/solarescue/
[12:52:06] <lem> ooh, good link for the math, thank you!!
[12:54:01] <lem> and in case you care for more info:
https://vimeo.com/13140652. This is the trailer for a video that was made a few years ago. It is the hospital we are designing these units for, and I'm working with the main doctor shown in the trailer/video.
[12:54:24] <CyL> lem: I read a couple of message in the back log, I suggest you to usa a comparator instead of a voltage divider..
[12:54:56] <lem> CyL: I'll make a note to look into that when we get to that part of the circuit. Thank you!
[12:56:47] <CyL> lem: your issue is quite long for me to read everything.. you'd be using an arduino, I suppose?
[12:57:28] <CyL> lem: wrong channel, sorry
[12:57:34] <CyL> I thought I was at arduino
[13:06:06] <bss36504> No youre at #arduino's older, cooler brother ;)
[13:06:35] <CyL> bss36504: yeah :D
[14:50:48] <_ami_> seems like my bootloader does not able to do clean jump to application section :/
[14:54:28] <_ami_> LeoNerd:
https://github.com/amitesh-singh/amiduino/blob/master/avr/atmega16a/vusb/bootloader-ami/main.c#L60
[14:56:01] <_ami_> the code looks okay. but why bootloader does not able to jump to application section. app code just do on/off at PB0
[14:56:16] <_ami_> i get one time LED ON on PB0 and then nothing.
[14:56:38] <_ami_> i do jump from bootloader to app section via usb command line client.
[14:56:51] <_ami_> wonder what went wrong
[14:57:17] <_ami_> i flashed app code/firmware via usbasp with -D option enabled.
[15:13:19] <_ami_> Jartza: ^
[16:31:59] <LeoNerd> Currently working on a personal-use onoff, so I'm working on stripboard. Pondering a layout with an ATtiny85 (DIP size) and the 6-pin ISP header right next to it
[16:32:18] <LeoNerd> Does anyone happen to have a "preferred favourite" optimal way to arrange that? The pins aren't quite in the right orientation to do it super-neatly
[16:51:56] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/boards/USBTiny_Mkii/new_kits/USBTinyMkII_adapter_kit_desc.jpg
[16:52:06] <Tom_itx> i use my breadboard adapter for the ISP
[16:53:10] <Tom_itx> i have a few left if you want one
[16:53:32] <Tom_itx> (i think i do)
[17:01:50] <LeoNerd> I mean more as a stripboarded layout
[17:02:13] <LeoNerd> ISP wants 2 pins on one side of the tiny (RESET/GND) and 4 pins on the other (MISO/MOSI/SCK/VCC)
[17:02:47] <LeoNerd> whereas the ISP header itself has them arranged quite differently; GND/{somethingIforget}/VCC on one side and RESET/other/two on the other
[17:02:54] <LeoNerd> So it's awkward however I do it; some signals have to cross over
[17:16:18] <carabia> if it's not the qfn, just hook so and sck straight, jump si to the other side and run rst from the other side
[17:16:32] <carabia> can't be that difficult. like 2 jumper wires necessary
[17:16:59] <carabia> and you don't have to cross anything, just run the jumpers from the top side and hook power from underneath
[20:38:50] <cehteh> http://www.megaprocessor.com/
[20:41:02] <eszett> what the??? this is incredible
[20:43:02] <eszett> i wonder who gave the money for this project, or is it a private project of newman?
[20:44:39] <cehteh> no idea
[20:44:49] <cehteh> but quite enthusiastic
[20:45:06] <eszett> i mean look at those racks
http://www.megaprocessor.com/Images/megaprocessor-tour1-2mbps.mp4
[20:49:12] <eszett> built time: 4 years. costs: 47.000 Euro. weight 500kg. 40.000 Transistors and 10.000 LEDs
[20:51:43] <cehteh> yeah
[20:53:59] <carabia> So well, that's just incredibly fucking dumb
[20:54:25] <carabia> By his argument of not being able to shrink small enough to see inside a fucking ic, you can argue you still cannot see the electrons even with this super idiotic build of his
[20:55:05] <eszett> from an economical point of view, perhaps. but the idea is unique, and the effort he put into this is astonishing.
[20:55:11] <cehteh> eh?
[20:55:47] <cehteh> exactly. he did it as hobby or whatever, and did it well
[20:55:54] <carabia> wasted life, i say
[20:56:02] <cehteh> its not yours
[20:56:08] <carabia> i hate stupidity
[20:56:33] <eszett> question: with what kind of occupation do you spend your time, carabia?
[20:56:35] <cehteh> i think its rather dubm to critize other peoples way of life
[20:57:05] <carabia> eszett, something more productive than this
[20:57:30] <cehteh> i bet you find plenty people who consider your lifestyle dumb
[20:57:34] <eszett> you create some unique work, that people will speak about even when you are dead?
[20:57:43] <carabia> arguably right now i'm contradicting myself, but the time i spend here is marginal in comparison
[20:58:00] <carabia> eszett, it's not the first time something like this has been done
[20:58:14] <cehteh> yes and?
[20:58:30] <cehteh> well i am off
[20:58:35] <carabia> wasn't for you, and cehteh most likely so, so let me have my two cents on this issue, then
[20:58:50] <eszett> hmm
[21:01:29] <carabia> The biggest stupid-point in my opinion is his reasoning for it being a "tour of the innards" of an ic. Without a schematic this thing is... borderline useless. Surely you can trace it out but, in my opinion it makes it just as good as a schematic
[21:02:34] <carabia> and... i still can't see the electrons!1
[21:04:36] <eszett> so Universities are useless from your point of view
[21:04:58] <eszett> the model can illustrate the way a MCU is working, thats its use
[21:05:34] <eszett> moreover, it doent even need to have a purpose, if its his passion to build it
[21:05:35] <carabia> much the same way the mcu can illustrate how it works
[21:05:44] <carabia> without a block diagram it's just a black box
[21:06:03] <carabia> ...the mcu can illustrate itself, moreso
[21:06:10] <eszett> hmm
[21:07:29] <carabia> someone once said something about opinions being like assholes, for everyone has one but it's not always a good idea to show them around. Now as you can see I'm not one for guidelines, but maybe this same philosophy can be applied to hobbies too.
[21:07:39] <carabia> hobbies, or projects to be exact
[21:08:47] <carabia> i gotta run anyway, have a good one
[21:08:59] <eszett> cu
[21:35:28] <rue_bed> the max sample rate of a tiny26 adc is
[21:36:23] <rue_bed> 3.8Khz
[21:36:52] <rue_bed> there are 11 channels
[21:37:05] <rue_bed> 4+10 is 14 bits
[21:37:24] <rue_bed> 14bits at 3800Hz is
[21:37:47] <rue_bed> 53.2Kbits/sec
[21:38:14] <rue_bed> na, its a servo loop,
[21:38:34] <rue_bed> the loop update rate is 300Hz
[21:38:49] <rue_bed> if I update at even 600Hz I'll be fine
[21:39:28] <rue_bed> 8400 bits/sec
[21:39:36] <rue_bed> much less interrupt overhead
[21:42:03] <rue_bed> I have to read the slave controllers adc values, read the local adc values, read the control serial, transmitt return data to controller, calc 8 servo loops
[21:43:11] <rue_bed> the slavetiny26 could just cache adc values from continious conversions and send the values in a rotation as the master clocks reads
[21:43:29] <rue_bed> I still have framing to deal with tho
[21:44:55] <rue_bed> this is where a SS line comes in handy
[22:07:30] <rue_shop3> so, put SS low, clock in 14 bits, put ss high
[22:07:52] <rue_shop3> SS going high would increment the transmitt pointer
[23:03:02] <_ami_> are jmp and goto similar? jmp x == goto x?
[23:40:36] <DKordic> _ami_: Yes, in assembly.
[23:40:50] <_ami_> okay, :)
