Back
[03:18:04] <superware> I'm developing a Brushed DC Motor Controller for an existing camera gimbal, will running a single PID control loop suffice performance/accuracy wise?
[03:49:52] <antto> a device which has atmega, FTDI (usb-serial), getting lots of corrupted bytes... could the cause be the XTALs being way off?
[03:51:14] <antto> the atmega is with 16MHz xtal, while the ftdi with 6MHz, the serial port baudrate is supposed to be 19200
[03:54:03] <Roklobsta> should be fine. the atmel data sheet has a table of XTALclock/baud.
[03:54:13] <Roklobsta> i doubt the ftdi is bonkers
[03:55:16] <antto> what could be causing the data to get corrupted?
[03:56:03] <antto> not all bytes, just some, but frequently enough to make the bootloader unusable, it can't even reach the point to start receiving firmware data
[04:49:07] <antto> any tips are welcome
[04:53:39] <Valen> can you slow the data rate
[04:53:51] <Valen> is anything else hanging off the pins used?
[05:06:57] <antto> Valen slow like, add small pauses between the bytes or lower the baudrate on the computer *slightly* ?
[05:08:22] <Valen> lower it a whole bunch
[05:08:38] <Valen> if you can run at a lower baud rate then do so
[05:08:51] <Valen> like 9600 bps rather than 57000 or whatever it wants
[05:11:22] <antto> i can't change the baudrate on the device itself, only on the computer
[05:11:33] <antto> it's hardcoded to 19200
[05:12:09] <Valen> odds are if it has a crystal that isn't the problem
[05:12:20] <Valen> look for other stuff on the lines
[05:12:39] <antto> some electrical noise/interference bleeding into the data pins?
[05:13:06] <antto> both the atmega and ftdi have resonators, 16M and 6M respectively
[11:27:57] <rue_house> http://www.ebay.ca/itm/3M-Textool-Zip-Strip-Socket-20-Pin-SIP-ZIF-Zero-Insertion-Force-220-2600-00-0602-/141252926673
[11:28:04] <rue_house> haha they make sip zifs
[12:51:51] <bss36504> Strange issue: I’m using timer1 on a 32U4, and when my main is just a infinite loop, it interrupts properly. When I have the timer interrupt enabled as well as the rest of my code, it works ok until i call one function in particular, then I get a bad ISR. If I comment out the TIMSK1 |= (1<<OCIE1A) the interrupting stops in both cases, and in the second case, the bad isr no longer fires and the code works properly
[12:51:55] <bss36504> any ideas?
[12:54:48] <bss36504> Oh, I should also mention that I have another timer interrupt on timer0 that operates happily in the aforementioned function.
[14:01:32] <Lambda_Aurigae> rue_house, those things look like they are meant to be ganged together too.
[19:19:34] <rue_house> have you never seen a sip?
[19:20:05] <Tom_itx> a sip of what?
[19:20:07] <Tom_itx> tea?
[19:21:16] <Lambda_Aurigae> rue_bed, yeah, I have some here.
[19:21:23] <Tom_itx> nearly got the sql working...
[19:21:25] <Lambda_Aurigae> I also have SIPP modules here.
[19:21:34] <Tachyon`> oh god
[19:21:37] <Tachyon`> I remember SIPPs
[19:21:45] <Tachyon`> 30 pin SIMMs with pins soldered on
[19:21:47] <Lambda_Aurigae> just 30 pin SIMMs with pins soldered on.
[19:21:55] * bss36504 goes to google SIPP
[19:22:06] <Lambda_Aurigae> great for playing around with...fits right into a solderless breadboard.
[19:22:16] <bss36504> ooh neat
[19:22:26] <Tachyon`> so do microchip 128K SPI RAMs
[19:22:33] <Tachyon`> and they take rather less pins
[19:22:38] <Lambda_Aurigae> yeah.
[19:22:55] <Lambda_Aurigae> I have some of their 1Mb spi srams.
[19:23:03] <Tachyon`> aye, that's what I meant by 128K, lol
[19:23:22] <Lambda_Aurigae> spi sram takes rather a bit less software to manage too as SIPPs were dram and need constant refresh.
[19:23:46] <Tachyon`> aye and with an 8MHz SPI bus they still nip along quite nicely
[19:23:53] <Tachyon`> particularly as the microchip ones can do 4 bit transfers
[19:23:56] <Lambda_Aurigae> try 20MHz
[19:24:01] <Xark> If you use two QSPI RAMs, it is *almost* like a parallel interface (8-bits at once). :)
[19:24:08] <Tachyon`> 20 how? the chip is only 16
[19:24:11] <Lambda_Aurigae> nop
[19:24:13] <Lambda_Aurigae> nope.
[19:24:16] <Lambda_Aurigae> the new ones are 20MHz
[19:24:45] <Tachyon`> I know my 1284s /can/ run at 20 but I'd still run them at 16 otherwise it'd be a major pain in the arse I suspect with serial timing and so on
[19:24:56] <Tachyon`> but isn't SPI speed half the clock speed?
[19:25:13] <Lambda_Aurigae> you can clock the data out at 20MHz
[19:25:13] <Xark> And supposedly they overclock to 40+Mhz ->
http://dangerousprototypes.com/docs/Logic_Pirate#Overclocking_the_serial_SRAMs
[19:25:33] <bss36504> I’m using a library (Roland Reigal’s SD/FAT lib) and inside are a bunch of structs. I have some variables of these structs defined in my main file. While I step through with my debugger, the debugger cant see them until I set a breakpoint inside one of the FAT library’s functions. Then, I can only see it while I’m in there. All these structs are passed around as pointers. The actual message from the debugger is “An invalid DIE of
[19:25:34] <bss36504> was passed to getDieFromId”. Anybody know what’s up?
[19:25:46] <Lambda_Aurigae> setup to read the memory out sequentially, you can feed it a 20MHz clock and get the data out 4 bits at a tick at 20MHz ticks.
[19:26:14] <Tachyon`> ooh, that's pretty nice, I'll have to have a mroe extended play instead of depending on the arduino libraries
[19:26:17] <Lambda_Aurigae> bss36504, no clue here.
[19:26:34] <Tachyon`> anyone overclocked a 1284 to 32MHz?
[19:26:38] <bss36504> It might be an issue with AS. I’m understandably irritated…
[19:26:48] <Lambda_Aurigae> I overclocked an atmega32 to 20MHz back when.
[19:27:15] <Tachyon`> I'd try it but I can't afford to lose one if it fails badly
[19:27:55] <Lambda_Aurigae> haven't had any horrible failures with that.
[19:28:06] <Lambda_Aurigae> just some peripherals not functioning properly usually.
[19:28:18] <Lambda_Aurigae> keep it from overheating though.
[19:28:32] <Tachyon`> I still have some dip40 heatsinks somewhere
[19:28:52] <bss36504> also getting “Unknown Identifer” for some other variables out of the debugger, things that are very clearly defined…
[19:28:55] * Tachyon` will have a play after sleeping
[19:29:14] <Lambda_Aurigae> bss36504, that error appears to be part of the library, not anything to do with the compiler...
[19:29:30] <Lambda_Aurigae> whatever a DIE is, it's not correctly formatted or something.
[19:29:33] <bss36504> Lambda_Aurigae: No, this is post compilation, during actual debug
[19:30:09] <bss36504> like, I have my JTAGICE3 hooked up and we’re running, and thats what the watch window says about certian variables, specifically the kind that are of the structs defined in the library
[19:30:15] <Xark> Lambda_Aurigae: I haven't had good luck overclocking 1284. Nothing close to how much the 644 can overclock.
[19:31:50] <Lambda_Aurigae> bss36504, is this an arduino sketch?
[19:32:47] <bss36504> Lambda_Aurigae: No, this is on an atmega32u4, custom project
[19:33:04] <bss36504> It seems that the debugger or debugging system doesnt like to resolve pointers.
[19:33:09] <Lambda_Aurigae> what debugger software?
[19:33:32] <Xark> Lambda_Aurigae: Supposedly if you increase voltage, it can work (I believe these people are going for ~28Mhz) ->
http://uzebox.org/forums/viewtopic.php?f=4&t=1136
[19:33:44] <bss36504> Lambda_Aurigae: the things the pointers are pointing to are global in scope, and if I watch them directly, I get what I want in the watch window. I’m using AS6.1 currently
[19:34:04] <Lambda_Aurigae> Xark, I remember the ADC and comparators not working on the overclocked atmega32...
[19:34:11] <bss36504> sorry, that was unclear: the pointers dont resolve if I watch them, the things they point at do resolve if I watch them directly
[19:34:45] <Xark> Lambda_Aurigae: Yeah, EEPROM is problematic too. The Uzebox seems to be pretty reliable with a 644 at 28Mhz.
[19:35:06] <Lambda_Aurigae> http://8515.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=139423&start=0
[19:35:11] <Lambda_Aurigae> read through that bss36504
[19:35:19] <Xark> bss36504: Are they PROGMEM pointers, perhaps?
[19:35:41] <bss36504> I dont believe in this case. I have not come across that article before, thanks
[19:36:15] <Lambda_Aurigae> it appears to be a not-uncommon issue with atmel studio debugger.
[19:37:57] <Lambda_Aurigae> those microchip serial srams are awesome...they are used in the logic shrimp and derivatives as buffer/capture memory.
[19:38:39] <Xark> Lambda_Aurigae: Yep, handy for RAM challenged MCUs. :)
[19:38:42] <Lambda_Aurigae> they literally set the address to 0x0000 then set it to read data bits sequentially then run it at whatever speed up to 20MHz and capture lots of data.
[19:39:00] <Lambda_Aurigae> and the 23LCV1024 is awesome in that it has a battery backup pin.
[19:39:19] <bss36504> Lambda_Aurigae: This is a very irritating problem, thank you for your help though
[19:39:25] <Lambda_Aurigae> only does 1 or 2 bit at a time but with minimal battery for backup it will hold the data a while.
[19:39:34] <Xark> Lambda_Aurigae: My friend used one for a 4-bit (16-color) scrollable frame buffer (on an 8051) ->
https://www.youtube.com/watch?v=6pOH1-zRuoc
[19:39:38] <Lambda_Aurigae> bss36504, I find atmel studio to be very irritating in general.
[19:39:52] <bss36504> haha is there a better debugger solution for this?
[19:40:01] <bss36504> I usually dont mind atmel studio
[19:40:06] <Lambda_Aurigae> Xark, I'm using them for 8 bit 800x600 vga generator.
[19:40:15] <Lambda_Aurigae> bss36504, gdb if you need a debugger.
[19:40:32] <bss36504> does that support hardware debugging?
[19:40:33] <Lambda_Aurigae> I've never used a debugger myself...I just know how my code acts because I wrote it.
[19:40:40] <Xark> Lambda_Aurigae: Cool. Got any pics? :)
[19:40:46] <Lambda_Aurigae> Xark, not yet...
[19:41:04] <bss36504> Lambda_Aurigae: Sure, that’s all well and nice, but sometimes things are forgotten…
[19:41:09] <Xark> Lambda_Aurigae: Hmm, so you are pushing 40Mhz, I guess too
[19:41:10] <Lambda_Aurigae> it's one of my many projects that's 3/4 functional.
[19:41:15] <Lambda_Aurigae> actually, no.
[19:41:21] <Lambda_Aurigae> I run them at 20MHz.
[19:41:23] <Lambda_Aurigae> but,
[19:41:26] <Lambda_Aurigae> interleave them.
[19:41:32] <Xark> I see.
[19:41:38] <Lambda_Aurigae> flipflop toggling between the two.
[19:41:55] <Lambda_Aurigae> with the clock for the flipflop running off of a 40MHz can oscillator.
[19:42:36] <Lambda_Aurigae> this also gives me enough memory for the full 800x600 frame plus a bit extra so I can do vertical scrolling.
[19:42:47] <Xark> Neat.
[19:43:20] <Lambda_Aurigae> eventually, hopefully, it will also be double buffered.
[19:43:41] <Xark> Lambda_Aurigae: With four chips? :)
[19:49:27] <Lambda_Aurigae> for 16 color I need 4 bits so 8 chips per buffer or 16 chips total.
[19:49:49] <Lambda_Aurigae> grr
[19:49:52] <Lambda_Aurigae> I mean,
[19:49:55] <Lambda_Aurigae> 4 chips per buffer
[19:50:01] <Lambda_Aurigae> and 8 total.
[19:50:14] <Lambda_Aurigae> 8 chips per buffer gives me 256 color.
[19:50:30] <Lambda_Aurigae> first iteration is only 4 bit color.
[19:50:34] <Lambda_Aurigae> or 16 color.
[19:51:06] <Lambda_Aurigae> doing it on a solderless breadboard makes for some interesting effects
[19:51:11] <Xark> At some point parallel SRAM starts looking good. :)
[19:51:13] <Lambda_Aurigae> specially when the clock lines get noisy.
[19:51:46] <Lambda_Aurigae> I can go 4bit mode on them but then I'm limited in my scrolling buffers dramatically.
[19:52:52] <Lambda_Aurigae> it is possible to run them in 4 bit mode, 2 chips per buffer but then I don't have a full screen of scroll.
[19:52:56] <Xark> Yeah, I have done VGA on breadboard and it is a bit noisy. Here are some pics from a 1KB 8051 running at 40Mhz (doing character graphics).
https://imgur.com/a/Jtr2C#2
[19:53:33] * Xark notes it used odd scanlines to decode characters into single scan line buffer that was scanned out on even lines. :)
[19:53:49] <Lambda_Aurigae> using the hardware SPI is another way to go generating video on an AVR too.
[19:54:47] <Xark> Lambda_Aurigae: Yep. I have a different technique that leaves SPI free (so you can do Ethernet during video etc.)->
https://imgur.com/a/JO4Cq
[19:55:22] <Lambda_Aurigae> yeah...I want full 800x600 vga graphical, not just text.
[19:56:28] <Xark> Lambda_Aurigae: Yeah, that is not easy to do with just AVR memory. Frame buffer in 2K is disappointing. :) I have 256 characters with 128 in RAM (so redefinable). Allows "sprites" etc.
[19:56:35] <Lambda_Aurigae> and I already have my ELO 14 inch touchscreen giving me usable output from the resistive touch system.
[19:58:27] <Lambda_Aurigae> first gen ELO flatpanel touchscreen...heavy bugger..but serial interface.
[19:58:36] <Lambda_Aurigae> so great for microcontroller work.
[20:01:05] <Xark> Lambda_Aurigae: I am not familiar with those. I recently got a 7" one (with SSD1963 controller).
http://www.amazon.com/SainSmart-inch-Display-Arduino-MEGA/dp/B00JUZ4VXS (notes he only paid $49...)
[20:02:03] <Xark> I am going to use it with an FPGA (so 16-bit parallel is fine - and should be reasonably fast).
[20:02:44] <Lambda_Aurigae> got mine free.
[20:03:00] <Lambda_Aurigae> company was upgrading to bigger touchscreens and it was to be tossed out.
[20:04:06] <Xark> Sweet.
[20:04:21] <Lambda_Aurigae> hmm..maybe it's 15 inch.
[20:04:32] <Lambda_Aurigae> http://www.ebay.com/itm/ELO-ET1527L-8SWC-1-15-Serial-VGA-Touchscreen-LCD-Monitor-/360913798746
[20:04:36] <Lambda_Aurigae> looks a lot like that.
[20:05:15] <Lambda_Aurigae> ELO used to be the top of the line in touchscreen units.
[20:16:56] <myself> used to be?
[20:17:06] <Lambda_Aurigae> maybe still are.
[20:17:13] <Lambda_Aurigae> I haven't looked them over in years.
[21:17:39] <sirpatrick> How would you read data from a certain address over SPI? I understand how a simple transfer works, but I don't understand how you can transfer form a particular register
[21:18:15] <bss36504> based on the chip youre talking to, you probably send some sort of command+address packet then shift in extra 0s or Fs to clock out the reply
[21:20:15] <sirpatrick> Here is what the documentation says about SPI: "The first send byte defines both the mode and the address byte."
[21:20:47] <sirpatrick> I am just confused how the byte should be structured to have both the mode and address
[21:21:06] <bss36504> What chip are you talking to?
[21:21:39] <sirpatrick> MFRC522
[21:21:45] <sirpatrick> \
http://www.nxp.com/documents/data_sheet/MFRC522.pdf
[21:23:49] <bss36504> Look at 8.1.2.1: If you send the first address (address 0 in the datasheet), the first recived byte is a dont care. you sending address 1 on the next transmission pushes the address 0 data out of the slave
[21:25:15] <bss36504> If you want to read a single address, send something like <Address of register>, <XXXXXXX0> then read whats in SPDR after sending the <XXXXXXX0> byte
[21:26:23] <sirpatrick> ok
[21:27:54] <bss36504> sirpatrick: Does that make sense/help?
[21:28:18] <sirpatrick> bss36504: Yep. I am just going to have to play with it some more
[21:28:21] <sirpatrick> Thank you for your help
[21:28:29] <bss36504> No problem
[21:35:56] <sirpatrick> bss36504: I found some example code and have a question. Do you know where 0x7e and 0x80 come from in this snippet?
http://pastebin.com/xSyF4HEn
[21:37:11] <sirpatrick> can't find those constants in the documentation
[21:37:41] <bss36504> it takes your address, shifts is one bit to the left, clears bit 0 of the resultant number, and sets bit 7 of that number. Its to comply with the address format spec in 8.1.2.3
[21:38:07] <sirpatrick> Ah!
[21:38:10] <sirpatrick> Thank you
[21:38:31] <bss36504> no problem
[21:41:31] <bss36504> abcminiuser: Your stupid yakety sax got me the other day :P
[21:41:50] <bss36504> Forgot I had my headphones on really loud, no music going at the time
[21:45:06] <bss36504> wow, what are the odds, it literally just got me again.
[21:46:31] <abcminiuser> Bahahaha
[21:46:43] <abcminiuser> There's an option to turn it off...