Back
[02:37:04] <goddard> is there any info on PROGMEM and device descriptor arrays?
[02:37:11] <goddard> it is just a line of hex
[02:37:31] <goddard> how can i figure out what the keys are?
[02:38:59] <Xark> goddard:
https://download.lulzbot.com/TAZ/hardware/electronics/RAMBo/bootloaders/rambo-32u2-usbserial/Descriptors.h ?
[02:39:48] <Xark> goddard: Perhaps in conjunction with
https://download.lulzbot.com/TAZ/hardware/electronics/RAMBo/bootloaders/rambo-32u2-usbserial/Descriptors.c
[02:40:23] <Xark> goddard: Hmm, this looks perhaps better
http://eleccelerator.com/tutorial-about-usb-hid-report-descriptors/
[02:57:06] <goddard> Xark: sweet maybe this will help :D
[03:26:03] <Haohmaru> is it possible to write all fuses from a file? with avrdude
[05:50:54] <cehteh> yes
[05:51:27] <LeoNerd> From three files. Annoyingly, avrdude treats each of the three fuses as an independent memory :/
[05:51:46] <LeoNerd> I don't know why it thinks three 1-byte memories are a better model than one 3-byte
[05:54:08] <Lambda_Aurigae> because someone wrote it that way?
[05:54:20] <Lambda_Aurigae> or maybe it's just insane from being used with too many arduinos.
[05:57:01] <Lambda_Aurigae> I'm beginning to like the pic pragma commands more and more.
[05:57:11] <LeoNerd> I should probably have my avr_hvsp tool synthesize a "fuses" memory
[06:18:45] <Haohmaru> in my case it's 5 bytes
[06:19:20] <Haohmaru> they are actually 6, but one of them (in the middle) is not available
[06:27:38] <Haohmaru> crap, this ftdi serial-to-uart is f*cked up.. when i short TX/RX on it the echo gets semi-corrupted
[06:53:44] <LeoNerd> FTDIs also have a "loopback" mode, so you can turn that on and it does it internally in the chip
[06:53:52] <LeoNerd> can help to distinguish hardware board-level problems
[06:54:46] <LeoNerd> 6 fuse bytes?
[07:02:36] <Haohmaru> five
[07:03:00] <Haohmaru> 0, 1, 2, 4, 5
[07:03:53] <Haohmaru> after compiling, i got a fuses hex, which contains 6 bytes, and the 4th one is 00
[07:04:55] <cehteh> isnt avrdude completely controlled by its config files .. you prolly can configure it to flash all fuse bytes in one rush
[07:05:33] <cehteh> just a bit magic fairy dust, this low level avrdude hacking, i never did
[07:09:21] <Haohmaru> if i'd try to modify avrdude, it would be to make v6.x work with the programmer, and then i would flash the .elf file directly
[07:09:26] <Haohmaru> but.. i couldn't
[07:10:12] <Tom_itx> iirc avrdude will flash elf anyway
[07:10:33] <Haohmaru> i read that it works from 6.x onwards
[07:10:34] <Tom_itx> just not reindeer
[07:11:33] <Haohmaru> there was something like.. "it will flash the elf as binary"
[07:13:26] <apo_> I always flush my elves with lava
[07:13:30] <apo_> it's the only way to be sure
[07:13:35] <LeoNerd> Haohmaru: my surprise was more that I didn't think there were AVR devices with that many fuses.
[07:13:43] <LeoNerd> Is it an Xmega?
[07:14:08] <Tom_itx> xmegas program PDI only
[07:14:49] <Tom_itx> LeoNerd, maybe it's a reserved byte for now
[07:19:22] <Haohmaru> LeoNerd yiz
[07:25:06] <Haohmaru> it was surprisingly easy to get printf() working O_o
[07:39:15] <Haohmaru> well, duh.. both RX and TX had to have external pullup, now it's not getting corrupted
[07:39:17] <Haohmaru> wtf
[07:40:04] <LeoNerd> Accidentally got stuck in opencollector/drain mode?
[07:40:15] <LeoNerd> Or maybe damaged hardware and has blown one of the totem drivers?
[07:40:17] <Haohmaru> no idea
[07:40:26] <LeoNerd> I find my FTDI FT232H sometimes a bit fiddly with that
[07:40:45] <Haohmaru> the ftdi convertor has surely seen.. things.. ;]
[07:40:55] <LeoNerd> Opendrain UARTs can be useful.. you can make a onewire bus out of them :)
[07:41:24] <Haohmaru> opendrain?
[07:41:39] <Haohmaru> does that mean it only drives low but not high?
[07:41:42] <LeoNerd> yup
[07:41:51] <Haohmaru> ahumz
[07:42:05] <LeoNerd> The output circuit looks like an nFET with source on GND, internal logic on the gate, and the drain pin is left "open" to the outside world
[07:42:35] <LeoNerd> So turning the FET on pulls the drain pin to ground, but with the FET off it just floats, so you put a pullup resistor on it. It's what things like I²C use
[07:42:51] <LeoNerd> Or often the IRQ output line of sensors/etc... will do that, so you can wire them all together on a shared bus
[07:44:25] <cehteh> in some cases you can emulate that with avr's .. switch DDR between sink and highz
[07:44:34] <LeoNerd> Yup
[07:44:53] <LeoNerd> The 232H supports that, you can configure opendrain mode independently on any of the 16 IO pins :)
[07:44:56] <cehteh> only the other way around when you want it pulled up is a bit more nasty
[07:45:00] <Haohmaru> the xmega can do that per pin iirc
[07:45:02] <LeoNerd> Except the person who wrote the data sheet had never heard the phrase "open drain"
[07:45:07] <cehteh> ah nice
[07:45:15] <LeoNerd> So it's documented with the hillariously wordy "drive output low on zero only" mode
[07:46:00] <cehteh> the uart on the megas and tiny cant do that or?
[07:46:05] <LeoNerd> Nope
[07:46:14] <LeoNerd> But you can trivially arrange for it in hardware, just with a diode
[07:46:18] <Haohmaru> maybe this: "Wired-AND with optional pull-up"
[07:46:29] * cehteh planning for some one wire like protocoll, cant use uart for tha
[07:46:40] <LeoNerd> Obviously that's not software switchable, but if you don't need the switching, just stick a 4148 inline with the TX pin
[07:46:52] <LeoNerd> Yah; I do UART buses like that
[07:46:59] <cehteh> pwm hardware should work to help bitbanging stuff
[07:47:17] <LeoNerd> TX --[k 1N4148 a]-- bus ---- RX
[07:47:33] <LeoNerd> And someone on the bus has a small (few Kohm) resistor pullup
[07:47:58] <LeoNerd> You need a bit of fancy collision detect, and annoyingly the AVR UART doesn't cope too well at that
[07:48:09] <cehteh> i want one wire bidirectional, with many devices on the bus
[07:48:10] <LeoNerd> multimaster I²C controllers check for collisions on every bit
[07:48:30] <LeoNerd> The AVR UART isn't built for that. You can detect after an entire byte if a collision happened, but only once you've corrupted that byte on the bus
[07:48:54] <LeoNerd> So then you need a bit of collision avoidance and retry, and that gets messier. So you can't have a very contended bus
[07:49:01] <LeoNerd> It's useful for "rare" events like human-input button presses
[07:49:21] <cehteh> io - [1k] -----wire------ [1k] -io .... internal pullups, and in front of the 1k resistors a 4.7 Zener to gnd for protection
[07:50:15] <cehteh> protokol with some token, only one node can send, everyone else listening
[07:51:09] <LeoNerd> Yeah, those can work too but then you have to pass it around and eugh..
[07:51:16] <cehteh> yeah
[07:51:23] <LeoNerd> I do radio systems with time division
[07:51:47] <cehteh> i aim for small codesize, so it can run on tiny85
[07:51:48] <LeoNerd> The base station maintains a 50msec beat broadcast, and gives other stations roughly equally-spaced timeslots within that beat
[07:52:06] <LeoNerd> So everyone else waits for the main beat, and then has their own delay after that before they check in
[07:52:11] <cehteh> there is no base here, its completely peer to peer
[07:52:15] <LeoNerd> Mmm
[07:52:22] <LeoNerd> So you just need to elect a master
[07:52:26] <cehteh> doesnt exist yet, just planning
[07:53:56] <cehteh> everyone has a address, first one on the bus (listens if the bus is silent, send wakeup, listen again ..) becomes master, sends beats or goes to sleep waiting for wakeups
[07:54:10] <cehteh> but later this 'master' token is just passed along
[07:54:14] <LeoNerd> Yeah, there's various standard ways to do that
[07:55:31] <cehteh> i just hack my own way, want to make it as free software so hopefully i wont tip too much patents
[07:58:13] <cehteh> most important, i want to make it reasonable timing error resistant, most serial busses have problem with timing get off and are a pita then
[07:58:53] <LeoNerd> Well, yes.. that's the general async serial problem
[07:59:17] <LeoNerd> The dallas onewire, and WS2812 protocols are clocked per bit.. kindof slow but mostly solves that issue
[07:59:47] <cehteh> i clock per 2 bit :D
[08:02:00] <cehteh> basically its pwm out, bits are only transfered when the duty cycle changes, so one could stall the bus with pwm hardware, while being busy
[08:02:58] <cehteh> havent settled on error corrections yet, possibly just parity, maybe crc
[08:05:48] <Xark> Do you really think PWM is helpful? It is 1 cycles to set or clear a GPIO line...
[08:05:56] <Xark> 2*
[08:06:52] <cehteh> and?
[08:07:22] <Xark> Do you really think PWM is helpful?
[08:07:29] <cehteh> why not?
[08:08:01] <cehteh> as long timing constraints can be met it should work
[08:08:30] <Xark> It just seems more of a PITA to use than not. But maybe I am missing something.
[08:08:41] <cehteh> will evaluate that, prolly making a pure bitbanging implementation too
[08:08:50] <cehteh> but why burn cpu cycles when you can use hardware
[08:09:02] <Xark> Slow/ :)
[08:09:11] <cehteh> i dont need very high speed
[08:09:38] <cehteh> too high speed wont work on single wire protocols anyway
[08:09:56] <cehteh> esp when wires are unshielded and get longer
[08:09:56] <Xark> Ok then. But it still seems easier to me to just toggle line via software vs staying in sync and setting PWM regs.
[08:10:16] <cehteh> yeah i will provide an implementaiton for that too
[08:11:01] <cehteh> but that could be more wasteful on cpu cycles and its harder to keep the timing (unless dealing with the bus is the only thing you do)
[08:11:31] <cehteh> but if your µC does something else and you want to keep interrupts enabled this will be pita
[08:11:52] <LeoNerd> I'd suggest using the UART for this if you can. Offload to hardware what is easy for it
[08:12:09] <cehteh> uart cant do that
[08:12:20] <Xark> Yeah, UART or SPI perhaps.
[08:12:31] <cehteh> uart needs clock signal
[08:12:40] <cehteh> and cant toggle open drain on tinys
[08:13:10] <LeoNerd> But again:you can create opendrain by adding a single diode to your board
[08:13:17] <Xark> If you are on ATTiny, then USI is probably helpful (same as UART and SPI anyways)...
[08:13:29] <LeoNerd> An output pin with the cathode of a diode attached, becomes opendrain
[08:14:28] <Haohmaru> i removed the external resistors and used the pinctrl stuff.. PULLUP on the RX and WIREDANDPULL on the TX
[08:14:36] <Haohmaru> still works now
[08:14:50] <Haohmaru> yey xmega
[08:14:51] <cehteh> still USI needs a clock or am i wrong?
[08:15:18] <Haohmaru> xmega is much x, very mega
[08:17:07] <LeoNerd> USI needs some kind of timing source, yes
[08:17:12] <LeoNerd> But it's up to you how you want that timing to work
[08:18:45] <cehteh> of course it should be on the wire
[08:19:20] <cehteh> when i looked at the usi datasheet i didnt got how i could realize what i want with usi
[08:19:50] <cehteh> you either need a clock line or get the clock from some internal source
[08:19:54] <LeoNerd> The USI is very Lego.. :) It can be tricky at first to see just how many ways you can stick it to other bricks to achieve your goal
[08:20:12] <cehteh> but you cant syncronize the clock with the falling egde of the signal
[08:20:20] <LeoNerd> Sure you can
[08:20:34] <LeoNerd> You use a PCINT on the DI line to force the first half of each bit's clock phase
[08:20:35] <cehteh> how?
[08:20:44] <LeoNerd> That interrupt also starts a short timer, that on expiry ticks the second half
[08:20:53] <LeoNerd> Arrange for the sampling to occur on that second half
[08:21:10] <LeoNerd> So whether the line is high or low after that bit timeout, is the level that is sampled and remains in the SR
[08:21:36] <cehteh> thats not much usi anymore :D
[08:21:46] <LeoNerd> It's very USI
[08:21:54] <LeoNerd> It's a user-assisted serial interface
[08:22:07] <LeoNerd> You the software running on the AVR, are assisting the serial interface to do its work
[08:22:11] <Haohmaru> wut's this usi?
[08:22:22] <LeoNerd> You know *when* to perform the shifting and clocking. so you tell it
[08:22:27] <LeoNerd> It implements that shifting
[08:22:38] <cehteh> and i wanted 2 bits per clock
[08:22:49] <LeoNerd> Uhm
[08:22:58] <LeoNerd> you can only get 2 bits per clock if you have a 4-level analog signal
[08:23:06] <cehteh> no
[08:23:06] <LeoNerd> .. or if you have two independent data lines
[08:23:13] <cehteh> digital modulation
[08:23:36] <LeoNerd> I don't recognise that phrase.. Explain
[08:24:10] <cehteh> thing about a pulse of 6 time units lets say bus idle has 50% duty ---___
[08:24:34] <LeoNerd> Ah; I see. But to recover that, you need the receiver to be clocking a lot faster, to recover it
[08:24:35] <cehteh> now you can signal -_____ to -----_
[08:24:53] <LeoNerd> So in effect you've now got a "normal" serial system, except you've restricted the patterns of bytes you could send
[08:25:01] <cehteh> yeah
[08:25:09] <LeoNerd> In effect, you're allowing only 100000, 110000, 111000, 111100 or 111110
[08:25:13] <cehteh> yes
[08:25:21] <cehteh> and that makes no sense with usi
[08:25:24] <LeoNerd> So why bother? If your transmitter and receiver can clock that quickly, just use all the bit slots independently
[08:25:36] <LeoNerd> You've reduced your signal bandwidth for no useful reason
[08:26:23] <LeoNerd> The information is flowing at a rate of 2 bits per 6 hardware clocks; when a naive system could manage 6 bits in that time
[08:27:13] <cehteh> cable cacpacitance/inductance .. and syncing the clock on rs232 protocol for example is ugly
[08:27:27] <LeoNerd> Cable capacitance has nothing to do with it
[08:27:32] <cehteh> ok start/stop bits
[08:27:42] <cehteh> anyway .. i do this another days, not now
[08:27:44] <LeoNerd> If the cable's properties are such that you can distinguish --____ from ---___ then it can distinguish 01 from 10
[08:28:05] <LeoNerd> If it can't do the latter, then it can't do the former _either_
[08:28:28] <cehteh> i'll think about it
[08:29:04] <LeoNerd> Pulse width encoding systems are useful on things like CD surfaces, because those have minimum pit and minimum land requirements... they can precicely measure the change far smaller than the smallest feature
[08:29:34] <LeoNerd> But electrical signals don't work like that; you can make pulses as short as the size you can measure, so it doesn't make sense to require smaller measurement than the smallest pulse you take
[09:49:08] <jben> Hi guys,
[09:50:18] <jben> I think of using an sdcard with a ATmega, for writing measured data from sensors (and precomputation)
[09:51:09] <jben> I think using a filesystem is easier to use the recorded data, as FAT or ext2.
[09:51:49] <jben> Do somebody have information about using SD cards and filesystems on it?
[10:04:31] <RikusW> it might be best to use some library for that
[10:15:29] <jben> RikusW: it is that I think, but I don't know libs which do that. I saw libs for arduino, and some libs for atmega, but lib for atmega seems to be proof-of-concept mote than lib (I saw only one lib)
[10:16:09] <RikusW> ASF from atmel might have it builtin
[10:16:19] <RikusW> if you have atmel studio
[10:18:01] <jben> I do not use atmel studio, but that is a good idea to look inside that
[10:19:38] <jben> hum, ddg and google don't find any lib form atmel studio which are doing that
[11:16:11] <|DM|> jben, depending on the amount of measured data
[11:16:22] <|DM|> you could just use the built in eeprom
[14:51:23] <lald> Hi, it seems like my distro's package of avra didn't come with the .inc for the ATmega328P. I found a copy on GitHub. Is there a more correct way for me to solve that issue in the future?
[17:34:44] <Jartza> lald: just copy them from somewhere, preferrably from atmel studio ;)
[17:34:57] <Jartza> avra will complain about the #pragma, but it doesn't really matter
[17:44:30] <lald> It's not complaining so far.
[17:44:48] <lald> Thanks though
[18:12:36] <jben> okay, /b avr
[18:13:02] <jben> (fail of buffer change)
[18:16:08] <jben> |DM|: no the build eeprom is too small, I have to write two measure (two float) each second for 24 hours
[18:16:46] <jben> so ~700KiB
[18:18:06] <jben> and using a sdcard with a filesystem allow a very simple way to load the data on the computer
[18:28:26] <|DM|> aha ok
[18:34:08] <Lambda_Aurigae> have used SD cards for things like that many times.
[18:34:26] <Lambda_Aurigae> I usually create a large text file on the SD card and just read and write that file.
[21:45:14] <icantlogin> howdy, anyone not lurking?
[21:48:19] <Xark> Nope. :)
[21:49:59] <icantlogin> oh, hello again!
[21:53:57] <Xark> icantlogin: Did you have an AVR question?
[21:59:14] <icantlogin> i do. i'm wondering what chip would be ideal if i wanted to build a low-spec game console
[22:00:01] <icantlogin> i could outsource the video and audio but i'm looking for a cpu
[22:02:03] <Xark> icantlogin: Hmm. You want AVR?
[22:02:15] <Xark> Have you seen UzeBox and Arduinocade?
[22:02:41] <Xark> For performance, PIC32 may be a good choice (or ARM perhaps).
[22:04:55] * Xark has experimented to see what just a 16MHz AVR can do (with two resistor composite) -> https://i.imgur.com/IgsmEY3.png https://i.imgur.com/gNyTb6u.jpg and a sprite test https://www.youtube.com/watch?v=Imk5ony8JHI
[22:06:25] <Xark> For AVR, 1284 is great (16KB SRAM and still 16-bit pointers), but doesn't overclock much past 20MHz. 644 has less RAM, but is quite overclockable (hence UzeBox).
[22:08:15] <icantlogin> i have seen the uzebox project. i'd like to do something similar ^o^
[22:08:49] <icantlogin> *checks links*
[22:09:15] <icantlogin> that saturn is gorgeous.
[22:10:59] <icantlogin> why "pseudo-sprites"?
[22:13:51] <icantlogin> also, holy crap, the arduinocade is based off of the uno?
[22:23:31] <Xark> Pseudo sprites, because they are really just redefined characters (128 in flash and 128 in RAM).
