Back
[01:56:12] <Haohmaru> when the 595 shift register sees a negative-to-positive edge on the stcp, it takes the internal data and puts it on all output pins at once, right?
[01:57:05] <gevorg> not sure, what does the DS say ?
[01:58:34] <Haohmaru> the datasheet has a function chart where it shows the states of the pins and has a description on each.. but there are two variants where the STCP pin gets a positive edge, and two descriptions
[01:59:24] <gevorg> hmm don't see an stcp on my ds
[02:00:03] <Haohmaru> it's probably called something else
[02:00:05] <gevorg> but I see a RCK pin, which might do the same function
[02:00:27] <Haohmaru> stcp == "storage register clock"
[02:00:38] <gevorg> yeah ok then its RCK
[02:00:57] <gevorg> it says here on rising edge it stores infromation in s.r.
[02:01:13] <Haohmaru> wut
[02:01:22] <gevorg> and on falling edge, nothing happens
[02:01:49] <gevorg> datasheet page 5, table 3 (truth table), last end prelast rows
[02:01:52] <Haohmaru> ah, "storage register" is like the internal buffer of 8 bits, right?
[02:02:03] <gevorg> yup
[02:02:26] <gevorg> so it knows, in case there are multiply chained together, which 8 bits to output
[02:03:30] <Haohmaru> "contents of shift register stages (internal QnS) are transferred to the storage register and parallel output stages"
[02:04:07] <Haohmaru> this would just take the buffered bits and apply their values on the parallel output pins.. at once, right?
[02:04:25] <gevorg> yes, exactly
[02:05:50] <Haohmaru> so the other variant, where both STCP and SHCP get a positive edge is doing something more funky
[02:06:09] <Haohmaru> "contents of shift register shifted through; previous contents of the shift register is transferred to the storage register and the parallel output stages"
[02:07:04] <Haohmaru> so this puts out the current bit values and shifts once?
[02:07:17] <gevorg> yes, it's like two stage 8 bit buffer
[02:08:23] <Haohmaru> i'd want to cascade a few of these, but i want to shift all the bits and then apply the values on all of them at the same moment
[02:08:31] <Haohmaru> should i use the first variant?
[02:10:10] <gevorg> well depends, how much io do you have at hand ?
[02:10:49] <gevorg> if you have a spare pin for RCK, then that would be the best variant
[02:10:58] <gevorg> not sure you can do it otherwise
[02:11:40] <Haohmaru> i've reserved pins for STCP, SHCP and DS
[02:12:39] <Haohmaru> SHCP == shift register clock
[02:14:08] <gevorg> so you have the clock, data in, and storage reg. clock
[02:14:19] <Haohmaru> yeah
[02:14:20] <gevorg> yeah, seems that's all you'll need
[02:14:57] <Haohmaru> i don't have the OE (output enable) so i can't put it in hi-Z state, but i don't think i'll need this
[02:15:41] <gevorg> yeah, shouldn't be a problem
[02:32:53] <Haohmaru> do you guys prefer bitbanging the shift registers or using something like an SPI?
[02:43:40] <gevorg> well, usually the chips support like up to 20mhz, so with 16 mhz avr, bitbanging sounds like a good option, but when you have the spi sitting there doing nothing, it would be better to use it
[02:44:18] <cehteh> whatever works
[02:44:54] <gevorg> when the input clock freq is high, just writing one, then zero to clock will work, as with 16mhz, it should take one instruction to set the PORT registers, so you are still less than 20 mhz
[02:45:10] <gevorg> but when you have slower speeds, use the SPI, or uart in SPI mode, if supported
[03:17:05] <Jartza> the shift register speed also often depends of the VCC
[03:17:17] <Jartza> like 74hc595
[03:18:14] <Jartza> it can survive 5MHz clock with 2V but ~25MHz with 5V
[03:19:07] <Jartza> oops, not 5V, 3.3V I think
[03:43:17] <gevorg> so, there are few things to consider
[03:45:50] <Haohmaru> luckily i don't require any specific timing, just fast enough (so it can be done frequently) so it doesn't get in the way of other tasks
[10:18:05] <studdentt> someone familliar with CAN bus >
[10:47:46] <Jartza> studdentt: I've talked to CAN bus, what about it?
[10:52:38] <Jartza> https://proximia.fi/websvn/listing.php?repname=Public&path=%2Ftrunk%2Flib%2Fcan%2F&#a4a62e61c62aaef734a69f13da9309fa5
[10:53:21] <Jartza> that's a working CAN library for certain avrs
[10:54:06] <Jartza> there's basically two variants of can, other is with 11 bit and the other with 29 bit ID
[11:00:06] <studdentt> what is the MOb's ? are they the whole frame?
[11:00:14] <studdentt> the datasheets explains it so-so
[11:00:21] <studdentt> and canpage ? what are they?
[11:00:44] <studdentt> ..and i was also looking for working examples with librairies
[11:01:56] <studdentt> if i got it correctly, one node sends a MOb and to receive it, the other node must listen to that MOb
[11:05:28] <keithbrown> anyone familiar with the bluegiga ble112-a
[11:13:55] <cehteh> mhm has the USART some startup time, i just enable it, push data to my tx buffer and the first few bytes come out garbled
[11:15:23] <cehteh> (at unusal/extreme settings .. 62.5kHz system clock, 300baud serial)
[11:16:28] <Casper> cehteh: try ti set up the startup delay fuse thingy
[11:16:32] <studdentt> cehteh: try it at higher sys clock first to validate your setings
[11:16:55] <Casper> it take time for a clock to stabilize
[11:17:05] <cehteh> that works, i am just trying to see if there are any bugs when i operate at the limits
[11:17:32] <Casper> and if the first byte is corrupted and you send many in a row, chance is that many bytes will be corrupted
[11:17:47] <Casper> until the receiver succede to sync back up
[11:17:50] <cehteh> yeah the first line is corrupted
[11:18:17] <Casper> which might be at the first buffer empty condition (first delay)
[11:20:17] <cehteh> actually i print "Ready\r\n" right at startup and then going into a lineeditor .. the lineeditor works only the Ready is garbled and when i send it twice the second works, doesnt completely surprise me at this extreme settings but i wonder which part garbles it up and how i could fix it
[11:20:32] <cehteh> avr, ftdi, receiver ...
[11:20:45] <cehteh> or possibly i just forget about it
[11:23:25] <Casper> cehteh: startup delay
[11:24:00] <cehteh> i add a _delay there makes no difference
[11:24:24] <cehteh> and its external osc . arduino nano with 16Mhz crystal
[11:25:16] <cehteh> prolly the receiver needs to sync
[11:25:18] <Casper> weird
[11:25:23] <Casper> possible
[11:25:27] <cehteh> or ftdi
[11:25:28] <Casper> auto-baud?
[11:25:50] <cehteh> using the baudrate macros from avrlibc, static baudrate
[11:26:07] <Casper> the receiver
[11:26:23] <cehteh> receiver in this case is the ftdi on the nano board
[11:26:49] <cehteh> ah .. i am proogramming at 115200 or so .. only my firmware switches to 9600 .. lemme reset
[11:27:12] <cehteh> nop ..
[11:27:42] <cehteh> just reseting the avr while the ftdi stays connected is still garbled up
[11:28:45] <cehteh> mhm
[11:29:26] <cehteh> when i send 2x 16 \r with delay inbetween its still garbled up
[11:29:35] <cehteh> now i suspect my terminal emulator :D
[11:32:37] <cehteh> ah got it :D
[11:33:13] <cehteh> my fault :D
[11:38:37] <Casper> picnic then, what was the issue?
[11:40:02] <Jartza> studdentt:
https://www.kvaser.com/can-protocol-tutorial/
[11:40:06] <Jartza> that's very nice tutorial of CAN
[11:42:52] <Jartza> studdentt:
http://marco.guardigli.it/2010/10/hacking-your-car.html that's another one, mainly talking about hacking cars, but still contains a lot of useful info about CAN
[11:57:15] <cehteh> Casper: i'Ve set the clockdiv after sending data
[11:58:10] <cehteh> (sending → pushing things on a queue)
[12:03:12] <studdentt> Jartza: will take a look, ty
[12:13:58] <Jartza> studdentt: no prob, I read those myself when I had to talk to CAN and I didn't know anything about it :)
[12:49:30] <julius> hi
[12:49:31] <julius> ive got a rear view camera here, it got a 12v power line and a cinch line for the camera. but the documentation does not specify if the pin or the outer shell of the cinch connection carries the camera signal. the lcd board has AV and GND. can i assume that the chinch female connection got the data line on the "inner" cable and GND around it?
[12:50:08] <julius> or can i measure that somehow?
[12:50:39] <cehteh> almost certainly the shell is the shield/ground and pin is signal
[12:51:00] <julius> could i measure both against +12v of the power supply? if i get ground the multimeter should say -12v?
[12:51:14] <julius> sounds reasonable
[12:51:46] <julius> gonna go measure anyway
[12:51:56] <cehteh> you can disconnect the camera and measure the shell against the power lines minus
[12:52:07] <cehteh> should be close to 0 ohms
[12:52:36] <cehteh> but dont forget that when measuring ohms you load some measureing voltage on the subject
[12:55:27] <julius> hm ok
[12:55:51] <julius> and assuming the shell is GND, cant i measure that against +12v?
[12:56:26] <cehteh> measureing voltage is ok
[12:56:33] <cehteh> but wont tell that much
[12:57:05] <cehteh> anyway .. its 99.999999% sure that the pin is signal
[12:57:09] <julius> but if the data is on the pin, that against +12v should give 0v or something differet than 12v?
[12:57:44] <cehteh> its signal, means some waveform your DMM cant follow, dc and less than 12v for sure
[12:58:00] <julius> ok
[12:58:16] <julius> and that could hurt the camera?
[12:58:41] <cehteh> just connect the camera to lcd
[12:59:29] <julius> thing is the camera got cinch, and the lcd got some weird 5pin connector containing AV2 and GND
[12:59:34] <julius> got no cable for that
[13:00:14] <julius> currently ive got a computer power switch cable (the one that does froḿ the case power switch to the motherboard (2pin)) connected
[13:03:56] <cehteh> as i saied its almost sure that it will work. if you are extremely cautionous you may connect the camera to the board via 1k resistors then at least some short circruit would be limited and signals may pass through (for tests at least)
[13:04:14] <cehteh> but this is so much standard i would just connect it and it will work
[13:08:45] <julius> ok
[13:08:47] <julius> it does
[13:10:35] <julius> well, now i know that the board accepts composite video
[13:19:29] <Casper> julius: check continuity between power ground and signal ground
[13:44:32] <julius> camera works, thx
[15:27:05] <julius> WormFood, hey, you there?
[19:43:19] <Jartza> https://www.youtube.com/watch?v=8BMM-UMZQlY
[19:45:28] <studdentt> Jartza: what are you doin?
[19:46:48] <Jartza> studdentt: 8-color VGA from attiny5
[19:47:05] <Jartza> that's tiny
[19:47:33] <Jartza> 6 pins sot23, 32 bytes of sram, 512 bytes of flash
[19:48:24] <Jartza> one pin goes to oscillator, leaving me with 3 usable pins when I disabled reset :)
[19:51:45] <Jartza> http://www.embeddedstar.com/postimages/2009/ATtiny-Microcontroller.jpg
[19:51:50] <Jartza> that size
[19:55:05] <Casper> vga? look like cga
[19:56:01] <studdentt> but how do you get these colors on screen ?
[19:56:06] <studdentt> you are driving soe vga controller ?
[20:03:10] <Casper> colors are easy to get... but what impress me more is how he succede to make all that...
[20:03:14] <Casper> RGBHV...
[20:03:25] <Casper> that's 5 lines... he have 4 pins
[20:06:52] <phinxy> i have a display that will not run on 3.43V but 3.5V it runs. The datasheet says:
[20:06:54] <phinxy> MCU interface logic level & low voltage power supply
[20:07:04] <phinxy> 1.65V - 3.5V
[20:07:39] <phinxy> is the voltage divided by two when doing i2c? since it goes on/off
[20:12:07] <Casper> I2C do not divide the voltage
[20:12:46] <studdentt> phinxy have you looked at your voltage rail on an oscilloscope ?
[20:14:53] <phinxy> ill just set the power supply to 3.6V and see if the voltage drops too much when the battery is drained
[20:16:11] <phinxy> aha. the datasheet is only for the actual display and not the complete "kit" i got from seeedstudio
[20:16:37] <phinxy> so there are a lot of extra components that.. does stuff
[20:18:00] <phinxy> on their website it says "öWorks with both 5V and 3.3V logic MCUs."
[20:19:01] <studdentt> you have a schematic?
[20:20:43] <phinxy> a components list
[20:21:55] <studdentt> s schema would be better
[20:22:27] <phinxy> 9 resistors, 4 caps a diode and what looks like 3 transistors
[20:22:43] <phinxy> go figure (
[20:25:51] <phinxy> it could be a flux capacitor or time machine for all i know )
[21:06:32] <phinxy> I have a magnetic sensor (hall sensor) it needs a 4.7nF capacitor between Vcc and GND. What if i want to add more sensors..? do i do 4.7 + 4.7 and add that cap?
[21:07:17] <studdentt> put one cap for each as close to the chip
[21:09:34] <Casper> phinxy: that capacitor is there to help about the electrical noise and track resistance
[21:09:58] <Casper> JoeLlama! are you the one behind the find the cow?
[21:10:57] <JoeLlama> Casper no I have just had that in my quit message
[21:11:00] <JoeLlama> MOO!!
[21:13:33] <Casper> meeeh
[21:14:03] <phinxy> My hall sensor works. It feels a little random when it triggers. is it a bad idea to have the sensor like half a meter from the chip?
[21:15:15] <phinxy> Maybe it is the magnet thats bad. its the flat bendable type you put on the fridge
[21:15:54] <Casper> oh those are very weak
[21:16:13] <Casper> also, they are not made to have a big distance
[21:16:34] <phinxy> i need the sensor to touch the magnet
[21:17:04] <phinxy> any idea of what magnet i could use for a fast spinning wheel?
[21:18:19] <Casper> anything else
[22:08:20] <lorenzo> so Microchip will buy Atmel?
[22:09:24] <lorenzo> http://www.theregister.co.uk/2016/01/15/microchip_atmel/
[22:12:11] <Casper> lorenzo: most likelly, which might be a good thing, or the end
[22:13:00] <lorenzo> I wonder if it's just a "commercial" acquisition
[22:13:05] <lorenzo> or if they'll move the product lines too
[22:13:14] <lorenzo> like, PICmega32u4 :p
[23:07:13] <studdentt> no more avr?!
[23:07:40] <studdentt> 'picdude' >.>
[23:27:52] <Xark> PIC is fine as long as it appears with "32". It is the other smaller PICs that are worrisome. :)
[23:32:51] <Casper> Xark: wants some pic16f84 ? :D
[23:36:14] * Xark backs away slowly. :)
[23:36:33] <Casper> what about some pic12?
[23:36:39] <Casper> of the c familly?
[23:37:05] <Xark> Like I said, "32" or GTFO. :)
[23:37:24] <Casper> ... but 2 pic16 is 32!
