Back
[07:04:45] <beaky> hello
[07:16:59] <beaky> has anyone used the attiny85v
[07:17:19] <beaky> i want to try using them for spi with my ATmega328p
[07:17:30] <beaky> my ATmega328p will drive them as master
[07:17:48] <beaky> but it seems the tiny85 doesn't have spi; it has something called "USI" instead :/
[07:18:33] <theBear> read the relevant part of the datasheet, it explains what usi does, just like 10 years ago when the new datasheets explained what usart can do
[07:19:35] <megal0maniac_afk> beaky: I explained USI to you a week ago
[07:20:02] <beaky> ah
[07:20:17] <beaky> maybe i was afk :(
[07:20:33] <megal0maniac_afk> Probably
[07:20:47] <megal0maniac_afk> "oh man usi is probably like bit-banging uart" is what you said
[07:22:27] <beaky> so it is like bitbanging uart?
[07:22:42] <beaky> hardware-accelerated bitbanging
[07:22:58] <megal0maniac_afk> "USI is a configurable shift register, in essence. So you can do SPI, UART or I2C with it. Takes some of the load off the CPU, and some of the pain out of bit bashing, but isn't done purely in hardware like a true USART/SPI/I2C module"
[07:23:16] <beaky> ah
[07:23:21] <megal0maniac_afk> bit bashing (TM)
[07:23:55] <beaky> wow i have to try this usi thing
[07:24:02] <megal0maniac_afk> http://www.atmel.com/images/doc2582.pdf
[07:24:18] <beaky> the tiny is awesome it can probably do anything the ATmega328p can
[07:24:30] <megal0maniac_afk> Not really
[07:24:43] <megal0maniac_afk> USI is slower, and it can't be more than one thing at a time
[07:24:49] <megal0maniac_afk> And uses more CPU overhead
[07:24:52] <beaky> ah :(
[07:24:56] <megal0maniac_afk> And they have far less RAM
[07:24:59] <megal0maniac_afk> And flash
[07:25:01] <megal0maniac_afk> And pins
[07:25:13] <beaky> 6 pins ought to be enough for anybody
[07:25:20] <megal0maniac_afk> Right...
[07:25:45] <beaky> 8k flash is plenty :D
[07:25:49] <megal0maniac_afk> By "more than one thing at a time", I mean doing I2C and UART and SPI simultaneously
[07:26:57] <beaky> so there's some software overhead i have to do if i want to e.g. take some i2c data from a sensor, and some spi data from some other slave, then use uart to send it to my terminal
[07:27:13] <megal0maniac_afk> Lots
[07:27:31] <beaky> oh well thats probably like only 100k of my 1 million iinstructions per second :D
[07:27:34] <megal0maniac_afk> Because you need to reconfigure the USI each time you switch modes
[07:28:15] <theBear> as i recall, even the usart was less 'hard' than the old 90s series uarts
[07:29:34] <beaky> I love my tiny avr; its a microcontroller that demonstrates that its not the size thats matters its how its used. Maybe using it more in projects will improve my design abilities
[07:30:03] <megal0maniac_afk> beaky: You sure do love a lot of things
[07:30:43] <megal0maniac_afk> Atmel has appnotes for using the USI as I2C master, I2C slave, SPI master and half-duplex UART. Read them
[07:30:59] <megal0maniac_afk> You might end up loving USI too
[07:31:02] <megal0maniac_afk> :)
[07:39:41] <theBear> heh, /me wonders if that was a phallic triggered subconscious statement there
[07:58:03] <tzanger> usi?
[07:58:33] <tzanger> is that some kind of i2c/spi/usart peripheral?
[08:00:19] <twnqx> universal serial interface or something like that
[08:00:59] <theBear> it's the 'new' version of usart on some new (or maybe just smaller) avrs
[08:07:14] <megal0maniac_afk> tzanger: Configurable shift register, to put it simply
[08:07:34] <megal0maniac_afk> Used for SPI, I2C or half-duplex UART on tiny devices
[08:35:58] <carabia> good afternoon
[09:06:49] <rue_house> its morning tho
[09:59:37] <beaky> hello
[10:08:10] <megal0maniac_afk> Stupid server. Sometimes it suddenly can't resolve anything. Did I miss anything exciting?
[10:08:14] <megal0maniac_afk> zlog
[10:09:01] <megal0maniac_afk> Ah. Apparently not
[10:59:52] <stefanct> hey guys. i wonder about the UCSR1D register of the U4 series... it is described in the usart section of the data sheet, but is missing in the register summary. and it is not defined by avr-libc.
[11:01:13] <stefanct> i guess it is just a bug in the summary (and hence in avr-libc)... but i could not really find any hard data regarding it, and id like to not test it myself :)
[11:33:28] <CeruleanSky> stefanct:
https://www.assembla.com/code/paranoidstudio/git/changesets/4e3cb5002545fc84918c08ef0e579a1dd9bdcebb is the only thing I saw
[11:33:53] <CeruleanSky> seems like on some chips it was used to disable flow control?
[11:34:40] <stefanct> yes, it contains two bits to enable hw flow control (rts/cts)
[11:36:47] <stefanct> cf atmega16u4/32u4 "18.10.5 USART Control and Status Register n D– UCSRnD" (sic :)
[11:38:01] <CeruleanSky> according to the changelog of lufa it isn't used, and lufa knows their atmega since I believe the coder works at atmel
[11:43:53] <N1njAway> Ahhhhhhhhhhhh
[11:43:57] <N1njAway> AHHHHHHHHHhh
[11:43:59] <N1njAway> Atmel
[11:44:05] <N1njAway> Make ASF work correctly for C++
[11:44:12] <N1njAway> And happy Monday to y'all
[11:45:25] <RikusW> CeruleanSky: he did LUFA before working at Atmel
[11:45:50] <CeruleanSky> that commit was a couple months ago
[11:45:54] <beaky> what makes avr so special compared to other uC families
[11:46:05] <CeruleanSky> not sure when he starting working there though
[11:46:25] <N1njAway> CeruleanSky: And continues to develop it whilst working for Atmel. He's usually on here - I'm actually surprised he's not logged in at the moment.
[11:49:55] <stefanct> aka abcminiuser... he is not always around
[11:51:45] <stefanct> CeruleanSky: can you please be more specific regarding the changelog?
[11:52:44] <CeruleanSky> stefanct: the commit changelog/message
[11:52:59] <CeruleanSky> "Removed use of UCSR1D since atmega16u4 and 32u4 does not have it (error in the compiler but it's not used anyway)."
[11:56:21] <megal0maniac_afk> That's pretty interesting
[11:56:33] <stefanct> uh... that commit is not from lufa
[11:56:37] <stefanct> and not from dean camera
[11:56:45] <stefanct> https://www.assembla.com/code/paranoidstudio/git/changesets/4e3cb5002545fc84918c08ef0e579a1dd9bdcebb
[11:57:21] <stefanct> but asking dean is probably an excellent idea, ill wait for him
[11:58:21] <megal0maniac_afk> Error 1 'UCSR1D' undeclared (first use in this function) C:\Users\Michael\Documents\Atmel Studio\6.1\m164test\m164test\m164test.c 16 2 m164test
[11:58:34] <megal0maniac_afk> Eugh, sorry. That was gross
[11:59:38] <megal0maniac_afk> But it isn't even defined in the headers for Atmel Studio, which makes sense since it uses GCC
[12:01:21] <megal0maniac_afk> If I had to guess, I'd say it's at 0xCB
[12:03:28] <RikusW> the DIDR register is only inthe ds and not the header too...
[12:03:39] <RikusW> don't know if its fixed by now
[12:04:07] <RikusW> megal0maniac_afk: I put the latest blaster and jtag fw on my site
[12:04:17] <megal0maniac_afk> You can replace it with _SFR_MEM8(0xCB)
[12:04:25] <megal0maniac_afk> (Assuming that's the correct address)
[12:04:30] <megal0maniac_afk> RikusW: Awesome :)
[12:04:40] <RikusW> jtag should be the same as you have
[12:04:51] <RikusW> blaster is a bit newer
[12:05:13] <RikusW> in the blaster change to 16MHz to make it a bit faster ;)
[12:05:34] <RikusW> (just uncomment 1 line)
[12:05:54] <megal0maniac_afk> Now...
[12:06:00] <megal0maniac_afk> Time to do Xilinx :D
[12:06:27] <RikusW> get me the protocol specs for PC to adapter..
[12:07:06] <megal0maniac_afk> Ooh...
[12:07:29] <RikusW> if its as simple as Altera it will be easy to do
[12:08:02] <RikusW> http://www.edn.com/design/test-and-measurement/4423158/Precision-capacitance-meter
[12:16:08] <megal0maniac_afk> RikusW: It's FT2232 based
[12:16:31] <RikusW> the official cable ?
[12:17:07] <RikusW> did you open one ? ;)
[12:18:27] <megal0maniac_afk> No, I'm just reading about it :0
[12:18:30] <megal0maniac_afk> * :)
[12:20:56] <RikusW> see if you can find the lowlevel usb protocol used by the FT2232
[12:21:16] <RikusW> it seems the libftdi guys must have it
[12:21:32] <RikusW> maybe your google skills is better than mine :-P
[12:21:40] <RikusW> I couldn't find it yet
[12:43:11] <megal0maniac_afk> "Xilinx software is designed to work with Xilinx communication cables
[12:43:11] <megal0maniac_afk> and some selected 3rd party equipment. Our software is tightly
[12:43:11] <megal0maniac_afk> coupled to the communication hardware and we do not provide general
[12:43:12] <megal0maniac_afk> access to the driver/software APIs."
[12:45:24] <carabia> awesome
[12:46:32] <megal0maniac_afk> carabia: I believe that's the opposite of what this is
[12:47:54] <RikusW> Altera got the same policy....
[12:48:09] <RikusW> megal0maniac_afk: do you have Xilinx adapters at uni ?
[12:49:17] <megal0maniac_afk> RikusW: No, unfortunately. No access to one
[12:49:28] <megal0maniac_afk> Maybe I'll bug some lecturers
[12:50:07] <carabia> i love proprietary stuff
[12:50:57] <megal0maniac_afk> Found a clone with lots of details, but they use a CPLD like the original, and use a xilinx utility to flash it with the original firmware
[12:51:04] <megal0maniac_afk> Nothing about protocol
[12:52:49] <megal0maniac_afk> carabia: I'm assuming that you're being sarcastic, but it really is more satisfying when you get it working when you're not supposed to :)
[12:53:10] <carabia> that is true
[12:53:20] <carabia> proprietary means dollahs tho!
[12:53:36] <carabia> holla holla get dolla
[12:54:00] <RikusW> indeed :-D
[12:54:16] <Casper> megal0maniac_afk: so they really cloned the chip
[12:54:34] <RikusW> megal0maniac_afk: site address ?
[12:55:49] <megal0maniac_afk> RikusW: It would be easy to make a small PC app to program bitstreams, since it's standard JTAG and the programming protocol is documented. But to mimic the platform USB cable and use it for debugging, I don't think it's possible
[12:56:30] <megal0maniac_afk> Casper: No, they cloned the programmer by using the same chips. So the xilinx software is happy to "upgrade" the firmware and you have a 100% working clone
[12:57:56] <RikusW> why have a cpld when ft2232 can bitbang jtag....
[12:58:35] <N1njaneer> Cost on the Xilinx platform cable isn't that bad for an authentic Xilinx device. :)
[12:58:50] <Casper> megal0maniac_afk: not even need to have a bootloader on it or anything to verify the integrity?
[13:00:26] <megal0maniac_afk> I'm not sure where I read that, but now it seems they use cypress fx2lp for USB and a CPLD
[13:00:30] <megal0maniac_afk> Casper: Don't think so
[13:00:47] <megal0maniac_afk> N1njaneer: There are digilent ones for $50 and they're much smaller
[13:00:56] <megal0maniac_afk> Supported by Xilinx as well
[13:01:30] <Casper> megal0maniac_afk: kinda a fail from them then
[13:02:00] <Casper> I'ld have expected them to factory flash a bootloader, secure it, then use it to upload the firmware
[13:04:10] <stefanct> hi abcminiuser, can i bug you about a datasheet inconsistency of the u4 series?
[13:04:40] <abcminiuser> Probably can't fix it, but sure
[13:04:52] <RikusW> Ahttp://rmdir.de/~michael/xilinx/
[13:04:56] <RikusW> -A
[13:05:18] <RikusW> I can't quite figure out the source... not yet anyways
[13:07:18] <stefanct> abcminiuser: on the u2 there is an UCSR1D (0xCB) that controls hardware flow control of the usart. on the u4 the register is explained too in the usart section, but in the register summary at the end it is missing (and 0xCB is reserved)
[13:07:50] <stefanct> abcminiuser: UCSR1D is also not defined in avr-libc... that's why i have noticed it at all, porting my code to the u4
[13:08:14] <abcminiuser> I don't think it has hardware flow control
[13:08:24] <abcminiuser> Probably removed from the module from the U7
[13:08:25] <RikusW> 32u2 does
[13:08:42] <megal0maniac_afk> stefanct: the 0xCB was a guess. It's a reserved address, but 0xCA is UCSR1C and 0xC9 was UCSR1B etc
[13:09:09] <stefanct> megal0maniac_afk: it is quite obvious if you look at the u2 datasheet... i was not quoting you, it was my own guess (too ;)
[13:09:34] <megal0maniac_afk> All good :)
[13:10:02] <RikusW> its documented as CB in u2 ds
[13:10:15] <reddie> Possible to program an atmega328 that has fuses set for 5v with a 3.3V isp programmer?
[13:10:30] <Tom_itx> no reason not
[13:10:58] <Tom_itx> i've programmed them down to 1.75v
[13:11:06] <Tom_itx> not that i'm recomending it
[13:11:24] <reddie> Ok, cool, thanks.
[13:12:09] <carabia> i need someone to tell me a default shortcut in some program with f10
[13:12:10] <Tom_itx> abcminiuser, at what point do the bits quite flashing?
[13:12:15] <Tom_itx> quit*
[13:12:15] <stefanct> abcminiuser: ok, so to sum up you think the register map in the u4 datasheet and avr-libc are correct. does it make sense to report the bug in the usart section (explaining UCSRnD) in the datasheet and if so where?
[13:12:16] <carabia> is there one in browsers?
[13:12:41] <megal0maniac_afk> RikusW: I think that the linux utils might program xilinx with the altera firmware
[13:12:42] <carabia> nvm found one
[13:12:59] <Tom_itx> carabia i was ignoring you anyway
[13:13:01] <Tom_itx> :)
[13:16:06] <abcminiuser> Tom_itx, the what now?
[13:16:21] <abcminiuser> stefanct, yes 99% sure it's a copy-paste mistake, register won't be in the device RTL
[13:16:43] <abcminiuser> As for fixing, I can file a bug but I haven't seen any movement on fixing "old" datasheets in a long long time
[13:16:45] <megal0maniac_afk> RikusW:
http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,395,922&Prod=JTAG-HS1
[13:16:54] <abcminiuser> All the techpubs resources are on newer devices to keep up
[13:17:21] <megal0maniac_afk> If I were to buy a cable, that would be the one
[13:18:12] <stefanct> abcminiuser: it's like that everywhere i guess :) thanks and sorry for the noise then
[13:18:27] <abcminiuser> No problem for me, just wish I could fix that myself
[13:18:43] <abcminiuser> Reality is we have fininite people and a trillion things to do
[13:22:45] <Tom_itx> abcminiuser, how low can you flash voltage wise before they start missing bits?
[13:22:48] <Tom_itx> was the question
[13:23:23] <megal0maniac_afk> How low can you go?
[13:23:39] <RikusW> HVPP is 5V only for some reason
[13:23:39] <Tom_itx> i've successfully done 1.75v but didn't go lower as it got to the point i couldn't see the led blink anymore
[13:24:05] <Tom_itx> just curious
[13:24:16] <megal0maniac_afk> RikusW: I have no drivers :P
[13:24:33] <RikusW> drivers ?
[13:25:37] <megal0maniac_afk> Altera Blaster
[13:25:57] <megal0maniac_afk> urjtag should be able to program a xilinx chip with the blaster firmware
[13:26:31] <RikusW> the standard FTDI FT245 drivers should work
[13:26:40] <RikusW> indeed
[13:26:49] <RikusW> no drivers required in Linux :)
[13:28:04] <megal0maniac_afk> RikusW: D2xx or VCP? (virtual com port)
[13:28:14] <RikusW> think so
[13:28:31] <megal0maniac_afk> Which one? :P
[13:28:42] <RikusW> try and see..
[13:28:52] <RikusW> D2xx first...
[13:34:28] <megal0maniac_afk> D2XX doesn't work
[13:35:26] <RikusW> Do you have Quartus for windows ?
[13:35:31] <megal0maniac_afk> Not does VCP. Probably VID/PID mismatch
[13:35:33] <RikusW> maybe its got a driver
[13:35:40] <megal0maniac_afk> RikusW: No I don't. And yes, it does :P
[13:36:12] <RikusW> edit vid/pid in inf...
[13:36:28] <megal0maniac_afk> I'll try
[13:36:29] <RikusW> the FT245 pid
[13:36:38] <megal0maniac_afk> This is the XuLA utility
http://i.imgur.com/LEyvq46.png
[13:36:50] <RikusW> or boot to Linux :-P
[13:37:07] <RikusW> urjtag can even read avr idcode :)
[13:40:44] <megal0maniac_afk> Whoo! Changed VID. PID was the same
[13:41:52] <RikusW> If you don't have Quartus what are you going to do with it ?
[13:45:02] <megal0maniac_afk> Well I figured I'd use urjtag and test it with a xilinx chip, but urjtag isn't finding the cable
[13:46:28] <RikusW> worked just fine on Linux
[13:46:41] <megal0maniac_afk> Might be a driver issue
[13:46:41] <RikusW> maybe try the other driver
[13:56:45] <megal0maniac_afk> No luck. i'm giving up for now. Got a maths test tomorrow :/
[13:57:01] <bitd> What math?
[13:57:36] <megal0maniac_afk> Integration
[13:57:49] <bitd> Nice :-D
[13:57:59] <megal0maniac_afk> For you, maybe :P
[14:00:41] <bitd> Wait, an electronics guy that doesnt enjoy math? :P
[14:02:16] <Chillance> is this really correct: #define SPI_MODE3 (SPI_MODE0_bm | SPI_MODE0_bm) ?
[14:02:43] <Chillance> found that here:
https://github.com/akafugu/Xmegaduino/blob/xmegaduino/libraries/SPI/SPI.h
[14:03:17] <RikusW> looks suspicious
[14:03:22] <bitd> Seems weird.
[14:03:27] <carabia> some arduino-stuff?
[14:04:59] <N1njaneer> Who wants to buy one of my Metric Arduino Hammers? You can use it on ANY Arduino code, and it will suddenly change back in to native AVR stuff and work correctly. :)
[14:06:37] <dabeastro> newb needs help choosing an avr. anyone care to help?
[14:08:06] <N1njaneer> dabeastro: Easy! You mainly want to choose it on the basis of what peripherals you need first, and then how much program space/ram you need second. And generally with the latter, you start on the largest device in that series, get your application working, shrink, and see if you can step down to a smaller part. :)
[14:08:42] <N1njaneer> dabeastro: Atmel has some chart breakdowns to help sort out the part numbers and features, or you can use something like digikey.com that has parametric search to drill down
[14:08:54] <RikusW> megal0maniac_afk:
http://www.canton-electronics.com/4-in-1-xilinx-platform-cable-usb-altera-usbblaster-download-cable-lattice-ispdownload-cable-saleae-logic-analyzer-fpga-cpld-programmer-p-535.html?zenid=csj6b3lu3p2btkltk8bq8f7042
[14:09:26] <dabeastro> i don't have any specific project in mind...just want to try and break some stuff....
[14:10:47] <N1njaneer> dabeastro: Then just get something like an ATMEGA2560 and you'll have overkill pins and peripherals and storage space to play with. :)
[14:11:28] <dabeastro> okay. but what if i want to got the other...super simple. is something like a minimus avr usb a good option?
[14:12:27] <bitd> Well, you could just get an arduino and program it in avr-gcc.
[14:13:01] <N1njaneer> dabeastro: I'd get one of the Arduino MEGA2560s and just develop for it under AVRStudio6 or gcc
[14:13:08] <N1njaneer> It's a nice break-out board
[14:13:55] <bitd> Really man AVRStudio? <.<
[14:14:26] <bitd> How bout we shoot him in the leg right here :P
[14:14:30] <dabeastro> i have an uno available to me.
[14:14:32] <dabeastro> lol
[14:14:38] <dabeastro> so avrstudio no bueno?
[14:14:57] <bitd> Please use vim, avrdude and avr-gcc toolchain.
[14:15:15] <N1njaneer> bitd: Yes, from an IDE and organizational standpoint it works well, and I'll take it over Eclipse any day.
[14:15:29] <N1njaneer> bitd: AVRStudio uses avr-gcc, it just makes it far less of a pain to deal with.
[14:15:30] <bitd> Yes, over eclipse, sure.
[14:16:00] <dabeastro> i'll get hold of the uno and do some projects with that. is the mega really much more capable?
[14:16:14] <bitd> N1njaneer, vim with the right tools and add ons can be used, over and over for other mcu's as well.
[14:16:17] <N1njaneer> Just a bigger micro with more space and more pins.
[14:16:57] <N1njaneer> bitd: AVRStudio supports AVR, AVR32, XMEGA, and all of Atmel's ARM devices (with the exception of the SAM5 series currently) all under one package.
[14:17:01] <dabeastro> that should work for me then. i am just fooling around. no project or direction at the moment
[14:17:14] <bitd> N1njaneer, I'm not talking about just avr :P
[14:18:00] <dabeastro> so, what's up with the atmel avr devices that have a usb attached and look like a thumb drive?
[14:18:13] <dabeastro> like the minimus...
[14:18:30] <N1njaneer> bitd: Use whatever tools you can work FASTEST with to get the job done efficiently. Time is money here and we ship many different projects for customers per month. AVRStudio lets me work significantly faster than any other approach I've tried, and I've tried several :)
[14:19:57] <N1njaneer> bitd: A nice IDE is also useful when you are managing projects made up for dozens or hundreds or more sourcefiles, especially if you are doing ARM stuff and trying to pull in all of the ASF libraries from Atmel so you can actually DO something with the devices. :)
[14:22:02] <megal0maniac_afk> AVRStudio != Atmel Studio :/
[14:22:22] <N1njaneer> Sorry, yes. Atmel Studio 6.1
[14:22:40] <N1njaneer> I've been using the thing for 12+ years now, hard naming habit to break XD
[14:25:48] <abcminiuser> BAHAHAHAHA
[14:25:54] <abcminiuser> Despicable Me 2 is fantastic
[14:26:12] <bitd> Haha, just saw it, it is awesome.
[14:26:24] <Roklobsta> how's the norwegian dubbing?
[14:26:29] <abcminiuser> The minions singing was amazing
[14:26:49] <abcminiuser> Got an English version, Norwegian is Grossmann 2
[14:31:06] <carabia> was the troll movies norwegian
[14:31:10] <carabia> effing weird ppl
[14:31:14] <carabia> was, were
[14:40:02] <abcminiuser> Ja, Troll Hunter
[15:26:45] <megal0maniac_afk> RikusW: The XuLA board has a python based debugging system, using the PIC as a USB to JTAG bridge. You need to add instrumentation code to your source, but it's pretty flexible once set up
[15:27:33] <RikusW> and a custom app to load the bitstream ?
[15:30:29] <megal0maniac_afk> Yip. But because of the design, either you can load it directly to the FPGA, or to the SPI flash. Then the PIC will program the FPGA with JTAG on power-up
[15:30:49] <megal0maniac_afk> Hence the "flash" section in the programming dialog
[15:31:55] <N1njaneer> I find it's easier to hang the SPI off the FPGA and let the FPGA do a master-load of the SPI bitstream on start-up, then you can use an external micro to talk to/reprogram the SPI, as well as the FPGA. :)
[15:32:30] <megal0maniac_afk> N1njaneer: I think that's exactly what it does
[15:32:32] <N1njaneer> If you let the FPGA load the bitstream directly, it comes up within a few ms, versus a processor being in the middle. I've done them both ways :)
[15:32:39] <megal0maniac_afk> Ah
[15:33:02] <N1njaneer> The other nice thing is that you can load the SPI device directly through the FPGA via JTAG, which is awesomely-useful for device bring-up.
[15:33:36] <N1njaneer> It's how we factory-program things with FPGAs as well - SPI via JTAG. :)
[15:33:40] <N1njaneer> But I digress.
[15:34:05] <megal0maniac_afk> It's still pretty quick though, but I hear you. The system works quite nicely
[15:34:22] <N1njaneer> That's what matters :)
[15:34:38] <megal0maniac_afk> This is the programming dialog
http://i.imgur.com/LEyvq46.png
[15:35:13] <N1njaneer> It's just amusing because I have an older product (that I designed in 2005) that does the SPI load via ATMEGA128 into a Spartan2 device, and that process accounts for the several second 'boot' time the device has on start-up; loading the FPGA's bitstream image.
[15:37:38] <megal0maniac_afk> I think it takes about 500mS for the led to start blinking :)
[15:39:10] <N1njaneer> FPGA bitstreams are actually pretty interesting to look at if you load them in to GIMP or Photoshop as RAW files.
[15:43:25] <megal0maniac_afk> Ooh, they are!
[15:43:37] <megal0maniac_afk> Only have irfanview on hand, but I get the idea
[15:46:43] <N1njaneer> Fun stuff!
[15:51:49] <megal0maniac> zlog
[15:52:55] <megal0maniac> Should probably try it with something a little more complicated, though :)
[16:58:43] <megal0maniac_afk> If Atmel ships samples with some quantities as 0, does it mean that they aren't sending you those parts, or they'll send them seperately when they have stock?
[16:59:11] <megal0maniac_afk> Oh, never mind. Didn't notice the backorder column
[17:03:43] <specing> backorder?
[17:03:52] <specing> Who does ATMEL backorder AVRs from?
[17:06:19] <twnqx> i suppose from their distributors
[17:06:40] <twnqx> why would they do that themselves
[17:06:53] <twnqx> TI clearly outsourced to digikey
[17:09:23] <megal0maniac_afk> specing: The backordered part is a SAM D20
[17:10:00] <megal0maniac_afk> It's a brand new part, which has had a lot of publicity, so I'm not surprised
[17:22:55] <N1njaneer> Backorder means the parts are on order from the manufacturer.
[17:23:19] <N1njaneer> So Atmel, TI, etc provide to Arrow, DigiKey, Mouser, Farnell, etc :)
[17:24:06] <N1njaneer> Which them from from a packager, who packages the dies from the fab.
[17:24:08] <N1njaneer> +then
[17:24:21] <N1njaneer> er... Which then come from a packager, who packages the dies from the fab.
[17:25:40] <N1njaneer> Always good to use a part which shows healthy stock from a number of suppliers if you are concerned about moving in to production quickly and can't afford 12-16 week or more in a worst-case lead-time for devices.
[17:27:01] <N1njaneer> Anyhoo
[17:27:05] * N1njaneer resumes rework
[18:25:28] <jadew> http://www.youtube.com/watch?v=FeLx_1E7gu8
[18:25:29] <jadew> YouTube: Villagers swap loud speakers for mobile phones
[20:42:49] <N2TOH> who here has written their own interpreter for the for the 8 bit AVR?
[20:49:18] <N2TOH> before you say I'm nuts take a look at this,
[20:49:22] <N2TOH> http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7
[20:49:46] <N2TOH> I'm toying with the idea of compiling System 7 UNIX with AVR-GCC
[20:52:51] <timemage> N2TOH, what's the appropriate amount of time we need to wait before telling you that you're nuts? =)
[20:54:11] <N2TOH> that was enough
[20:54:31] <Casper> we waited enought? oh great, then you're nut!
[20:54:39] <N2TOH> hey the ATmega1284P has 16Kilo Bytes of SRAM that sould be enough to boot :)
[20:55:04] <seldon> You are aware that important parts of that are written in pdp-11 assembly, are you not?
[20:57:13] <seldon> I suppose you could attempt to write a pdp-11 emulator for AVR. Perhaps that would not even be crazer than the ARM emulator, although it would still be rather insane, all things considered.
[20:57:38] <N2TOH> I'm considering it after reading about the ARM emulator
[20:58:21] <seldon> There's certainly hack value in it.
[20:58:37] <seldon> s/crazer/crazier/, btw.
[20:58:48] <N2TOH> I did already manage to track down a guy in Calli who created an ASM byte code interpreter for the AVR that allowed him to run code stored from an SD card.
[20:59:23] <N2TOH> kinda like a basic stamp kinda thing but ASM code vs basic tokens
[20:59:52] <N2TOH> he was willing to share, but warned it was spaggeti code with no comments
[20:59:56] <N2TOH> or documentation
[21:18:12] <N2TOH> crazy of not the tools are there...
[21:41:24] <N2TOH> So the question I ask is do I go down the emulator path, or just do a native port
[21:54:43] <Casper> if native is an option, go native, always better
[21:57:00] <N2TOH> I can squirt most of the Bell Labs source thru AVR_GCC but there is still tons of PDP-11 ASM code that has to be replaced with AVR ASM code
[21:57:45] <N2TOH> hmm perhaps a psudo emulator in the forum of a AVR BIOS firmware
[21:58:34] <N2TOH> short story code that runs from the internal flash is WAY faster!
[22:00:38] <N2TOH> the guy I spoke with in CA claimed that he could seamlessly switch between interpreted and internal code.
[22:01:52] <N2TOH> so I postulate to write a BIOS that streamlines all the disk access and serial stuff, then try to cram as much as I can into the 128K flash
[22:23:48] <rue_shop2> or just use linux, that ignores the bios and just does things
[22:26:15] <N2TOH> the reason in my case for BIOS code is that in interperted mode the code runs like 12 times slower, then just calling internal flash code. again keep in mind the code is running on 16 to 20MHz 8 bit AVR and not a modern PC
[22:29:29] <N1njaneer> N2TOH: Simple fix, LN2 cool the chip and overclock at 192Mhz to make up for the difference.
[22:31:13] <N1njaneer> Clearly that is the most economical way to problem-solve it!
[22:34:05] * N2TOH sees the project primarily as a joke and source of amusement, what would be epically more amusing after it's done is people actually finding real uses for the code.
[22:36:36] <N1njaneer> ... and thus is also how Microsoft Windows 8 was born....
[22:43:02] * N2TOH LOL!
