Back
[00:13:54] <Lightsword> how would I go about identifying the pinout and settings for a serial console with an unknown pinout?
[00:14:31] <Casper> pinout... might be easyish
[00:14:36] <Lightsword> I think I found the ground since 2 other connections give 3.3v
[00:14:48] <Lightsword> when crossed with it
[00:14:48] <Casper> 3 pins are needed, ground, data out and data in...
[00:15:01] <Casper> ok
[00:15:04] <Lightsword> so ground when crossed with data out or data in gives 3.3v usually right?
[00:15:19] <Casper> maybe
[00:15:29] <Casper> are you sure that you do have the right ground?
[00:15:36] <Lightsword> no....
[00:15:46] <Lightsword> how would I find that out?
[00:15:48] <Casper> and depending on some circuit, you may have a VCC pin too
[00:15:55] <Casper> check with a known ground
[00:16:04] <Lightsword> what would be a known ground?
[00:16:15] <Casper> quite possibly the power
[00:17:00] <Lightsword> what should I be looking for when crossing with a known ground?
[00:26:21] <Lightsword> Casper, when I cross a ground point on it to what I think is the ground connection I get 0V
[00:26:49] <Casper> so most likelly it
[00:26:56] <Casper> do you have 3 or 4 pins?
[00:27:22] <Lightsword> Casper 6 actually, but I don't think all have traces
[00:27:35] <Casper> is it a router?
[00:27:59] <Lightsword> Casper, it has ethernet but no, serial is rj11 style
[00:28:31] <Lightsword> and I have a movable adapter
[00:28:38] <Casper> ok, routers are mostly reverse engineered already
[00:28:53] <Lightsword> yeah, I already check on that, nobody reverse engineered this device
[00:28:56] <Lightsword> its not linux based
[00:29:06] <Lightsword> some sort of RTOS is my guess
[00:29:21] <Casper> so... my guess is 4 pins are used
[00:29:32] <Casper> gnd, vcc, data out, data in
[00:29:43] <Lightsword> ok, so I think I have identified ground
[00:29:50] <Lightsword> how would I identify vcc?
[00:30:27] <Casper> logically, data out should oscillate, or stay low... a dmm shouln't read 3.3V, but can read something highish
[00:30:57] <Casper> data in should be 0... unless they used a pullup... which I find weird...
[00:31:03] <Casper> VCC should be hard high
[00:31:13] <Casper> that said, they may have also inverted the signal
[00:31:32] <Lightsword> well I have one pin at least that is almost exactly 3.3
[00:31:36] <Lightsword> is that vcc?
[00:31:38] <Casper> but for data in, you should be able to find it possibly
[00:31:42] <Casper> possibly
[00:31:58] <Casper> try a resistor (like 1k) to ground
[00:32:17] <Casper> if it do not change then you can be almost sure it's vcc
[00:32:31] <Lightsword> I don't think I have a resistor
[00:33:20] <Casper> :(
[00:33:35] <Casper> but the serial out may not work all the time
[00:33:40] <Casper> it may be only at power up
[00:33:48] <Casper> or only when it receive some data...
[00:34:09] <Lightsword> well, I've been getting some garbage output for some pin configurations
[00:34:19] <Lightsword> tried all baud rates with no luck
[00:34:42] <Casper> and no oscilloscope?
[00:34:54] <Lightsword> nope, just a multimeter and serial adapter
[00:35:11] <Casper> I wonder if you may be dealing with an inverted signal
[00:35:31] <Casper> 0/3.3V logic should idle at 0V
[00:35:42] <Casper> if you read 3.3V on the data out then it's most likelly inverted
[00:35:52] <Lightsword> well, I have quite a few pins
[00:36:12] <Lightsword> so one should idle at 0 and jump when data goes through?
[00:36:26] <Casper> yes
[00:36:37] <Lightsword> how much should it jump by?
[00:36:47] <Lightsword> like over 1v?
[00:36:50] <Lightsword> or less?
[00:37:02] <Casper> on your dmm, "anything"
[00:37:10] <Casper> on an oscilloscope, near 3.3V
[00:38:51] <Lightsword> so I have 2 connections that when grounded give me about 3.3V
[00:38:59] <Lightsword> one is almost exactly 3.3 one a little less
[00:39:03] <Lightsword> but neither move
[00:39:51] <Lightsword> ill make a list real quick of the pins
[00:39:53] <Lightsword> and what they read
[00:40:03] <Casper> a multimeter is not made to handle the fast varying signal that the output gine
[00:40:22] <Casper> it's made for a steady signal<
[00:40:36] <Casper> so may be unable to even see the signal
[00:40:58] <Casper> this is why you almost need an oscilloscope to find out stuff...
[00:41:14] <Casper> (mine can even decode and display the signal)
[00:41:17] <Casper> but bed time
[00:41:18] <Casper> nite
[00:47:19] <Lightsword> anyways this is the pinout
https://gist.github.com/jameshilliard/8d542fab93d1e65c39ff and readings
[02:05:51] <melonsoda> ayeeeeeeeee
[02:32:59] <ecilop> How can I get address of a low byte in uint16_t ?
[02:34:37] <ecilop> Sample:
[02:34:40] <ecilop> uint16_t timer_max EEMEM;
[02:34:46] <ecilop> I need addresses of low and high bytes.
[02:42:08] <jacekowski> ecilop: well, timer_maxis your address
[02:49:34] <ecilop> no, it's address of first byte
[02:49:48] <ecilop> I need 2 addresses, low and high from uint16_t
[02:50:58] <ecilop> uint16_t = (uint8_t<<8) | uint8_t ; //I need both addresses uint8_t
[02:52:55] <jacekowski> why do you want both addresses?
[02:53:18] <jacekowski> there are functions that will ready complete word from eeprom
[02:53:23] <ecilop> it's a second question.
[02:53:26] <jacekowski> so you don't have to
[02:54:12] <ecilop> I use own function for deferred write in eep
[02:54:31] <ecilop> main cycle must not wait eep_write end
[02:57:50] <ecilop> http://pastebin.com/scgHHPJq - my foolish function. Don't laugh. It works fine for me. I not recommend use it. It's only for my programs.
[04:07:46] <ecilop> There are sоме errors in pasted asm source
[05:12:20] <nhere> i am trying to activate pwm outputs on attiny87, i am using this code, but port B is not working at all, while port A is working:
http://pastebin.com/ip1LxypW
[05:12:32] <nhere> any tips what to try?
[05:20:40] <RikusW> nhere: TCCR1A= (1<<COM1A0) | (0<<COM1B0) | (0<<WGM11) | (1<<WGM10);
[05:20:56] <RikusW> use toggle not set
[05:22:08] <RikusW> also mode 15 might not be the best for your purposes
[05:22:31] <RikusW> how about mode 5 ?
[05:23:04] <nhere> i am very new here, can you explain in more details?
[05:23:16] <nhere> btw, port A is working, port B is not working
[05:23:45] <RikusW> TCCR1A= (1<<COM1A0) | (0<<COM1B0) | (0<<WGM11); //mode 14
[05:24:29] <RikusW> nhere: you should probably go read the entire timer 1 chapter in the datasheet
[05:26:21] <RikusW> TCCR1B = (0<<WGM13) | (0<<WGM12) | (1<<CS12) | (0<<CS10);
[05:26:46] <RikusW> do you really use external clock on T1 ???
[05:28:36] <nhere> no, i use internal
[05:28:42] <nhere> (i want to use internal)
[05:32:10] <RikusW> TCCR1A= (1<<COM1A0) | (0<<COM1B0) | (0<<WGM10); //mode 5
[05:32:11] <RikusW> TCCR1B = (0<<WGM12) | (1<<CS12) | (0<<CS10);
[05:32:24] <RikusW> try mode 5 ?
[05:36:29] <nhere> so you suggest ti replace those two line to your suggested ones?
[05:36:37] <nhere> *to
[05:37:02] <RikusW> yes
[05:39:55] <nhere> ok, i will try it
[05:41:58] <nhere> RikusW, btw,
http://i.snag.gy/mdL4E.jpg
[05:42:02] <nhere> here my settings
[06:17:58] <nhere> i have tried your suggested code, but it still does not work (port B)
[06:18:39] <nhere> RikusW,
[06:55:48] <ecilop> maybe I can help
[06:56:06] <ecilop> Little chance :)
[07:10:09] <RikusW> was afk...
[07:36:45] <bezoka> hello
[07:36:49] <bezoka> how are you all?
[07:41:51] <ecilop> ?
[07:47:27] <abcminiuser> Tom_itx, have an email asking about you
[08:21:08] <Duality> hi
[10:53:22] <FoxGT> Is there any downside to using the code blocks ide?
[10:54:09] <FoxGT> I've been using studio & want to switch to something less resource hungry.
[12:55:20] <pzak> Is anyone familiar with the Serial USART Driver (SerialSPI.h) from LUFA?
[12:58:02] <pzak> I'm building for AT90USB1287, and the following macros are coming up undeclared UCPOL, UDORD, UPCHA.
[13:01:17] <pzak> I'm considering defining the pins, but I figured there would already be something in LUFA to take care of that --- esp since most of the demos are written for AT90USB1287 already
[13:03:54] <RikusW> those are for SPI, just define them
[13:04:02] <RikusW> its used to se the SPI mode
[13:04:22] <RikusW> the mega1287 datasheet will clarify
[13:07:28] <pzak> RikusW: I was going to do `#define UCPOL UCPOL1`, etc., but I'm surprised this isn't already taken care of by LUFA...
[14:18:13] <Jartza> ahh
[14:18:31] <Jartza> does atmega328 always need a chrystal/oscillator for isp-programming?
[14:35:01] <hetii> Jartza: all depends on fusebits
[14:36:05] <hetii> Jartza: if its brand new then suppose you don`t need crystal but you need program it in slower SCK signal.
[14:36:15] <Jartza> ok
[14:36:23] <Jartza> so it's wise to put one anyway?
[14:37:04] <hetii> it will not harm, all depend if you will plan use it in future.
[14:37:07] <Jartza> I'm making a small zif-board for my isp-programmer to atmega328
[14:37:33] <hetii> if yes then you need to set proper fuses and then you can programm it faster.
[14:37:58] <Jartza> well, I guess I'll place the crystal there then
[14:38:40] <hetii> yep i guess its a better choice.
[14:38:58] <hetii> but using zif socket is overhead imho.
[14:39:37] <hetii> If you plan build paraller programmer for it then it make more sense :)
[14:40:09] <hetii> You can also see
http://mdiy.pl/atmega-fusebit-doctor-hvpp/?lang=en
[14:40:40] <hetii> Its very useful project when you set wrong fuses and need to restore your AVR.
[14:45:40] <Jartza> yeah, I've build fusebit doctor already
[14:46:10] <Jartza> I just like zif sockets, and I happen to have them :)
[14:46:41] <Jartza> in fact, currently they are the only 28-pin sockets I have
[14:46:53] <Jartza> then I have 8- and 14-pin dip sockets
[14:47:15] <kastein> I hate soldering zif sockets into stuff, so I normally put a socket on the board, then stick a zif socket in it if I want one
[14:47:18] <kastein> because damn zif sockets are expensive
[14:48:02] <Jartza> expensive?
[14:48:14] <Jartza> those 28-pin sockets were something like $0.8 each
[14:48:36] <Jartza> of course they're not "real" TEXTOOL, but TFXTDOL branded :D
[14:49:01] <kastein> ahh, nice
[14:49:06] <kastein> last time I bought one it was like 15 bucks
[14:49:19] <Jartza> http://www.tinyosshop.com/index.php?route=product/search&filter_description=true&filter_sub_category=true&filter_name=zif
[14:49:23] <kastein> and I'm not wasting a 15 dollar part I could easily reuse on something else lol
[14:49:37] <kastein> wow, cheap
[14:49:38] <kastein> thanks
[14:49:42] * kastein bookmarks
[14:51:25] <Jartza> yeah, I wouldn't use zif for this either if it was that expensive :)
[14:51:37] <Jartza> but one of those $0.8 sockets, well, why the heck not
[14:51:41] <kastein> yeah
[14:51:44] <kastein> might as well at that point
[14:52:03] <kastein> I now have the urge to build an eprom burner again, even though I can buy one cheaper than I can build one
[14:52:14] <Jartza> :)
[14:52:28] <Jartza> I do have few of those cheap olimex avr-isp-mk2 programmers
[14:52:42] <Jartza> but I hate placing the chips into breadboard and the wiring
[14:52:56] <Jartza> I already etched one board for 8- and 14-pin attinys
[14:53:26] <Jartza> but now I want to try those atmegas, and thought to etch new board which has 28-pin and 14-pin zifs
[14:53:35] <Jartza> maybe even 20-pin
[14:53:54] <Jartza> 8-pin and 28-pin chips can be programmed in same socket ;)
[14:55:31] <mheld-irccloud> anybody want to make some money helping me write firmware for a device we're manufacturing?
[14:55:47] <mheld-irccloud> it's super simple GPS + GSM/GPRS
[14:55:48] <Jartza> that of course depends of the device
[14:55:52] <mheld-irccloud> and I have most of the code already
[14:55:58] <mheld-irccloud> but I can't spend any more time on it
[14:56:08] <mheld-irccloud> gotta work on power consumption, etc
[14:56:32] <Jartza> what chip?
[14:56:40] <mheld-irccloud> atmel xmega 16a4u
[14:56:54] <Jartza> mmkay
[14:57:17] <Jartza> I'm not sure if I have any time, but I have few colleagues who also write avr code
[14:57:20] <Jartza> I can ask, if you wish
[14:57:35] <mheld-irccloud> yes please!
[14:57:38] <mheld-irccloud> we're a funded startup
[14:57:43] <mheld-irccloud> I have cash to burn on this
[14:58:46] <mheld-irccloud> email -> marc@weft.io
[15:07:32] <Jartza> mheld-irccloud: will ask!
[15:07:42] <hetii> hmm
[15:08:24] <hetii> mheld: what need to be done there ?
[15:24:30] <mheld-irccloud> hetii: I have firmware that works but I don't understand why it does
[15:24:44] <mheld-irccloud> hetii: and I have firmware that doesn't 100% work
[15:24:55] <mheld-irccloud> but can't figure out why it's not 100%
[15:25:03] <mheld-irccloud> hetii: I'm fine with scrapping them as long as they fit the spec
[15:25:27] <mheld-irccloud> (they need to do an environmental sample every N minutes, where environment consists of temperature, humidity, battery, location)
[15:25:37] <mheld-irccloud> location is special -- we should fall back on cell triangulation
[15:25:57] <mheld-irccloud> maybe we just send a scan of all the towers we see along with the signal strength and do the triangulation server-side
[15:26:31] <mheld-irccloud> OH, and the ping frequency should be reconfigurable (the device pings an environmental sample and checks its mailbox for reconfig instructions)
[15:28:47] <hetii> hmm you based on someone work ?
[15:29:42] <mheld-irccloud> I had someone write firmware for me a while back
[15:29:53] <mheld-irccloud> it worked, but I couldn't change it
[15:29:56] <mheld-irccloud> because it was pretty gross
[15:30:06] <mheld-irccloud> then the dude who wrote the firmware got fired from the firm
[15:32:58] <hetii> I see...
[20:36:41] <aandrew> for the ATTINY25, which pins are used for ISP? is it reset, SCK, MISO and MOSI?
[20:36:57] <aandrew> the datasheet is less than clear
[20:37:54] <Tom_itx> generally those are the pins yes
[20:38:04] <Tom_itx> there are a few odd chips out there though
[20:47:01] <aandrew> *nods*
[20:47:16] <aandrew> moved one of my signals off the reset pin just to help keep things easy
[21:20:34] <Casper> aandrew: I confirm that it should be it, I have the datasheet on hand
[21:20:42] <Casper> but never checked it up
[21:20:57] <Casper> well, never tried
[21:20:59] <Casper> I did checked it
[21:21:07] * Casper haves some tiny85
[21:38:01] <aandrew> Casper: thanks
