Back
[04:01:46] <mohsen_> In arduinos we used to do Serial.println(). how can I do this in avr?
[04:04:08] <mohsen_> Should I use a library to transmit string over USART of avr?
[04:05:35] <Casper> peter fleury's uart library is very common and well built
[04:06:47] <RikusWork> printf redirected to serial
[04:10:26] <mohsen_> Is that serial protocol on arduino also uart?
[04:12:51] <_ami_> mohsen_:
https://github.com/amitesh-singh/ubirch-avr/blob/master/lib/uart/uart.c
[04:15:27] <mohsen_> Casper: If I'm reading the right manual:
http://homepage.hispeed.ch/peterfleury/doxygen/avr-gcc-libraries/group__pfleury__uart.html , then it doesn't have a function to send string?
[04:19:53] <mohsen_> Oh didn't see this: void uart_puts ( const char *s) , should I give it a pointer to a char array?
[04:27:05] <mohsen_> hello?
[11:07:45] <mohsen_> The tutorial I'm reading is using atmega16, so the IO ports are ABCD, what about an avr with more GPIOs?
[11:09:01] <mohsen_> What will be the port letters?
[11:20:04] <GeneralStupid> mohsen_: yes
[11:20:14] <GeneralStupid> mohsen_: theres no naming voodoo
[11:23:49] <mohsen_> I see, so for each avr I need to look up the datasheet?
[11:24:12] <mohsen_> There is no convention in naming the ports?
[11:25:25] <_ami_> mohsen_: i think xmega ones have only 32 GPIOs
[11:25:36] <_ami_> does it have more than 32 ports?
[11:25:52] <_ami_> at max, 32 ports only?
[11:26:08] <_ami_> for I/O
[11:29:34] <mohsen_> xmega As have more than that
[11:29:59] <mohsen_> Up to 78
[11:31:50] <mohsen_> Their port names are GPIORx, according to datasheet.
[11:34:31] <Lambda_Aurigae> if you have more than 32 i/o pins then the next ports will be E and F
[11:34:50] <Lambda_Aurigae> look at the atmega128
[11:35:17] <Lambda_Aurigae> it goes up to F
[11:35:25] <Lambda_Aurigae> actually,,,it goes to G
[11:36:29] <Lambda_Aurigae> but port G only has 5 pins where A-F have 8 each.
[11:38:04] <mohsen_> Lambda_Aurigae: I need 34, which avr do you suggest?
[11:40:40] <Lambda_Aurigae> all depends on the project.
[11:42:45] <Lambda_Aurigae> I'm guessing you want 8bit avr? atmega series?
[11:43:35] <Lambda_Aurigae> do you need usb?
[11:46:32] <mohsen_> No, uart and 34 io pins to draw power on
[11:46:37] <Lambda_Aurigae> how much flash do you need?
[11:46:45] <Lambda_Aurigae> draw power on i/o?
[11:46:45] <mohsen_> I don
[11:46:49] <Lambda_Aurigae> not sure I understand.
[11:47:05] <mohsen_> I don't know how to measure that, I mean measuring how much flash does my application need.
[11:47:25] <Lambda_Aurigae> estimated how big your application is...small, medium, large, huge?
[11:48:18] <Lambda_Aurigae> go with an atmega1281 and you have 128K flash, 8K sram, 4K eeprom, 54 i/o pins.
[11:49:21] <mohsen_> pins to draw power I mean pins that I can set high and low
[11:49:25] <Lambda_Aurigae> that is a 16MHz chip.
[11:49:48] <mohsen_> I think its small.
[11:50:05] <Lambda_Aurigae> you could go with an atmega325pA with 32K flash, 2K sram, 1K eeprom, 54 i/o pins, and runs at 20MHz.
[11:50:19] <Lambda_Aurigae> same form factor of 64pin tqfp style package
[11:51:50] <mohsen_> Does it also have UART?
[11:52:16] <Lambda_Aurigae> yes.
[11:52:49] <Lambda_Aurigae> 325PA has 1...324PB has 2.
[11:53:16] <Lambda_Aurigae> http://www.atmel.com/selector.html#%28actives:!%2881041,8238,8394,8362,8282,8431,8300,8358,8392,8378,8445,8236,8449,8474,8248,8264,8447,8256,8254,8286,8462,8429,8458,8466,8400,8302,8278%29,data:%28area:%27%27,category:%2734864%27,pm:!%28%28i:81041,v:!%281,2,3,4,5,6,7,8,9,10,11,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70
[11:53:16] <Lambda_Aurigae> ,71,72,73,74,75,76,77,78,79%29%29,%28i:8238,v:!%280,19%29%29,%28i:8394,v:!%280,26%29%29,%28i:8362,v:!%2812,47%29%29,%28i:8282,v:!%286%29%29,%28i:8431,v:!%281,40%29%29,%28i:8300,v:!%281,9%29%29,%28i:8358,v:!%2824,44%29%29,%28i:8392,v:!%280,1%29%29,%28i:8378,v:0%29,%28i:8445,v:!%281,4,5,6,7,9%29%29,%28i:8236,v:!%280,35%29%29,%28i:8449,v:!%281,11%29%29,%28i:8474,v:!%280%29%29,%28i:8248,v:!%280,1%29%29,%28i:8264,v:!%280,5%29%29,%28i:8447,v:!%280,1%29%
[11:53:17] <Lambda_Aurigae> 29,%28i:8256,v:!%281,2,3,4%29%29,%28i:8254,v:!%283,18%29%29,%28i:8286,v:!%280,3%29%29,%28i:8462,v:!%280,10%29%29,%28i:8429,v:!%280,10%29%29,%28i:8458,v:!%280,8%29%29,%28i:8466,v:!%285%29%29,%28i:8400,v:!%280,20%29%29,%28i:8302,v:!%280%29%29,%28i:8278,v:!%280%29%29%29,view:list%29,sc:1%29
[11:53:20] <Lambda_Aurigae> oops.
[11:53:23] <Lambda_Aurigae> that doesn't paste well.
[11:53:45] <mohsen_> Thanks, I'll find the datasheet myself.
[11:53:55] <Lambda_Aurigae> gonna give you a product selector.
[11:54:41] <Lambda_Aurigae> http://www.atmel.com/products/microcontrollers/avr/default.aspx
[11:54:47] <Lambda_Aurigae> there..go to Product Search
[11:55:13] <Lambda_Aurigae> gives you a nice table that you can zero in on what you want with.
[11:56:27] <mohsen_> Thanks alot.
[11:56:31] <Lambda_Aurigae> welcome
[11:57:05] <mohsen_> And something else, is it okay to cast an unsigned char to int?
[11:57:12] <Lambda_Aurigae> yes.
[11:57:16] <Lambda_Aurigae> but not the other way around.
[11:57:52] <Lambda_Aurigae> well, in theory you can cast anything to anything but they don't always translate the way we want them to.
[11:58:00] <mohsen_> Right
[11:58:14] <Lambda_Aurigae> uChar is an 8bit unsigned int already basically.
[11:59:02] <Lambda_Aurigae> well, char is always unsigned...but,,
[12:02:20] <mohsen_> You mean if I send numbers from the other point of serial, can I perform mathematical operations on them when I get unsigned chars from this object inside the avr:
https://ptpb.pw/O9lC ?
[12:03:19] <mohsen_> function* sry
[12:08:24] <Lambda_Aurigae> if the variable is type char then you will need to cast it before doing math or your compiler might throw fits.
[12:08:32] <Casper> mohsen_: uart_puts() and uart_putc() and make so printf() work too
[12:09:18] <Lambda_Aurigae> whatever data you send is what you get at the other end...it is just bits. your variable at the receiving end determines what you can do with that data. more or less.
[12:10:15] <Lambda_Aurigae> hmm..I guess you can have signed CHAR...never used such myself...didn't know it was a possibility.
[12:15:10] <mohsen_> Why do they bound it to a char?
[12:15:23] <mohsen_> Why not int? or byte or...
[12:16:53] <mohsen_> Because the other end only send bytes?
[12:16:56] <Lambda_Aurigae> the uart can send or receive one byte at a time...there is no byte variable by default.
[12:17:24] <Lambda_Aurigae> just doing some reading, and it seems on most systems char is signed...I didn't know this...I never bothered to deal with it either way.
[12:17:33] <Lambda_Aurigae> just an aside there.
[12:17:52] <Lambda_Aurigae> I often use uint8_t to send and receive data over uart.
[12:18:35] <Lambda_Aurigae> but, 90% of my variables are uint8_t on an avr.
[12:19:14] <mohsen_> Hmmm
[12:19:27] <mohsen_> So can we say char is an equivelant of byte in c?
[12:19:43] <Lambda_Aurigae> more or less.
[12:19:49] <Lambda_Aurigae> that is kind of implementation specific though.
[12:20:09] <Lambda_Aurigae> on some systems a char is known to be 16 or 32 bits...those are few and far between.
[12:20:33] <mohsen_> Hmmmm.
[12:20:42] <Lambda_Aurigae> a char on AVR is one byte, 8bits.
[12:21:28] <Lambda_Aurigae> I've worked on systems that considered 16bits to be a byte and 32 bits to be a word.
[12:21:50] <Lambda_Aurigae> and build a system that used 4 bit bytes and 8bit words...but that was a custom 4bit processor made from 74xx chips.
[12:22:26] <mohsen_> They couldn't communicate to 8bits-bytes systems, could they?
[12:22:48] <Lambda_Aurigae> well, my 4bit computer couldn't communicate with much
[12:22:58] <Lambda_Aurigae> I did make it communicate with my vic-20 though.
[12:23:07] <Lambda_Aurigae> as to the others, yes, they communicated well.
[12:23:20] <Lambda_Aurigae> in their limited range of functionality as they were very custom systems.
[12:23:47] <Lambda_Aurigae> rs232 comms is very standard across platforms.
[12:24:01] <Lambda_Aurigae> you send and receive 8bits at a time usually....or 9bits if you want to get fancy.
[12:24:26] <Lambda_Aurigae> but the 9th bit is used for addresses.
[12:24:39] <Lambda_Aurigae> rs232 or rs485 multidrop busses are fun.
[12:25:10] <mohsen_> I see. no I thought since they identify 8bits as different types they can't communicate with each other, but you can find an equivelant in them, like in they chose char?
[12:25:19] <mohsen_> in C*
[12:25:37] <mohsen_> But in Java its byte?
[12:25:48] <Lambda_Aurigae> it's all in the implementation.
[12:26:14] <Lambda_Aurigae> if I wanted to send 32bits I would just have to send it in 4 8bit hunks and put it back together at the other end.
[12:26:38] <Lambda_Aurigae> if I wanted to communicate in text I just send each character as 8bits at a time.
[12:27:01] <mohsen_> Hmmmm.
[12:27:23] <Lambda_Aurigae> 4004 processors communicate with 8008 processors over a uart based modified rs485 bus all the time on satellites.
[12:27:30] <Lambda_Aurigae> 4004 being a 4 bit processor.
[12:28:52] <Lambda_Aurigae> your 64bit intel i5 processor communicates with that 8bit avr easily enough.
[12:29:14] <mohsen_> How did you figure that out?
[12:29:22] <Lambda_Aurigae> which?
[12:29:29] <Lambda_Aurigae> the 4004/8008 thing?
[12:29:44] <mohsen_> My I mean my processor model.
[12:29:50] <Lambda_Aurigae> was a guess.
[12:30:18] <Lambda_Aurigae> -mohsen_- VERSION qwebirc v0.93, copyright (C) 2008-2014 Chris Porter and the qwebirc project -- Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0
[12:30:24] <Lambda_Aurigae> that helps some too.
[12:30:39] <Lambda_Aurigae> i5 being about the most popular processor these days.
[12:31:47] <mohsen_> I see
[12:32:13] <mohsen_> Gotta go for dinner, have nice day/night everybody.
[12:32:24] <Lambda_Aurigae> another 10 minutes at lunch here
[12:32:28] <Lambda_Aurigae> then back to the slave pits.
[12:48:06] <skz81> cat /proc/cpuinfo
[12:48:14] <skz81> mohsen_, ^
[12:48:54] <skz81> (unsure it is what you're seeking for, sorry if I missed my shoot)
[12:50:00] <mohsen_> No its okay, I'm learning linux these days too.
[15:38:42] <Jartza> evening
[15:39:19] <liwakura> heyo
[15:39:36] <Jartza> wassup
[15:40:44] <liwakura> kinda lazy/bored
[15:40:56] <liwakura> maybe i'll try to setup sabotage linux on my raspberry pi
[15:41:27] <cehteh> mhm
[15:42:13] <liwakura> today i looked a bit into attiny's
[15:42:20] <liwakura> those with like 32 bytes of RAM
[15:42:27] <liwakura> are there some with less than that?
[15:42:55] <dsal> What are your requirements?
[15:43:07] <cehteh> there are some without any SRAM
[15:43:20] <liwakura> none. i just want to know the smalles specs for an AVR
[15:43:20] <cehteh> attiny11 iirc
[15:43:31] <lorenzo> attiny4 or 11 yeah
[15:43:34] <dsal> Neat.
[15:43:36] <lorenzo> 4/5/9/10
[15:43:39] <dsal> I've got plans for attiny4.
[15:44:25] <cehteh> usually not really worth it
[15:44:43] <dsal> Most of the things I'm working on aren't really worth it.
[15:44:55] <liwakura> im just a dude with a job that is just... i write c# code at work. at home i compile kernels and program avr's
[15:44:59] <cehteh> for very limited tasks and when you can afford assembler development and then produce 100k devices .. maybe it makes a dent
[15:45:11] <liwakura> <- bored
[15:45:16] <dsal> I just like making things really small.
[15:45:30] <cehteh> me too .. but not smaller than really necessary
[15:45:33] <liwakura> dsal: same
[15:45:42] <dsal> day job:
http://research.google.com/pubs/pub41344.html
[15:46:13] <cehteh> if attiny13 isnt enough hey then i just pay 10 cent more and buy a tiny45 instead optimizing the code a week long
[15:46:33] <dsal> I've got attiny8s around, which are fine for my task (I think I prototyped on them). But attiny4 is so tiny.
[15:46:37] <liwakura> dsal: that sounds actually interesting
[15:46:49] <dsal> Friend pointed out stm8 is about the same size. Looks less pleasant to solder, though.
[15:47:08] <cehteh> and i was busy past days .. still blocking_io on mµos isnt finished ...
[15:47:29] <liwakura> cehteh: cant you just poll in a while loop?
[15:48:00] <cehteh> huh?
[15:48:12] <cehteh> i just want to have a blocking io facility
[15:48:25] <cehteh> http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/kinetis-cortex-m-mcus/l-series/kinetis-kl02-48-mhz-small-form-factor-high-integration-ultra-low-power-microcontrollers-mcus:KL02 if you want it small
[15:48:34] <liwakura> isn't that some sort of the same?
[15:48:45] <dsal> Oh yeah, I did do that polling loop you mentioned cehteh... I'm not sure how I feel about it, though. It's consistently faster, but less consistent in delay. I think it might actually be better to be slightly delayed a consistent amount than have less delay, but have 1-2µS of variance.
[15:48:50] <cehteh> https://www.wired.com/images_blogs/design/2013/02/KL0PA-keyboard-20-LR-3.jpg
[15:48:55] <dsal> None of that really matters, though.
[15:49:14] <dsal> I've never done bga.
[15:49:17] <dsal> I assume I... can't.
[15:49:21] <twnqx> bah
[15:49:29] <cehteh> liwakura: nope, it shall use the 'muos_wait()' function to enter the scheduler recursively
[15:49:30] <twnqx> you don't know until you tried
[15:49:42] <liwakura> mh
[15:49:43] <twnqx> i've heard of so many ways, from "put PCB into frying pan" onwards
[15:50:01] <cehteh> dsal: you still have a timer running w/ interrupts?
[15:50:01] <dsal> I solder with air much of the time.
[15:50:16] <dsal> cehteh: On the ppm -> pwm thing, it's just a fast loop.
[15:50:27] <dsal> Wait... No, that's not true.
[15:50:31] <dsal> I do still have the sync timer.
[15:50:38] <cehteh> that gives the jitter
[15:50:42] <dsal> But that doesn't fire anywhere near the edges, though.
[15:50:47] <cehteh> mmh
[15:51:15] <cehteh> if done right you should be able to make a constant time loop w/o any interruptions
[15:51:40] <cehteh> that may need some nops on fast paths from branches
[15:51:55] <dsal> Yeah. It makes sense to me briefly, but then I lose it.
[15:51:56] <cehteh> and generally reduce the complexity, have only few branches
[15:52:24] <cehteh> well its a very limited and special way to solve things
[15:52:33] <dsal> This is what it looked like in my loop thing, though:
https://usercontent.irccloud-cdn.com/file/Lw4A36JN/latency
[15:52:58] <dsal> vs.
https://usercontent.irccloud-cdn.com/file/CUL66u8B/latency.png
[15:53:20] <cehteh> doesnt tell me much
[15:53:47] <dsal> Yeah. Basically the interrupt way was almost always the exact same delay. The polling way is always faster, but has that little yellow band of variance.
[15:54:21] <cehteh> that only means your code either isnt constant speed (on all branches), or gets interrupted
[15:54:21] <dsal> But when I think about it, I don't really understand why it'd matter.
[15:54:51] <dsal> Right, the interrupt way is always jumping when an interrupt comes in. Nothing much going on.
[15:55:10] <cehteh> i'd try to do that w/o any interrupts
[15:55:17] <cehteh> maybe even w/o timer
[15:55:38] <dsal> I'm not quite sure how to get it to work without the sync timer. It seems like it'd be kind of painful.
[15:55:58] <dsal> But I'm fairly sure it only fires right in the middle of the sync pulse, so it shouldn't have an effect.
[15:56:05] <cehteh> if your loop is constant speed (for all branches taken) then you only need to increment a counter on each loop iteration
[15:56:28] <dsal> Yeah, but it'd need to be a pretty big counter, right?
[15:56:28] <cehteh> thats your timebase then
[15:56:35] <cehteh> big as in?
[15:56:53] <dsal> Big enough to not roll over in ~2µs iterations of my loop.
[15:56:54] <cehteh> its as coars as big your loop is
[15:57:10] <dsal> Er, 2ms
[15:57:21] <cehteh> assembler?
[15:57:27] <dsal> Right.
[15:57:48] <dsal> 16 bits might be enough. 16 bit ++ is a bit ugly, but doable, I guess.
[15:58:18] <cehteh> should do, if not 24 or 32 bit
[15:58:25] <dsal> Is that just the same code?
[15:58:26] <cehteh> maybe you can do it in registers
[15:58:39] <dsal> I think I've got plenty of registers.
[15:58:42] <cehteh> quite similar
[15:58:45] <cehteh> only add with carry
[15:59:19] <cehteh> how many instructions is your loop now?
[15:59:42] <dsal> This many:
https://github.com/dustin/snippets/blob/master/avr/deppm/deppm.S#L71-L91
[15:59:44] <cehteh> you could even use the timer registers for that .. lol
[15:59:47] <dsal> ha
[15:59:58] <cehteh> (w/ timer stopped)
[16:01:13] <dsal> Most of the time, it's just in, andi, cp, breq
[16:02:12] <Jartza> timer jitter in avr is relatively simple to fix
[16:03:23] <dsal> I did a PPM producer and got 20µs of jitter. Kind of annoying.
[16:03:35] <cehteh> Jartza: idea here is not to use a timer, but a constant time loop
[16:03:50] <Jartza> ah
[16:03:54] <cehteh> then you did something wrong
[16:04:00] <Jartza> I was too lazy to read what's going on :)
[16:04:27] <dsal> cehteh: :) I would believe that.
[16:04:47] <dsal> I did timer interrupts. I think b to turn up and a to turn down/set up next channel.
[16:05:16] <cehteh> you need to be careful about possibly races with other interrupts
[16:05:17] <dsal> I does OK, but then I occasionally read 20µs off on my scope.
[16:05:27] <dsal> That's true. This was isolated code, though.
[16:05:40] <dsal> I still have to figure out how I might integrate it into something else.
[16:06:23] <dsal> Here's all I had:
https://github.com/dustin/snippets/blob/master/c/avr/ppm/ppm.c
[16:06:48] <dsal> Half the reason I did that was to have something easier to test my ppm->pwm thing with. But then I started thinking about incorporating it into another project.
[16:07:34] <dsal> 20µs is kind of a lot. No idea how it could drift that far.
[16:09:09] <cehteh> its prolly not drifting but a race between interrupts
[16:09:37] <cehteh> i have some similar things which need some tricks to handle
[16:11:26] <cehteh> when one interrupt is entered, and the other one would be due meanwhile then you have some races, which can be handled but need some care and tricks
[16:12:46] <dsal> These are constant values, though. It should just do the same thing all the time, right?
[16:14:17] <cehteh> havnt looked closely at your code
[16:15:21] <cehteh> ah
[16:15:21] <dsal> Well, timer is reset at the bottom, ~3µs out B fires which raises the port, then ~1000µS or so later, A fires which brings it back down and reset timers for the next channel.
[16:15:25] <cehteh> i see
[16:15:40] <cehteh> you have this atomic block
[16:16:13] <cehteh> what happens when a interrupt triggers while its entered? ... as soon you leave that block the interrupt gets called
[16:16:52] <dsal> The atomic block just sets up the whole sequence. It shouldn't ever be called with the timer enabled, since it's disabled on the last channel.
[16:17:05] <dsal> emit() doesn't return until all the channels are finished.
[16:17:36] <cehteh> havent analyzed it further but i bet there are some races
[16:17:46] <cehteh> also .. i really dont like to reset timers :D
[16:18:05] <dsal> How do you use them without resetting them?
[16:19:03] <cehteh> in muos only one timer spins freely, its overflow ISR increments a global counter
[16:19:22] <cehteh> so global counter + hw counter gives the wall clock
[16:19:31] <cehteh> i base all time calculations on that
[16:19:46] <cehteh> (well with different types for short and long timespans)
[16:21:10] <cehteh> its a bit more expensive in many cases, but having a reliable clock is worth it imo
[16:21:22] <dsal> It seems like it'd be harder to accurately set the compare values relative to the current timer value.
[16:22:46] <cehteh> yeah i put some efforts into that, moreover i have a priority queue with a sliding window over time where timed jobs are recorded
[16:23:00] <cehteh> thats gone somewhat more complicated
[16:23:40] <dsal> I tried messing with wgm without understanding it and just got confused.
[16:24:33] <dsal> I wanted to do a pwm output. That's not practical anyway since it won't trigger enough outputs.
[16:57:56] <daey> how do i write a program to a specific place in the flash with avrdude?
[16:58:12] <daey> im tinkering around with a bootloader that i want to place at 0x3800
[17:01:24] <eszett> hi! last days i asked for a script/code that checks the AVR for "is it soldered correctly or not?" .
[17:02:23] <eszett> I checked with my multimeters continuity function each pin together with its neighbouring pin, that no solder bridges are there. that works pretty good, im quickly done with this check.
[17:03:20] <eszett> so i need no script for that. but what remains is the check of "have the pins proper connection with the pads?". I cant use my multimeter to check that
[17:04:03] <eszett> So.. how would i write the code to check this by software?
[17:05:17] <daey> just use the continuity check?
[17:05:56] <eszett> for checking solder bridges, yes. but what about checking for proper connection of pins to pads?
[17:06:04] <daey> yes?
[17:06:20] <daey> put one probe on the pin, the other on whatever the pin is connected to
[17:06:33] <eszett> my pins pads are too small, i cant explicitely put a probe to pin1 and the other probe to pad1
[17:06:58] <daey> you arent supposed to put it on pin1 pad1
[17:07:04] <eszett> im happy when i somehow hit with the probe the right pin/pad but to differentiate between them is too fiddly
[17:07:10] <daey> pin1 follow trace 2nd probe
[17:07:30] <eszett> yea but that check would take more time
[17:07:40] <eszett> a software solution would be more convenient
[17:08:20] <daey> more time than writing a program that knows the environment it runs in and magically checks connections? i think not.
[17:08:30] <eszett> as probes i use the leads of a Diode. and even these leads are pretty huge compared to the pins/pads of my AVR
[17:08:56] <eszett> and my eyes are weak. i could do it with eyeglass magnifiers perhaps
[17:09:03] <daey> anyways its unlikely that pins arent connected if you drag solder them properly
[17:09:41] <eszett> hmm probably yes. since i tend to put rather too much solder on, than too less
[17:09:56] <eszett> so i skip this check
[17:10:17] <daey> yeah i would bother with it, unless you stumple across something weird
[17:10:43] <eszett> just saw that there is a pretty cheap 60x microscope from china, which you can apply to your I-Phone, is it any worth?
[17:11:25] <eszett> https://www.youtube.com/watch?v=09Pq6dueWmM
[17:12:04] <eszett> maybe this is a better video
https://www.youtube.com/watch?v=YokWp_a8gHc
[17:31:29] <aandrew> I kind of doubt it
[17:31:58] <eszett> hm hm ordered it anyway, we'll see..
[17:32:34] <aandrew> I mean if you're trying to use it as an inspection microscope it's fail
[17:32:47] <aandrew> but if you want something to play with it's not a bad little toy
[17:32:57] <aandrew> I've certainly bought toys along the same lines before
[17:34:52] <eszett> lol..
[17:35:10] <eszett> well i actually bought it to inspect the solder joints, so i failed hm maybe
[17:56:17] <WormFood> [05:32:12] <daey> im tinkering around with a bootloader that i want to place at 0x3800 <-- byte or word address?
[17:57:58] <WormFood> LDFLAGS += -Wl,--section-start=.text=1800 <-- add this to your Makefile, of course changing the name of LDFLAGS if necessary. That will locate your code at 0x1800 as byte address (0xc00 as a word address, which is what the datasheet uses)
[18:00:37] <WormFood> eszett, remember back in the "good 'ole days"(tm), when we'd test serial ports with a loopback connector, that was specifically for testing? Well, you may need something like that for your board, to test the continuity of the traces.
[18:01:48] <WormFood> Say for example, pin 1 and pin 2, go to some off-board connector. Make a loopback for it, and you can easily test continuity in software.
[18:04:44] <eszett> WormFood is this loopback done merely by software code or do i need some hardware for it?
