Back
[01:43:27] <Haohmaru> is it a bad idea to use a 74hc595 SIPO for a bunch of SPI slaveselects?
[02:03:04] <Xark> Haohmaru: I would think that would work well.
[02:13:27] <Haohmaru> i wonder if it could be a problem with some SPI devices like EEPROMs.. where there is this thing where you can write multiple bytes at once by just holding the CS pin low for additional bytes
[02:14:03] <Haohmaru> what if you're unable to bring the CS pin up fast enough (due to the SIPO) and the EEPROM decides you want to write one more byte?
[02:25:47] <Xark> Haohmaru: I assume you need more than just CS (like clock etc.)?
[02:26:57] <Xark> On AVR I really doubt it will be an issue (unless you have a really strange "SPI" EEPROM).
[02:48:00] <Haohmaru> Xark i got 4 SPI slaves on one SPI, and i happen to use 2 SIPOs, the second of which has 7 free pins
[02:48:23] <Haohmaru> now, i'd need 4 slaveselect pins, but i was wondering if i could use 4 of the pins from the SIPO
[03:00:43] <Xark> Haohmaru: In theory you can get arbitrarily complex. As long as only one CS is selected (LOW) when you send+receive next byte (and start clocking SPI).
[03:16:27] <Haohmaru> ah, right.. the slave won't send another byte unless i "clock" another byte (send garbage byte out)
[03:16:53] <Haohmaru> so it won't matter if my slave select pin is low for an additional amount of time
[03:16:56] <Haohmaru> correct?
[07:02:49] <eballetbo> hi all! anyone with experience with the PDI protocol ?
[07:03:05] <megal0maniac> Haohmaru: Correct. Your master is in control of the clock and nothing can be received if the clock is not ticking
[07:03:53] <megal0maniac> Typically devices will respond with the status register or similar by default when they receive a null byte (assuming they haven't received another command which is sitting in the buffer)
[07:04:05] <megal0maniac> eballetbo: "It just works" (tm)
[07:24:36] <RikusW> eballetbo: I've used it once or twice
[07:24:38] <RikusW> hi megal0maniac
[07:25:12] <RikusW> eballetbo: just to see if my dragon actually works with it, though older xmega pdi don't
[07:31:40] <megal0maniac> Hey, RikusW !
[07:39:33] <twnqx> wow
[07:39:40] <twnqx> haven't seen you two in ages
[07:42:07] <RikusW> I've been busy during the day and online only evenings lately (gmt+2)
[07:42:18] <RikusW> been looking at
http://www.telkom.co.za/sites/business/smme/productsandservices/datanetworks/spacestream/&productname=SpaceStream%20Home%20%28SSH%29
[07:42:49] <RikusW> though the stupid site doesn't give any prices or actual usefull info on how to connect the devices
[07:42:59] <RikusW> its already being used for VoIP
[07:46:39] <twnqx> i'm in your timezone, just some thousand km north :P
[07:47:03] <RikusW> where in eu again ?
[07:47:15] <twnqx> .de
[07:47:22] <twnqx> germany :P
[07:47:39] <RikusW> I know .de at least. I'm .za ;)
[07:47:59] <twnqx> yeah, i know, just didn't notice you chatting recently
[07:50:34] <megal0maniac> Aw, it's like a big happy reunion :P
[07:50:39] <megal0maniac> Tom_itx: get over here
[07:51:26] * RikusW got a geforce 9800 gtx to troubleshoot
[07:51:43] <RikusW> I'm not sure if its even possible to fix...
[07:51:50] <megal0maniac> Reball!
[07:52:17] <megal0maniac> Probably uses rohs stuff
[07:52:23] <RikusW> got it from a it guy who said it simply doesn't work...
[07:52:37] <RikusW> and it seems oldish
[07:52:51] <megal0maniac> Yeah, they are old
[07:52:52] <RikusW> its RoHS alright
[07:53:18] <RikusW> I've soldered plenty of RoHS PC power supplies
[07:53:34] <RikusW> I usually apply a bit of lead solder to get it to melt easier
[07:54:00] <RikusW> but its a pita if the joint is connected to a large heatsink...
[07:54:22] * RikusW prefers SnPb solder
[07:55:04] * twnqx doesn't really care
[08:01:16] * megal0maniac glues wires together
[08:08:56] * Haohmaru twists wires together
[08:14:43] <RikusW> ppp
[08:14:48] <RikusW> wrong window...
[08:23:37] <eballetbo> RikusW, megal0maniac, i'm trying to implement a PDI programmer using a beaglebone black and his pru (programmable real time unit) but i've some problems
[08:24:21] <eballetbo> the first thing i'm trying to solve is know if can see if the xmega enters in programming mode but i don't see how to check this, any clue?
[08:57:00] <bss36504> eballetbo: Isnt PDI proprietary?
[09:00:06] <eballetbo> bss36504: afaik is propietary from atmel but public
[09:01:31] <bss36504> eballetbo: It just seems that if you cant find info on how to detect if the part is in prog mode, then there likely isnt accessable documentation on that. And that, to me, seems like a critical part of the spec. However, a hack around it, or perhaps not a hack, would be to read the chip ID. That may very well be how atmel does it.
[09:01:58] <bss36504> And just for clarity, are you working on PDI physical layer or via JTAG or something into the PDI controller?
[09:02:26] <bss36504> Skimming through the XmegaAU spec, the PDI section does have quite a bit of info on the protocol.
[09:03:11] <eballetbo> bss36504: I'm implementing a pdi driver, as explained here
[09:03:11] <megal0maniac> http://www.atmel.com/images/doc8282.pdf
[09:03:16] <eballetbo> http://www.atmel.com/images/doc8282.pdf
[09:03:21] <megal0maniac> Too slow ;)
[09:03:26] <eballetbo> heh
[09:04:02] <eballetbo> the idea is program an xmega in-circuit using a chip similar to the one used in the beaglebone black
[09:05:49] <eballetbo> from doc I can't see if there is a register or something that indicates the xmega is in programming mode for that reason I asked here, as to enter in programming mode we need to do a reset and send some dummy cycles, I'm able to send a command but looks is not responding
[09:07:28] <bss36504> "The sequence of entering external programming is as following:
[09:07:29] <bss36504> 1. Load the PDI RESET register with the Reset Signature (0x59).
[09:07:29] <bss36504> 2. Load the correct NVM key in the PDI.
[09:07:29] <bss36504> 3. Poll NVMEN in the PDI Status Register (PDI STATUS) until NVMEN is set.
[09:07:29] <bss36504> When the NVMEN bit in the PDI STATUS register is set the NVM interface is active
[09:07:29] <bss36504> from the PDI."
[09:08:43] <bss36504> Section 3.3 btw
[09:12:04] <eballetbo> yes, the problem i see is reading PDI status register, or NVMEN is not set or i'm not reading correctly the status register
[09:14:14] <bss36504> eballetbo: That is a conundrum. Do you have the atmel source code mentioned in the document?
[09:17:47] <eballetbo> bss36504: yes i've this code and i adapted to run in the beaglebone black pru, if you want i can share it, my BBB is connected to a PDI xmega connector, something like this ...
[09:17:48] <eballetbo> http://pastebin.com/W8nRUMPP
[13:30:05] <Martin90> Hello, how to restore completly messed fuses ?
[13:30:18] <Martin90> I accidently made typo ;/
[13:31:09] <Martin90> Now i have " error: programm enable: target doesn't answer. 1"
[13:33:55] <bss36504> Depends on what you did, but you may need HVPP with a dragon
[13:34:17] <Martin90> it's a programmer ?
[13:34:34] <Martin90> basicly I set LFUSE to 201 ;/
[13:34:41] <Martin90> 201 dcimal
[13:34:54] <Martin90> which means I set clock which doesn't exist
[13:35:09] <bss36504> What clock mode is that?
[13:35:44] <bss36504> which part number, by the way
[13:35:45] <bss36504> ?
[13:35:50] <Martin90> Atmega16A
[13:36:10] <Martin90> CKSEL3:1 -> I set to 100
[13:36:32] <Martin90> CKOPT i HFUSE i set to 0
[13:36:49] <Hexum064> Hey all. Now typing from my phone. Thanks to our network guys at work
[13:37:02] <Martin90> so if I am not mistaken I set clock source which doesn't exist ?
[13:37:03] <bss36504> Hexum064: Thats unfortunate
[13:37:22] <bss36504> Martin90: Hang on, I need the ds. I dont know this avr as well...
[13:37:31] <Martin90> ok ;)
[13:37:39] <Martin90> bass..., do you have any idea ?
[13:37:59] <bss36504> http://www.engbedded.com/fusecalc/
[13:38:16] <Hexum064> Wanted to check on some possible pitfalls of my design. I plan to have 24 mcus attached to an 8bit buss controlled by one master mcu. Frequency is about 1mhz.
[13:38:17] <bss36504> according to that, you'd have Ext. RC osc. 3.0Mhz - 8.0Mhz
[13:38:31] <bss36504> Hexum064: 24!
[13:38:44] <bss36504> that wont be annoying to make firmware changes to :)
[13:38:54] <Hexum064> Is there something I should watch out for? Attenuation? Echos?
[13:39:08] <bss36504> Hexum064: what kind of distance? Probably not an issue though
[13:39:12] <Martin90> I set both Hight abnd low fuse to 0xC9
[13:39:30] <Hexum064> Small. All same pcb
[13:39:49] <Martin90> bss36504, so can I restore it ?
[13:40:05] <bss36504> Martin90: Looks to be set for a low freq external crystal.
[13:40:07] <bss36504> so maybe.
[13:40:13] <bss36504> but you might need that crystal
[13:40:28] <Martin90> sure I have 8 Mhz
[13:40:36] <Martin90> but the question is is 8 mhz right ?
[13:40:40] <bss36504> I dont remember what qualifies as "low frequency" but a ttl clock on XTAL0 might work too.
[13:41:23] <bss36504> Hexum064: that will probably be fine as long as your clock/data traces werent routed willy nilly. If you made them short and precise, they will probably be fine at 1Mhz.
[13:43:08] <Martin90> bss36504, this website shows it wrong
[13:43:22] <Hexum064> Ok. Thank you. I have not finished the design yet, so I will keep that in mind. Anything else you'd suggest for the design of the data buss?,
[13:43:53] <Martin90> 0xC9 = 201 = 11001001
[13:44:12] <Martin90> so CKSEL1 = CKSEL = 0
[13:44:19] <bss36504> Hexum064: bigger traces are probably going to be better. Youre nowhere near RF so it wont likely be an issue. Plus, your data is synchronous to a clock so as long as you have appropriate set up times, there shouldnt be any issues.
[13:44:27] <Martin90> that website shows CKSEL1 = CKSEL2 = 1 o.0 WRONG !
[13:45:22] <Hexum064> Great! Thanks again!
[13:45:38] <bss36504> Martin90: The table is inverted.
[13:45:45] <Martin90> ??
[13:45:46] <bss36504> 1 is unprogrammed
[13:45:50] <bss36504> 0 is programmed
[13:45:55] <bss36504> as is common with flash
[13:46:13] <bss36504> so double check that you did what you think you did, and that what you wanted to do was actually correct
[13:46:47] <Martin90> yes right
[13:46:47] <Martin90> ok
[13:47:11] <Martin90> The fact is I accidently set both fuses to 0xC9
[13:47:27] <Martin90> anyway where do you see that info that I should use low freq oscilator ?
[13:48:00] <bss36504> Using that calculator, if you enter C9 and C9 in the bottom section and hit "apply changes" it gives you the human readable version up top in the drop downs.
[13:48:36] <bss36504> I just checked with another caluclator and it matches.
[13:49:15] <Martin90> ohh ok I see
[13:49:30] <Martin90> so the question is what means ext . low freq oscilator ?
[13:50:12] <Martin90> I doubt anything will be working since I set conf which doesn't exist
[13:50:26] <Martin90> The lovest I have is 8 Mhz - ?
[13:50:31] <bss36504> Means a crystal connected to XTAL0 and XTAL1, but you'll have to consult the datasheet to see what qualifies as "Low frequency".
[13:50:32] <Martin90> lowest
[13:51:25] <Martin90> To use a 32.768kHz watch crystal as the clock source for the device, the Low-frequency Crystal Oscillator must
[13:51:25] <Martin90> be selected by setting the CKSEL Fuses to “1001”.
[13:51:47] <bss36504> the issue with clock fuse mess-ups is that it is a pain to fix them if you accidentally switch to a source you dont have the means to make.
[13:51:47] <Martin90> CKSEL Fuses to “1001” - its my current conf
[13:52:00] <bss36504> right
[13:52:28] <bss36504> so sounds like you need a 32khz crystal, or maaaaaybe you can provide a 32khz recovery clock from another micro or a function generator.
[13:53:08] <Martin90> 32.768kHz
[13:53:27] <bss36504> right
[13:53:43] <bss36504> if youre just trying the recovery clock, the exact speed likely isnt critical
[13:53:51] <bss36504> just as long as it's not too high.
[13:54:12] <Martin90> but if i plug that cristal it would work ?
[13:54:23] <bss36504> correct, it should
[13:55:04] <Martin90> hmmm, ok thank you ;)
[13:55:08] <Martin90> I have one more question
[13:55:17] <bss36504> I hope it works out. Clock fixes can be a pain
[13:55:34] <Martin90> hfuse:w:0xC9:m -U lfuse:w:0xEF:m tha is what I wanted to do
[13:56:34] <Martin90> is it right for 16 MHz cristal ?
[13:57:05] <bss36504> yes
[13:58:06] <Martin90> the reverse table logis confues me a little bit ;)
[13:58:27] <bss36504> yeah it's not the easiest. Use the drop downs
[13:58:51] <Martin90> drop downs ?
[13:58:57] <Martin90> ahh I see
[13:59:03] <bss36504> on that fuse calculaor page
[13:59:15] <Martin90> yes I noticed
[14:00:24] <Martin90> thank for your help, I am going to buy that low-freq oscilator and I let you know if it helped
[14:04:49] <bss36504> No problem, hope it works for you!
[14:09:13] <bss36504> I'd like to implement a speaker independant voice recognition system for about 20 words. The more embedded it is the better. Has anyone done anything like this or found an app not online on how to do it? My searches havent found much
[14:31:56] <Martin90> bass.., what you mean by the more embeeded ? :P
[15:11:34] <rogan_> hi folks, I'm a bit of a noob at programming the AVR chips. I've been playing around with a Cactus Micro Rev 2, which is an Atmega32U4 connected to an ESP8266 wifi chip
[15:11:52] <Emil_> Hi
[15:12:18] <rogan_> I've been fairly successful talking to it using the Arduino IDE, but now I want to get a little more sophisticated, and create my own USB HID interfaces
[15:12:28] <Emil_> VUSB
[15:12:30] <Emil_> Go
[15:13:01] <rogan_> to do that, the "correct" way seems to be to use LUFA, rather than the seemingly incomplete Arduino Keyboard and Mouse libraries
[15:13:32] <rogan_> I've started with the KeyboardMouse class drivers in teh LUFA examples, and hacked it around to receive the keystrokes from the ESP
[15:13:50] <rogan_> my problem is that the ESP needs a specific pin enabled to power it on
[15:13:58] <rogan_> being pin PC7
[15:14:37] <rogan_> In the Arduino IDE, all I need to do is:
[15:14:39] <rogan_> pinMode(13, OUTPUT); digitalWrite(13, HIGH);
[15:15:00] <rogan_> if I understand correctly, the equivalent low level instruction is:
[15:15:25] <rogan_> DDRC |= (1<<7);
[15:15:26] <rogan_> PORTC |= (1<<7);
[15:15:46] <rogan_> can anyone confirm that? Or alternatively, point me in the right direction?
[15:16:08] <rogan_> I reckon I have it wrong, since I'm not seeing the ESP show up on my wifi network
[15:16:26] <Emil_> Which physical pin is the pin 13 connected to?
[15:16:47] <rogan_> PC7, apparently
[15:17:24] <Emil_> PB5 more likely
[15:17:49] <Emil_> That's by the default pin configurations for the dip version
[15:18:03] <Emil_> But in any case
[15:18:08] <rogan_> http://wiki.aprbrother.com/wiki/Cactus_Micro_Rev2_Hookup_Guide details the interface betwen the 32U4 and the ESP
[15:18:08] <Emil_> Yeah
[15:18:22] <rogan_> this is not a DIP chip, it's the 44 pin SMD
[15:18:31] <Emil_> DDRx controls the registers, which are 8bit
[15:18:43] <Emil_> A better way to understand what is happening is to use the 0b macro
[15:19:05] <rogan_> I'm not familiar with that
[15:19:07] <Emil_> DDRB |= 0b10000000;
[15:19:15] <Emil_> Sorry DDRC
[15:19:24] <Emil_> PORTC |= 0b10000000;
[15:19:32] <Emil_> You can directly see which pins are toggled
[15:19:35] <rogan_> is that meaningfully different to what I had above?
[15:19:38] <Emil_> No
[15:19:45] <Emil_> But it helps in debugging
[15:19:50] <rogan_> fair enough
[15:22:24] <rogan_> Hah! I guess I hadn't properly written the hex to the board, I seem to be getting results now
[15:22:32] <rogan_> thanks for the confirmation ;-)
[15:22:37] <Emil_> Ah
[15:22:38] <rogan_> tha tI Was doing it right
[15:22:40] <Emil_> It's PB7
[15:22:42] <Emil_> Not PC7
[15:22:51] <Emil_> http://www.atmel.com/Images/Atmel-7766-8-bit-AVR-ATmega16U4-32U4_Datasheet.pdf
[15:23:08] <Emil_> wAIT
[15:23:09] <Emil_> What no
[15:23:11] <Emil_> hold on
[15:23:12] <rogan_> Are you sure? Because the ESP is powered up currently, and I was only enabling PC7
[15:23:35] <Emil_> No
[15:23:41] <Emil_> I'll just be silent :D
[15:24:04] <rogan_> heh
[15:24:12] <rogan_> I was looking at
https://www.arduino.cc/en/Hacking/PinMapping32u4
[15:24:21] <rogan_> pin 32
[15:26:09] <rogan_> Perhaps I can ask a different question, while I'm here
[15:26:24] <rogan_> what are the limitations on creating different devices at one time?
[15:26:33] <Emil_> ?
[15:26:44] <rogan_> Ideally, I'd like to have a HID (Keyboard and Mouse), as well as a Mass Storage device
[15:26:55] <rogan_> and possibly a Serial port for debugging ;-)
[15:28:04] <rogan_> my current, horribly inefficient workflow is to flash the 32U4 with a serial relay firmware, which purely relays packets to the ESP
[15:28:16] <rogan_> I can then interact with the NodeMCU firmware on the ESP
[15:29:01] <rogan_> once I'm happy with what that is doing, I can then try to flash the KeyboardMouse firmware to the 32U4, and send instructions to it via the network, using the ESP as a wifi to serial converter
[15:29:08] <rogan_> but debugging that is a bit of a pain
[16:05:42] <ali1234> isn't VUSB inappropriate for the 32u4 given it has hardware USB?
[16:06:23] <ali1234> shouldn't you use LUFA with those instead?
[16:08:07] <ali1234> rogan_: you can certainly have one physical piece of hardware act as more than one type of device at the same time
[16:08:28] <ali1234> it's just a question of whether you've got enough resources in the chip to do what you want
[16:10:50] <ali1234> also, don't trust any arduino docs when it comes to pin mapping documentation, their stuff is riddled with errors for some reason
[16:10:56] <ali1234> always check the datasheets
[16:11:51] <Emil_> ali1234: I didn't know the platform before I said VUSB
[16:14:35] <ali1234> rogan_: so this is what you want to pay attention to:
https://github.com/AprilBrother/cactus-micro-r2/blob/master/schematic/cactus-micro-rev2.pdf
[16:20:31] <ali1234> although i'm somewhat confused by that schematic because ESP-3 is a 14 pin device but the ESP8266 is a 32 pin device. and there's nothing else on the schematic that could be it
[16:23:42] <ali1234> oh wait, i see, it's a stacked board configuration
[16:31:28] <rogan_> ali1234: yes, I am using LUFA, not VUSB
[16:31:36] <rogan_> the VUSB comment was from someone else
[16:32:33] <rogan_> so the device I'm building is a kind of a "BadUSB" type device
[16:32:47] <rogan_> the idea is that it looks like a flash drive, so you plug it in to your computer
[16:33:08] <rogan_> and it shows up as a Mass Storage Device (even if only a *really* tiny one!)
[16:33:43] <rogan_> but it also has the ability to report keystrokes and mouse movements like a regular keyboard
[16:34:12] <rogan_> precisely what those keystrokes will be is up to the person connecting to it via wifi
[16:35:30] <rogan_> while this could be seen as a purely malicious device, another use for it would be a remote keyboard mouse for headless devices
[16:35:48] <rogan_> or at least devices that have a screen, but no keyboard
[16:36:17] <rogan_> e.g. kiosks, display-only monitors, etc
[16:36:40] <rogan_> that might need a keyboard at some point, but do not have anywhere to actually store one
[16:46:05] <Emil_> rogan_: you can have it look any size you want
[16:47:15] <rogan_> Emil_: well, size is one thing, actually having a meaningful file system on it is something else ;-)
[16:48:25] <rogan_> so far, I have not yet added an SD card to the device, although that would be an interesting option
[17:27:59] <rogan_> ok, so I'm clearlly missing something
[17:28:28] <rogan_> Does anyone have an example of how to do an *actual* not virtual serial to usb CDC interface with LUFA?
[17:28:45] <rogan_> i.e. read from the UART, pass the data to the USB serial interface, and vice versa?
[17:30:02] <rogan_> ignore me, I see it in ./Projects/USBtoSerial/USBtoSerial.c
[18:23:01] <balrog-k1n> hi, does someone know off-hand if the atmega2560 assembly is mostly a superset of atmega328's assembly? are the timings about the same too?
[18:23:37] <Lambda_Aurigae> they should be identical.
[18:23:54] <Lambda_Aurigae> might have extended registers for the larger memory size.
[18:24:06] <Lambda_Aurigae> but the assembly language for AVRs is all the same.
[18:24:17] <balrog-k1n> great, thanks
[18:24:24] <Lambda_Aurigae> from attiny through atmega.
[18:25:04] <Lambda_Aurigae> I think the atmega might have a few more than the attiny but those are for things the atmega has hardware wise compared to the attiny.
[18:25:13] <balrog-k1n> the code in question compiles and kinda works, but not 100%, seems like maybe a timing difference, it's one of those RGB LED drivers which use strictly timed loops
[18:25:45] <balrog-k1n> i wonder if maybe on of the two-cycle atmega328p insns is a single cycle on an atmega2560
[18:25:56] <Lambda_Aurigae> commands should be the same.
[18:26:22] <Lambda_Aurigae> there is one document for all of the avr instruction set.
[18:26:47] <Lambda_Aurigae> you could be running into issues with the larger memory.