#avr | Logs for 2016-10-13

Back
[00:27:01] <dgriffi> xMopxShell: if you want something in a to-92 package, you only have linears
[00:27:37] <dgriffi> xMopxShell: you can get dc-dc converters in the same footprint at to-220 though.
[05:43:52] <dgriffi> What does it mean when writing with avrdude looks like this? http://pastebin.com/sqPAUFid
[05:47:32] <Lambda_Aurigae> it means something is messed up.
[05:47:43] <Lambda_Aurigae> wires too long maybe
[05:47:51] <Lambda_Aurigae> noisy connection somewhere.
[05:49:20] <Lambda_Aurigae> hmm..I need 108 1/2 inch square e-ink displays.
[05:49:32] <dgriffi> Lambda_Aurigae: I didn't change anything in the hardware
[05:49:47] <Lambda_Aurigae> you asked what it means.
[05:49:51] <dgriffi> hrmm.
[05:49:55] <Lambda_Aurigae> looking at that error that's my first thought.
[05:50:41] <Lambda_Aurigae> a bad avr would just fail outright.
[05:50:49] <Lambda_Aurigae> that fail and retry is a comms issue.
[05:51:40] <Lambda_Aurigae> comms issue with something that I am assuming worked without error before would be 98% chance of hardware, primarily cabling.
[05:51:45] <Lambda_Aurigae> something's loose
[05:52:15] <dgriffi> this prototype board is a bit dodgy
[06:09:39] <Lambda_Aurigae> so is this network this morning.
[06:10:48] <dgriffi> Whee!!! Networking like a yo-yo!!!
[06:10:48] <LeoNerd> I believe they're rehubbing things
[06:10:48] <dgriffi> yeah... I'm getting messages from ops alluding to such things
[06:10:51] <specing> some say Eris is still trying to get into the network
[06:18:32] <Lambda_Aurigae> no clue what an Eris is.
[06:19:15] <specing> Lambda_Aurigae: ever heard of EFNET?
[06:23:01] <dgriffi> specing: why did they call it "Eris Free"... that place seems dominated by Eris and her followers.
[06:40:59] <Haohmaru> who's Eris?
[06:41:27] <specing> A server
[06:53:38] <Lambda_Aurigae> efnet, yeah..used to hang out there....
[06:56:05] <Tom_L> rikus
[07:09:50] <dgriffi> Haohmaru: Eris is the Greek goddess of discord
[07:12:22] <Haohmaru> oh
[07:25:20] <Tom_L> rikus isn't greek but he brings discord
[07:40:07] <Haohmaru> i know a greek guy
[07:40:27] <Haohmaru> but so what ;P~
[07:51:25] <_ami_> oh boy.. kicad does not work behind webproxy :/
[07:52:10] <_ami_> on linux, it was simple to do IMO, https/http_proxy env variable.
[09:28:58] <RikusWork> Tom_L: not talking about me ?.
[09:37:10] <RikusWork> zlog
[13:55:41] <sebus> Can anybody tell me which library is good for fat16 and tiny mcu's like atmega8? I'm going to read stuff up to few kHz depends if it's going to be pcm or raw data for chips like this http://i.imgur.com/J2xaHFR.jpg
[13:56:20] <bss36504> sebus: http://elm-chan.org/fsw/ff/00index_e.html
[13:56:22] <sebus> already done that with sram... but heck, uploading stuff @ 460800 is slooow
[14:05:53] <Tom_L> elm chan
[14:06:00] <Tom_L> might work on that
[14:06:33] <sebus> bss36504 about half of flash and more than half of ram used just for r/o... Hmmm... I am afraid I'll run out of resources :S But i'll try it. Thanks.
[14:15:17] <bss36504> unfortunately that's the way it goes. If you wanted to roll your own, very limited FAT16 lib I imagine it could be much smaller. elm-chan's library is very well written and supports a lot of options and features (mostly turned on and off by #if) but that flexibility comes at a cost
[14:20:02] <carabia> sebus: a fat16 lib for just reading is very simple to implement
[14:21:10] <carabia> also - if you can have the sd card alone in the spi bus, that makes it even more simpler. Or alternatively use some glue logic to isolate it from the bus when talking to other chips...
[14:21:59] <carabia> wait. no sd card mentioned. I should learn to read
[14:23:46] <carabia> unclear to me from where the data would be read, but i'm just a bit dumb. Anyway just reading off fat16 is simple in itself. Just makes it even simpler if you don't have to stick with sector boundaries and you can just stream byte per byte
[14:32:37] <sebus> carabia only sd card. Interfacing ide / cf card uses way too much i/o pins even with 595 and some 245 bi-dir buffers/273/573/574 latches
[15:12:28] <carabia> sebus: yeah figures
[15:13:50] <carabia> as said if you can have the sd card alone in the bus or use a tristate buffer to isolate it from the bus if you need to talk to other chips on the same bus during transfer, it's super easy
[15:16:39] <carabia> all you gotta do is read the partition table which lets you get to the boot sector and the bpb within contains all the info you need to read the disk
[15:17:53] <carabia> and when reading a file you can just initiate a multi-block read and clock out data byte by byte until you have read a sector, then you gotta terminate it to read the fat again to get the next cluster, etc.
[15:18:02] <carabia> s/sector/cluster
[15:19:31] <carabia> whereas fatfs caches a sector into memory to handle data reads that are not sector-aligned (well, 512 bytes really... haven't seen any other implementations)
[15:20:37] <carabia> also, clock in data rather*
[15:22:54] <carabia> or alternatively just always read a sector at a time and ignore unnecessary bytes, and bytes beyond EOF
[15:59:53] <sebus> carabia I always try not to share communication pins with other stuff, except programmer port.
[16:00:32] <carabia> well then you can implement it very easily and it suits well for streaming
[16:08:08] <sebus> carabia If it'll let me read bytes to playback tunes with 1kHz interrupt, then it's okay. (1kHz interrput from vgm rips and other raw dumps)
[16:08:34] <sebus> But now, time to go, I'll try it tomorrow. And good night :-)
[16:15:32] <carabia> sebus: easily. also if you keep the data defragged on the sd-card the read routine will simplify even more.
[16:16:36] <carabia> basically you would init mblock read, clock data in and keep track of bytes transferred and compare that against the size of the file which you get from the directory entry
[16:19:21] <carabia> the only thing you need to fiddle with is before every sector the card will seek for a bit, basically you just clock the line until you get the data start token which is specified in the SD spec
[16:19:56] <carabia> and after every sector (512 bytes) the card will give you a crc which you can discard, then it seeks again, etc.
[16:21:22] <carabia> seek, well rather loads its output buffer I guess.
[21:32:58] <Evidlo> I wish the tinies had a built in uart
[21:33:40] <rue_house> I have transmitt code
[21:33:47] <rue_house> tiny26 and tiny13
[21:35:40] <specing> Evidlo: t2313 has uart
[21:55:04] <anonnumberanon> rue_house, You have to bit bang it?
[21:57:26] <Evidlo> are there any abstraction libraries for AVRs so I don't have to look up registers when doing simple stuff like toggling or reading IO?
[21:57:37] <Evidlo> like Wiring, but without the bloat
[21:58:01] <specing> I'm sure ATMEL has something
[22:09:23] <rue_house> yup
[22:11:04] <specing> you could also do Ada and have the compiler type-check everything for you
[22:12:10] <rue_house> anonnumberanon, last time I did the tiny13, I had fun with the delay, I needed the only timer for something else
[22:17:27] <Tachaway> strong typing is for people with weak memories -.o
[22:18:17] <specing> It is also for people wanting to ship a reliable product
[22:21:12] <Tachaway> and if you need a strongly typed language to hold your hand perhaps you're not quite ready to be writing production code for embedded systems, heh.
[22:23:03] <specing> or perhaps you are writing programs for pacemakers, peacemakers or anywhere in between and "things going wrong" is not acceptable
[22:29:39] <rue_house> get some people to design a pacemaker, but give them just 1 month and pay them minimum wage
[22:35:05] <anonnumberanon> specing, at the end of the day it may not matter the Ariane 5 explosion was running Ada, wasn't the fault of the coding but the software was still used in the wrong way. It still did not save the rocket with its strong typing.
[22:38:33] <specing> actually it did
[22:38:52] <specing> the runtime threw an exception... the exception was handled inappropriately
[22:39:25] <specing> but the rocket still self-destructed according to procedure
[22:42:17] <specing> Would the rocket detect a failure if it was running C?
[22:42:30] <specing> the counter would still overflow...but there would be no exception thrown
[22:42:55] <specing> so it is possible that the rocket would be turned downwards into something else that is valuable
[22:43:46] <specing> the Ada runtime system likely prevented further damage.
[22:49:43] <anonnumberanon> no there is a destruct button they have they push it after a certain downwards angle or trajectory deviation
[22:50:22] <anonnumberanon> 'sides, nobody is ordering Ada anymore, just people who want to maintain old stuff or port to faster architectures, it's like a very minimal part of the market
[22:50:37] <anonnumberanon> they seem to fair with C and C++ pretty well
[22:51:18] <anonnumberanon> In any case everything is tied down to the support on RTOS packages and architectures. Language used is spoken about only after.