| 00:49.31 | kristianpaul | game changer? |
| 00:51.50 | wolfspra1l | wpwrak :-) |
| 00:51.57 | wolfspra1l | he means fpgatools I would think |
| 00:52.06 | wolfspra1l | or maybe the pcb etching that I keep procrastinating on? :-) |
| 00:52.21 | wolfspra1l | fpgatools will be no game changer for sure |
| 00:52.29 | wolfspra1l | though the project is really great |
| 00:52.33 | wolfspra1l | (for me) |
| 00:52.55 | wolfspra1l | the more I work on that, the more I value the existing tools, open or closed |
| 00:53.02 | wolfspra1l | which is to be expected |
| 00:53.21 | wolfspra1l | can't wait to move forward to the xc7a100, yesterday I started peeking into xc7 documentation :-) |
| 00:53.24 | wpwrak | yeah, the fpga tools. and if they're not a game change, then something's very wrong in this world :) |
| 00:53.49 | wolfspra1l | I don't think this is such a binary problem |
| 00:53.59 | wolfspra1l | maybe later on the tool can find a niche, maybe |
| 00:54.23 | kristianpaul | ah yes pcb etching is fun too ;) |
| 00:54.32 | wolfspra1l | I have to say I start to like the chips more too, what's inside them, things like the mcb, gtp, upcoming adc |
| 00:54.35 | wolfspra1l | the zynq |
| 00:54.38 | wolfspra1l | and so on |
| 00:55.09 | wolfspra1l | xilinx is moving behind vivado 100% |
| 00:55.16 | wolfspra1l | so ise will be a thing of the past soon |
| 00:55.17 | wpwrak | the most important bit may not be the tools themselves but rather what they reveal |
| 00:55.38 | wpwrak | maybe someone will just read the code and then hack a synthesis system in haskell |
| 00:55.40 | wolfspra1l | even for new 7-series designs, ise seems officially 'unsupported' |
| 00:55.56 | wolfspra1l | (quoting their own xcell publication) |
| 00:56.06 | wpwrak | divide yourself and be conquered ;-) |
| 00:56.15 | wolfspra1l | ise had a 15 year life |
| 00:56.25 | wolfspra1l | and maybe that's enough |
| 00:56.49 | wolfspra1l | so we have to see. 'game changer' doesn't resonate with me |
| 00:56.52 | wpwrak | feels as agile as if it didn't have a day more than 150 years on its back ;-) |
| 00:57.01 | wolfspra1l | if a few more serious people find fpgatools and if it creates any value for them, I will be happy |
| 00:57.24 | wolfspra1l | how can you say that without knowing what it does, what requirements they had to meet to get to where they are, or the alternatives? |
| 00:57.42 | wpwrak | the fpgatools prove that synthesis can be done (without access to privileged information) |
| 00:57.52 | wolfspra1l | yes |
| 00:58.04 | wpwrak | this breaks down one of those "this is impossible" barrieres |
| 00:58.13 | wolfspra1l | but I don't think anyone from xilinx/altera or others would have suspected anything else |
| 00:58.15 | wpwrak | like supersonic flight |
| 00:58.27 | wolfspra1l | 'this is impossible' only in the circles of relatively meaningless and immature babbling |
| 00:58.34 | wpwrak | once someone has proven it's possible, things suddenly get a LOT easier |
| 00:58.48 | wolfspra1l | we should not underestimate people, but also not overestimate them |
| 00:58.53 | wolfspra1l | the world may not be full of werners :-) |
| 00:58.54 | wpwrak | and your proof is a constructive one, i.e., it also shows how it's done |
| 00:58.59 | wolfspra1l | one by one |
| 00:59.01 | wolfspra1l | I'm at 0.1% |
| 00:59.09 | wolfspra1l | working on the luts again, actually |
| 00:59.11 | wolfspra1l | more cases |
| 00:59.19 | wolfspra1l | fixed 0, fixed 1 |
| 00:59.43 | wolfspra1l | and there are luts in a lot of varieties (in the encoding), they are all different depending on whether they sit in the a-d position, or x/l/m slice, or lut6 or lut5 |
| 00:59.46 | wolfspra1l | etc. etc. |
| 01:00.07 | wolfspra1l | I brought that stuff exactly to the level I needed for the AND gate, but now for the blinking led I have to take it a bit higher |
| 01:00.15 | wpwrak | cute ! your "inside an fpga" book will be a bestseller :) |
| 01:00.23 | wolfspra1l | and I can already see the next steps later, because the luts can also be used as rom, ram, shift registers, etc. |
| 01:00.43 | kristianpaul | wpwrak: book yes ;)! |
| 01:01.02 | wolfspra1l | kristianpaul: you have read the sources a bit, please let me know if you have any questions |
| 01:01.07 | kristianpaul | wolfspra1l: yes ram please :) |
| 01:01.15 | wolfspra1l | I will probably apply werner's if (model->rc) error handling idea soon |
| 01:01.26 | wolfspra1l | because it cuts down the number of lines of code, which I always like |
| 01:01.27 | kristianpaul | wolfspra1l: yes i will, i'm reading x6 datasheets again |
| 01:01.38 | kristianpaul | now hello world make more sense |
| 01:01.40 | wolfspra1l | and I have to do this soon before the codebase is at 50k lines :-) |
| 01:01.53 | wolfspra1l | thanks for that werner! |
| 01:02.16 | wolfspra1l | I just have to get used that the code running throuhg all sorts of functions in an 'error state' is not an ugly thing :-) |
| 01:02.36 | wolfspra1l | maybe run around the block twice, cold shower, then I'm ready for the change :-) |
| 01:03.08 | wolfspra1l | kristianpaul: ram support is a lot of work |
| 01:03.14 | wolfspra1l | expect it a little later |
| 01:03.22 | wolfspra1l | first the logic blocks |
| 01:03.29 | wolfspra1l | even those are just 5% supported now |
| 01:03.32 | wolfspra1l | something like that |
| 01:03.38 | wolfspra1l | then bram, macc |
| 01:03.48 | kristianpaul | sure sure |
| 01:03.51 | wolfspra1l | each bram device has about 190 pinwires :-) |
| 01:03.56 | wolfspra1l | and a macc slice about 350 |
| 01:04.12 | wolfspra1l | that's a lot of stuff going in and out that has to be tamed/understood/processed in a meaningful way |
| 01:04.40 | kristianpaul | where you count the pins from the library datasheet? |
| 01:04.41 | wolfspra1l | werner is right about one thing though |
| 01:04.48 | wolfspra1l | I am looking at details, lots of them, thousands |
| 01:04.58 | wolfspra1l | and I may get lost in the details and not see the big picture, i.e. where to apply this today |
| 01:05.19 | wolfspra1l | so once in a while I should get out of the pile of details and see whether this makes sense to anyone outside |
| 01:05.22 | wolfspra1l | I will |
| 01:07.08 | wpwrak | great ! you may also find people who can help. once the problem appears less overwhelming, others may feel confident enough to give it a try |
| 01:07.08 | wolfspra1l | kristianpaul: you find the data in the documentation, dsp48a1 slice etc. |
| 01:07.34 | wolfspra1l | it just takes a bit of time to put the pieces of the puzzle together in running code as opposed to dozens of pdf files |
| 01:08.16 | wpwrak | and of course, there are thousands of people out there who spent the best years of their lives studying all the sort of nasty algorithms you'll need to give meaning to the low-level stuff you're digging up. |
| 01:09.34 | wolfspra1l | that's why I'm hesitating about the game changer |
| 01:09.43 | wolfspra1l | yes there is a lot of business in those chips, and applications |
| 01:09.54 | wolfspra1l | BUT, they are tied to existing workflows, tools, ip/reusable cores, etc. etc. |
| 01:10.04 | wolfspra1l | if you take it all out, the value drops a lot |
| 01:10.19 | wolfspra1l | but for myself I do believe this is the right thing since I don't want to start somewhere inside the existing toolchains |
| 01:10.30 | wolfspra1l | I just start with the chip naked like a little baby |
| 01:10.42 | wolfspra1l | then the milk bottle |
| 01:10.45 | wolfspra1l | then take it from there :-) |
| 01:11.05 | wolfspra1l | I think the zynq chip is something quite interesting |
| 01:11.43 | wolfspra1l | btw xilinx acquired a small linux solution provider recently |
| 01:11.51 | wolfspra1l | they built embedded linux systems around microblaze |
| 01:12.05 | wolfspra1l | and now they (that small team) will focus on linux solutions around zynq |
| 01:12.24 | wolfspra1l | 'solutions' probably meaning some larger work that works out of the box and can be the starting point for an embedded project |
| 01:12.59 | wpwrak | not sure about the workflow, but iwouldn't worry about the IP. the existence of Free tools gives meaning to avoiding proprietary IP. before it was more a style choice, since you were tied to the vendor anyway, though the tools. |
| 01:13.52 | wpwrak | now the proprietary IP becomes the one last thing that binds you. in many cases, there will be no escape. but there are probably lots of cases where just a little effort would be needed to drop these chains as well. |
| 01:14.19 | wpwrak | and as things grow, abandoning proprietary IP will get easier and easier |
| 01:16.27 | wolfspra1l | it's not that binary |
| 01:16.45 | wolfspra1l | fpgas are very specialized chips that find its way into real world products through an entire stack of tools |
| 01:16.58 | wolfspra1l | I can write a small piece of those tools |
| 01:16.58 | wolfspra1l | so? |
| 01:17.06 | wolfspra1l | other tools exist as well in the 'free' world |
| 01:17.16 | wolfspra1l | but they are not supported, there is no business using those tools |
| 01:17.30 | wolfspra1l | and most importantly - there are not enough *serious* people who drive value into and out of these tools |
| 01:17.37 | wolfspra1l | let's call it the 'shit' counter |
| 01:17.51 | wolfspra1l | the people who talk about free tools will use the s-word in every other sentence |
| 01:17.59 | wpwrak | well, let's see how it goes. rome wasn't built in a day :) |
| 01:18.28 | wolfspra1l | I do not believe that fpgatools alone changes how many business opportunities around fpgas exist or emerge |
| 01:18.30 | wpwrak | and you'd be surprised by how ridiculous linux looked in its infancy ... |
| 01:19.07 | wolfspra1l | not surprised because I didn't hack on it like you did in 1992, but around the same time I did install it on every piece of 80x86 I could get my hands on |
| 01:19.19 | wolfspra1l | but trust me on the business thinking, that's why fpgatools alone won't change much imho |
| 01:19.22 | wolfspra1l | not fast |
| 01:19.43 | wolfspra1l | if at all then there must be a whole suite/stack of tools that somehow connects to real world use cases |
| 01:19.55 | wolfspra1l | including debugging, resuable cores, and and |
| 01:20.16 | wpwrak | oh, it'll be years before this matters in terms of business |
| 01:20.41 | wolfspra1l | one thing xilinx highlights in vivado is that vivado has all these 'ip management' features |
| 01:21.21 | wolfspra1l | because (I would assume) their customers are dealing with more complex projects that has to integrate ip from various sources into 1 functioning and fully tested and verified product, with a tight schedule |
| 01:21.22 | wolfspra1l | that have to |
| 01:21.44 | wolfspra1l | so the problems they are solving for their customers are x generations ahead/away from that little tech tool/toy I am working on right now |
| 01:22.29 | wolfspra1l | but let's see. maybe fpgatools can find a niche over some difference to other tools |
| 01:22.38 | wolfspra1l | that difference may emerge over time |
| 01:22.55 | wolfspra1l | it's not relevant to me as long as I can't even blink a led yet |
| 01:23.18 | wpwrak | of course. but as the little toy gets stronger, it'll get a viable choice for an increasing number of people. first, perhaps only researchers. then a few crazy folks from industry. then some projects with unusual requirements. and so on. |
| 01:23.33 | wolfspra1l | let alone have any hope that fpgatools could matter in a project where some customer has to ship a fully working/tested/stable product for motor control or real-time visual analysis in a few months |
| 01:23.34 | wpwrak | yeah, blinking the led is kinda essential :) |
| 01:23.44 | wolfspra1l | yes correct |
| 01:23.55 | wolfspra1l | now we're on the same page, and that doesn't sound like 'game changer in october' to me ;-) |
| 01:24.03 | wolfspra1l | blinking led in october, maybe |
| 01:26.27 | roh | heho |
| 01:30.46 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 01:45.01 | wolfspra1l | I'm working on the carry chains at the moment btw |
| 01:45.18 | wolfspra1l | needed for the counter that counts up (to make the led blink :-)) |
| 01:45.51 | wolfspra1l | it's a holiday in china, which I can feel because suddenly so quiet outside |
| 01:46.01 | wpwrak | ;-) |
| 01:46.20 | wolfspra1l | normally there is construction all around me, the are building new luxury-whatever in all n/s/e/w directions here... but not now |
| 01:46.27 | wolfspra1l | I can hear the birds tweeting :-) |
| 01:46.30 | wolfspra1l | so they DO EXIST :-) |
| 01:46.33 | kristianpaul | wow :) |
| 01:46.45 | wolfspra1l | yeah |
| 01:46.51 | wolfspra1l | carry chains with bird inspiration |
| 01:47.02 | wolfspra1l | the holiday lasts the entire week |
| 01:47.02 | kristianpaul | i all years listen birds |
| 01:47.08 | kristianpaul | except hollidays ;) |
| 01:47.14 | wolfspra1l | not when you have a sledgehammer not far from you :-) |
| 01:47.55 | kristianpaul | haha |
| 02:47.27 | *** join/#qi-hardware nikescar (~nikescar@114.199.131.108) |
| 03:03.42 | *** join/#qi-hardware DocScrutinizer06 (~HaleBopp@openmoko/engineers/joerg) |
| 03:48.56 | *** join/#qi-hardware fire_ (~fire@unaffiliated/codingenesis) |
| 04:13.42 | *** join/#qi-hardware pabs3 (~pabs@d175-38-169-197.per801.wa.optusnet.com.au) |
| 06:27.43 | *** join/#qi-hardware kilae (~chatzilla@109.205.205.99) |
| 06:57.37 | *** join/#qi-hardware jekhor (~jek@46.53.195.142) |
| 08:00.34 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 08:05.49 | qi-bot | [commit] Xiangfu: debian: update email address (master) http://qi-hw.com/p/fped/42a4ade |
| 09:25.53 | *** join/#qi-hardware GNUtoo-desktop (~GNUtoo@host143-91-dynamic.21-79-r.retail.telecomitalia.it) |
| 10:06.32 | *** join/#qi-hardware kilae (~chatzilla@109.205.205.99) |
| 10:07.39 | *** join/#qi-hardware fire_ (~fire@unaffiliated/codingenesis) |
| 10:20.46 | *** join/#qi-hardware porchao (~hato@eatkyo313102.adsl.ppp.infoweb.ne.jp) |
| 10:48.38 | wpwrak | wolfspra1l: (all week) the chinese seem to like their massive holidays :) CNY, this one, ... |
| 11:24.24 | *** join/#qi-hardware lekernel (~lekernel@g225039089.adsl.alicedsl.de) |
| 11:44.02 | *** join/#qi-hardware antoniodariush (~antonio@host-92-2-90-240.as43234.net) |
| 11:46.11 | antoniodariush | Hi, I briked my Nanonote and the instructions for hardware USB boot mode don't really work |
| 11:46.17 | antoniodariush | any advice? |
| 11:47.08 | antoniodariush | i was running usbboot -c "nerase 0 4096 0 0" and then things went wrong and it didn't boot in usbboot mode anymore |
| 11:47.14 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 11:56.04 | wpwrak | usb booting always works ... eventually :) |
| 11:56.13 | wpwrak | which instructions did you use ? |
| 11:56.44 | antoniodariush | hi wpwrak |
| 11:56.49 | antoniodariush | http://en.qi-hardware.com/wiki/USB_BOOT_mode#Hardware_USB_BOOT |
| 11:56.52 | antoniodariush | these |
| 11:57.17 | antoniodariush | and also other similar from other websites and irclogs |
| 12:11.22 | *** join/#qi-hardware heberth (~heberth@190.255.213.214) |
| 12:16.08 | *** join/#qi-hardware paul_boddie (~paulbodd@hfaistos.uio.no) |
| 12:18.40 | paul_boddie | USB boot can be very frustrating. |
| 12:18.54 | antoniodariush | it is |
| 12:19.15 | *** join/#qi-hardware urandom__ (~user@p548A1BC6.dip.t-dialin.net) |
| 12:19.16 | paul_boddie | For the software one, at least, I found that U + reset was often required, rather than U + power. |
| 12:20.32 | kyak | i say, remove the battery and hold U+power while plugging in the USB cable :) |
| 12:22.37 | wpwrak | hmm, the role of the POWER button seems to have been misunderstood in these instructions. if the power button does anything, then some code is already running |
| 12:22.58 | wpwrak | kyak: exactly. that's how it's supposed to work :) |
| 12:23.10 | paul_boddie | Yes, that's why I added a note about U + reset to the Wiki page. |
| 12:23.38 | paul_boddie | Far too often, U + power didn't do anything. |
| 12:24.16 | *** join/#qi-hardware cladamw (~adamwang@host-174.163-235-182.cable.dynamic.kbtelecom.net) |
| 12:24.52 | wpwrak | paul_boddie: U still needs code to be running. so your device can only be lightly bricked is this works |
| 12:25.07 | wpwrak | i mean U in any constellation |
| 12:25.19 | paul_boddie | wpwrak: Yes, that's why software boot won't be enough in this case. |
| 12:25.44 | paul_boddie | antoniodariush: Don't know whether bridging the contact and using hardware reset instead of power helps at all. |
| 12:25.59 | antoniodariush | both ways don't work |
| 12:26.31 | wpwrak | what always works (except in the presence of a major hardware issue) is: 1) remove battery and USB. 2) sit tight for 30 sec. 3) make the USB BOOT contact. 4) while maintaining the contact, connect USB. 5) release and enjoy usbboot. |
| 12:27.05 | wpwrak | hw reset is as good as power. BUT ... it's harder to get it right :) |
| 12:27.38 | kyak | wpwrak: does sw reset do the same as hw reset, but from the sw? :) |
| 12:28.03 | paul_boddie | So, it's better to connect the USB cable while bridging the contact instead of already having power and using the power button? |
| 12:28.04 | kyak | or you get to "different" usbboot from sw? |
| 12:28.20 | antoniodariush | wpwrak: those instructions don't work in my case, i've been here for hours now |
| 12:28.42 | wpwrak | for step 4), this is easier if you connect the cable first on the Ben side, then short USB BOOT, and then plug the cable on the PC side. this way, there's no mechanical action on the side of the ben when plugging in the cable. |
| 12:29.29 | antoniodariush | brb |
| 12:29.33 | wpwrak | paul_boddie: yes. the power button is just another yet without any special hardware function |
| 12:30.47 | paul_boddie | wpwrak: OK. Maybe the Wiki should be updated to say this. I found a few different descriptions of USB boot, and so I tried to consolidate these on the "USB BOOT mode" page. |
| 12:30.58 | wpwrak | kyak: it's probably the same (that is, if the sw reset does a proper reset). but of course, if you can command a sw reset, you're probably in good enough shape for the POWER+U approach :) |
| 12:31.48 | kyak | wpwrak: yes, of course, i was just wondering |
| 12:35.13 | *** join/#qi-hardware he2 (~he2@95-89-130-215-dynip.superkabel.de) |
| 12:37.23 | *** join/#qi-hardware jekhor (~jek@178.121.137.196) |
| 12:37.31 | wpwrak | paul_boddie: this would be a reasonably accurate set of instructions: http://www.mail-archive.com/discussion@lists.en.qi-hardware.com/msg02191.html |
| 12:38.00 | wpwrak | paul_boddie: note the "Iff" before the "U" part :) |
| 12:41.07 | wpwrak | antoniodariush: if you really get stuck, you may also consider soldering a wire to the USB BOOT contacts. that way, you can be sure that you have a good connection. it's okay to keep USB BOOT connected indefinitely after reset (of course, it means that you'll always end up in usb boot mode) |
| 12:41.09 | paul_boddie | Sure. I was just saying that hardware reset + U works in situations where power + U does not. That led me to believe that the power button isn't enough in many cases. |
| 12:41.43 | wpwrak | oh, the power button does almost nothing |
| 12:43.03 | paul_boddie | I guess it's even better to remove all power and use the USB cable to apply power, but I wasn't aware that this would actually perform a reset, although I think I've seen it happen recently. |
| 12:43.25 | wpwrak | a hardware reset is the best, but it can be difficult to command while keeping USB BOOT shorted. power cycling is as effective, provided that you let the machine completely unpowered for ~30 seconds. |
| 12:45.34 | wpwrak | there's a trap with power cycling: if it's too short, then you enter some sort of limbo state from which only a reset (or proper power cycle) recovers. |
| 12:45.54 | wpwrak | hence the 30 seconds rule. (in fact, about 12 seconds should do. but better have a bit of a margin) |
| 12:46.55 | wpwrak | see also: http://lists.en.qi-hardware.com/pipermail/discussion/2011-March/007432.html |
| 12:51.44 | paul_boddie | Does the limbo state involve a ticking sound? I've had that a few times when reflashing didn't work. |
| 12:54.09 | paul_boddie | Should I also change the hardware boot description on the Wiki page? Currently, it talks about the power button. |
| 13:05.55 | wpwrak | (ticking sound) i don't remember hearing such a thing. but that doesn't necessarily mean that it doesn't occur, or maybe only on some devices :) |
| 13:07.00 | wpwrak | (wiki) i think it would be good to avoid mentioning the POWER button. people may be misled to think of it as a power switch, which isn't how it works |
| 13:11.48 | paul_boddie | So it should say (1) disconnect everything and wait, (2) bridge the contacts, (3) connect USB? |
| 13:13.31 | *** join/#qi-hardware erikkugel (~ekugel@216.183.91.254) |
| 13:14.46 | wpwrak | (2) bridge the contacts (and keep them bridged) |
| 13:15.23 | wpwrak | (4) after a few seconds (5 is plenty), you can de-bridge the contacts |
| 13:17.17 | wpwrak | i.e., i think another common misunderstanding is that USB BOOT merely needs a "pulse" (kinda like reset). so i think some people short it briefly, but it's no longer shorted when powering up, and thus has no effect |
| 13:18.49 | wpwrak | it's a bit difficult to tell what specifically goes wrong when people run into trouble. they often try something, which doesn't work, then ask for help. then, after a bit of confusion, someone gives correct instructions. then they try some more, and at some point in time, it suddenly works. be we never quite know what changed to make it work. |
| 13:19.16 | wpwrak | sometimes, it may simply be luck, e.g., when using an unreliable method for shorting USB BOOT |
| 13:21.02 | wpwrak | that's why i think some redundancy on what may be unexpected parts of the process can't hurt :) |
| 13:21.16 | paul_boddie | The problem is that it's difficult to remember what does work, and perhaps the only remedy is to brick a device and then spend lots of time systematically trying to bring it back. |
| 13:23.41 | paul_boddie | I'm guessing LCM means "screen" in the instructions. I didn't change that before. |
| 13:24.14 | antoniodariush | re: |
| 13:24.29 | antoniodariush | i will try again |
| 13:25.51 | antoniodariush | but nothing seems to work |
| 13:26.33 | antoniodariush | and I bricked two nanonotes in the same procedure so cannot be hardware fault cause hardware USB boot fails in both of them |
| 13:27.06 | paul_boddie | I've just updated the page, by the way: http://en.qi-hardware.com/wiki/USB_BOOT_mode |
| 13:27.33 | antoniodariush | paul_boddie: i'll have a look |
| 13:27.34 | wpwrak | antoniodariush: are you sure it doesn't come up in USB boot mode ? i.e., are you checking with lsusb ? |
| 13:27.46 | antoniodariush | wpwrak: yes lsusb |
| 13:27.53 | antoniodariush | does not come up |
| 13:27.58 | viric | how do you bridge? |
| 13:27.58 | antoniodariush | it does with other nanonotes i have |
| 13:28.09 | viric | maybe the contacts are a bit dirty |
| 13:28.13 | viric | or rusty |
| 13:28.16 | antoniodariush | with that carbon thing |
| 13:28.20 | antoniodariush | cleaned |
| 13:28.22 | wpwrak | or worn out ;-) |
| 13:28.58 | viric | where is the usbboot code, btw? in a little memory in the processor? |
| 13:29.48 | antoniodariush | the last command I ran was usbboot -c "nerase 0 4096 0 0" |
| 13:29.58 | antoniodariush | does this mean anything? |
| 13:30.02 | wpwrak | viric: yes, there's some sort of ROM there |
| 13:30.39 | paul_boddie | I also want to dispute this page, too: http://en.qi-hardware.com/wiki/Updating_Ben_NanoNote_software . Booting from a microSD card is much easier than reflashing, and it's probably easier to reflash from within Linux on the NanoNote than to use usbboot. I also found that reflash_ben.sh didn't work where usbboot did. |
| 13:30.53 | wpwrak | antoniodariush: i think that nerase means that you wiped out u-boot. but that's okay. you should be able to recover regardless. |
| 13:31.11 | paul_boddie | Yes, that command apparently erases the entire NAND storage. |
| 13:32.29 | wpwrak | paul_boddie: (http://en.qi-hardware.com/wiki/USB_BOOT_mode) looks good to me. maybe add that it may take few tries because shorting USB BOOT with such ad hoc means is inherently unreliable. |
| 13:33.31 | wpwrak | antoniodariush: if you're confident with a soldering iron, i'd suggest to just add a "hard" bridge for USB BOOT, to get rid of that bit of uncertainty |
| 13:34.25 | antoniodariush | wpwrak: i might consider that |
| 13:35.31 | antoniodariush | brb |
| 13:35.43 | wpwrak | of course, the deluxe solution would be to make an idbg :) alas, i think there are only 2-4 bens in existence that have this kind of luxury |
| 13:36.37 | wpwrak | (idbg is a little pcb with a microcontroller inside the ben that connects to serial console, reset, and usb boot. so you can control all these things via another usb connection. rather convenient ;-) |
| 13:37.41 | wpwrak | http://lists.en.qi-hardware.com/pipermail/discussion/2010-August/004919.html |
| 13:42.31 | *** join/#qi-hardware kristoffer (~kristoffe@c-b6dce555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
| 13:51.10 | qi-bot | [commit] Werner Almesberger: ircstat/ML: update for 7/2012 through 9/2012 (master) http://qi-hw.com/p/wernermisc/8fc01a1 |
| 14:43.04 | *** join/#qi-hardware Ayla (~paul@190.162.199.66) |
| 14:49.40 | paul_boddie | How do you reset the idbg? Is it dongles all the way down? ;-) |
| 14:50.30 | wpwrak | idbg is powered from USB, so if i want to reset it, i just unplug its micro-USB plug |
| 14:50.40 | wpwrak | but in general it is expected to behave ;-) |
| 14:53.05 | wpwrak | its firmware has two parts: the boot loader (which uses DFU) and the "application". flashing the boot loader needs in-circuit programming, which is a little tricky. but you can bootstrap it with a ben with UBB. the ben is very nice for such tasks. |
| 14:54.28 | *** join/#qi-hardware heberth (~heberth@190.255.213.214) |
| 14:54.34 | wpwrak | (i just wish it had a better separation between the internal 3.3 V domain and what goes out to the 8:10 card. it's a bit irritating if powering up an external board causes the ben to reset due to excessive inrush current - just because there are a few caps on the external board.) |
| 15:03.04 | paul_boddie | I'm currently playing with an Arduino (yes, I know!) with USB Host interface in conjunction with the NanoNote. |
| 15:05.53 | wpwrak | that's an odd combination :) |
| 15:07.09 | paul_boddie | Well, I got the USB Host board a while back but never did anything with it, whereas the NanoNote has USB Peripheral mode, so it makes an obvious companion. :-) |
| 15:07.20 | wpwrak | if the goal is to use the AVR as an i/o extender or to control some peripherals, you could perhaps just bit-bang SPI on the 8:10 card slot and hook up the AVR that way |
| 15:07.25 | wpwrak | ah ;-) |
| 15:08.20 | paul_boddie | I guess I would otherwise use a "slimmer" AVR-based board for such experiments, but it's all about the prototyping. |
| 15:09.34 | *** join/#qi-hardware heberth (~heberth@186.115.105.79) |
| 15:09.36 | paul_boddie | It also gives me a bit of experience using the Max3421 stuff on the Arduino. |
| 15:09.57 | paul_boddie | Which I imagine is somewhat portable to other AVR boards, too. |
| 15:11.32 | paul_boddie | Either way, I get to practise my C++ a bit. |
| 15:11.33 | wpwrak | the real challenge would be do adapt v-usb to be USB host :) |
| 15:11.49 | wpwrak | s/do/to |
| 15:11.49 | qi-bot | wpwrak meant: "the real challenge would be to adapt v-usb to be USB host :)" |
| 15:13.57 | paul_boddie | v-usb? |
| 15:14.40 | whitequark | paul_boddie: http://www.obdev.at/products/vusb/index.html |
| 15:15.18 | *** join/#qi-hardware aisa (~a@173-10-243-253-Albuquerque.hfc.comcastbusiness.net) |
| 15:17.40 | paul_boddie | I think I've seen this before! Is the point of it to drive the interface directly using the AVR and thus to avoid a separate controller like the Max3421? |
| 15:18.23 | wpwrak | or a microcontroller with usb hardware (which generally drives up the chip price considerably) |
| 15:19.02 | wpwrak | it's very unusual to have an external usb controller (like a max3421) these days |
| 15:19.32 | whitequark | wpwrak: it doesn't, if that's not AVR |
| 15:19.43 | whitequark | e.g. STM32's are cheaper than AVRs and yet way more powerful |
| 15:20.02 | whitequark | an entry-level STM32F100RB on a $10 devboard can do USB OTG. |
| 15:20.28 | whitequark | *F103 |
| 15:21.19 | paul_boddie | Well, I guess it's like all controllers these days. They become so powerful that they are then potentially more powerful than the designated CPU in a system. |
| 15:22.06 | viric | OTG? |
| 15:22.09 | paul_boddie | It's like a board I have with an LCD controller which is some kind of ARM core and must have more on-core storage than the AVR I'm using it with. |
| 15:22.10 | whitequark | on-the-go |
| 15:22.15 | whitequark | i.e. it can act both as device and host |
| 15:22.21 | viric | ah ok |
| 15:22.39 | whitequark | paul_boddie: stm32 is not a controller, it's basically a simple SoC |
| 15:22.41 | paul_boddie | They could have called it USB one-must-go, just for the laughs. |
| 15:23.02 | whitequark | that is, it's not an USB controller or so. |
| 15:23.17 | whitequark | it's an ARM core with a bunch of really nice peripherals |
| 15:23.52 | paul_boddie | whitequark: Yes, I meant that you get to the point with controllers where you need enough performance and features that you end up using a conventional core, and then you might as well start consolidating functions into a single component. |
| 15:24.45 | whitequark | paul_boddie: I highly doubt that USB in that chip is implemented as a general-purpose CPU core |
| 15:24.50 | wpwrak | whitequark: you probably still have a significant price step between STM with and STM without USB (provided that they even make the latter variant) |
| 15:26.38 | whitequark | wpwrak: well, there aren't variants of the _same chip_ with and without USB |
| 15:27.06 | whitequark | there is basically a 24MHz chip without USB and a 72MHz chip with USB |
| 15:27.07 | *** join/#qi-hardware paroneayea (~user@fsf/member/paroneayea) |
| 15:27.25 | whitequark | the former is 4.79@1, the latter is 7.14@1 at digikey |
| 15:27.43 | wpwrak | and according to the data sheet on digi-key, the STM32F100RB has no OTG |
| 15:27.45 | paul_boddie | I wouldn't really know. I imagine that you'd want some special purpose circuitry for various aspects of it, but then convenience dictates that you might as well do some of the solution with an existing core, and that also opens it up to other convenient features that you can offer developers. |
| 15:28.24 | whitequark | wpwrak: indeed, I corrected myself. the one with USB is F103 |
| 15:28.52 | whitequark | paul_boddie: naw, you already have Verilog. it's way more convenient to design inherently parallel processes without inherently sequental G/P CPU cores |
| 15:29.19 | whitequark | what takes an interesting challenge to fit on a CPU is done with a trivial line in Verilog, not even talking about the resources used |
| 15:29.27 | whitequark | (talking about NRZI decoding here) |
| 15:29.36 | wpwrak | pricy :) still USD 3.50 at volume |
| 15:29.42 | paul_boddie | It becomes like the Telit components where the original intention probably started out with just providing GSM connectivity and ending up with something that you can load Python programs onto, thus abandoning any need for a separate CPU, RAM, and thus the traditional "device logic" part of the system. |
| 15:29.59 | whitequark | wpwrak: they're way more powerful than AVRs |
| 15:30.14 | whitequark | sometimes you don't need that, but more often than not you do |
| 15:30.36 | wpwrak | oh, that's not a challenge :) is there anything SLOWER than AVRs ? ;-) |
| 15:30.44 | whitequark | also, due to a more advanced process, STM32s are significantly more energy efficient, both in sleep and idle :) |
| 15:30.48 | whitequark | hehe |
| 15:30.48 | whitequark | PICs |
| 15:30.51 | whitequark | 4 cycles/op |
| 15:30.58 | whitequark | and the same top freq |
| 15:31.01 | paul_boddie | whitequark: Why would you embed an ARM core into an LCD controller, then? |
| 15:31.28 | whitequark | paul_boddie: because parsing commands from an external controller _is_ a sequental process, and quite a complex one |
| 15:31.49 | whitequark | it just draws to framebuffer. the framebuffer is then displayed on the matrix with a Verilog-written core. |
| 15:31.53 | wpwrak | PIGs in the same price range tend to have faster clocks. not sure about clocks/cycle, though. |
| 15:31.56 | whitequark | *HDL-written, ok |
| 15:32.18 | paul_boddie | I'm going to have to get into this FPGA game at some point, I just know it! |
| 15:32.43 | whitequark | wpwrak: memory banks. who in their right mind would ever voluntarily design or use a chip with memory banks?! |
| 15:33.57 | whitequark | I'm convinced that it's a conspiracy to turn programmers insane |
| 15:34.06 | whitequark | and drive compiler developers to a rage |
| 15:34.26 | wpwrak | whitequark: 8051 holds the record for a messy memory architecture :) |
| 15:34.58 | wpwrak | M8C isn't too bad either, though. i like the symmetry of their instruction set, though. but they're dead anyway. |
| 15:35.12 | whitequark | wpwrak: 8051? I thought it was pretty ancient, but not really arcane |
| 15:35.15 | whitequark | could you elaborate? |
| 15:35.28 | wpwrak | they have "internal" and "external" memory |
| 15:36.01 | wpwrak | of course, anything remotely modern has the "external" memory also inside |
| 15:36.27 | wpwrak | but they're still treated differently. may even be different instructions, but i'm not sure about that. |
| 15:36.46 | wpwrak | luckily, we have compilers to worry about that :) |
| 15:36.46 | *** join/#qi-hardware emeb (~ericb@ip72-201-79-123.ph.ph.cox.net) |
| 15:37.02 | whitequark | oh |
| 15:37.19 | whitequark | well, pic8 is so bad that there isn't even a gcc port |
| 15:37.23 | whitequark | there was sdcc, but it died |
| 15:37.32 | whitequark | and it didn't produce code which is any good anyway |
| 15:38.25 | whitequark | oh, it actually is still alive |
| 15:38.55 | wpwrak | pic18xxx seems to be reasonably well supported by sdcc |
| 15:39.21 | whitequark | yep |
| 15:39.26 | whitequark | sdcc actually works |
| 15:39.41 | whitequark | this doesn't change the fact that underlying architecture absolutely sucks. |
| 15:39.51 | whitequark | just imagine doing bitbanging with memory banks |
| 15:39.54 | wpwrak | one galling problem is that there are no gpl-friendly register definitions. they pick the stuff from microchip's proprietary devel kit making the resulting headers non-Free |
| 15:40.22 | wpwrak | oh, the memory banks may be the least of your worries ;-) |
| 15:41.24 | wpwrak | for real fun, try programming the critter in assembler. the branch instructions are somehow triply-negated. (if this isn't that, then don't skip the next instruction, which will be the thing that actually does what you want to be done. or such.) |
| 15:42.03 | wpwrak | i basically gave up and tried one way and if it didn't work, the other way. that was quicker than processing all the negations in my head. |
| 15:42.11 | whitequark | wpwrak: I tried. |
| 15:42.15 | whitequark | it was my first MCU ever. |
| 15:42.20 | whitequark | pic18f628a |
| 15:42.44 | whitequark | well |
| 15:42.45 | wpwrak | PIC12something there :) |
| 15:42.57 | whitequark | if I will ever meet someone loosely related to developing PICs |
| 15:43.23 | whitequark | and there will happen to be something sharp enough nearly |
| 15:43.27 | wpwrak | 12F629 to be precise. one is still doing important work in my lab :) |
| 15:43.28 | whitequark | like a perfectly round steel ball |
| 15:44.02 | wpwrak | so you'll go nuernberg, but without trial ? :) |
| 15:44.38 | whitequark | kind of :) |
| 16:09.10 | antoniodariush | wpwrak: I got one working finally :) |
| 16:09.49 | antoniodariush | by just using the cambonized rubber button |
| 16:10.37 | antoniodariush | it's quite hard to get it done |
| 16:10.57 | wpwrak | congratulations ! :) |
| 16:16.55 | *** join/#qi-hardware xiangfu (~xiangfu@123.115.7.153) |
| 16:19.57 | paul_boddie | Was the described procedure accurate, or do we need to refine it further? |
| 16:26.11 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 16:26.56 | antoniodariush | paul_boddie: the procedure in the wiki is good, but perhaps you can have a paragraph to explain what to do if it doesn't work |
| 16:27.15 | antoniodariush | like clean the USB boot pin |
| 16:27.37 | antoniodariush | clean the carbonized rubber button |
| 16:27.43 | antoniodariush | (which is what I did as well) |
| 16:30.05 | paul_boddie | OK. What to do if it doesn't work is perhaps the hardest part to write. ;-) |
| 16:34.15 | antoniodariush | finally, and the second nanonote is fixed as well |
| 16:35.17 | antoniodariush | had to clean the pins and the rubber button thoroughly |
| 16:36.09 | antoniodariush | i read somewhere that it can be cleaned with some alcohol |
| 16:37.10 | antoniodariush | didn't try that but can be useful info for the wiki |
| 16:41.42 | antoniodariush | thanks a lot for your support guys :) |
| 16:42.02 | paul_boddie | I think I read the bit about the alcohol somewhere, too. Must try and find that. |
| 16:42.35 | kristianpaul | need fo fix its nanonote LCM broken "cable connector" on the board |
| 16:42.42 | kristianpaul | i could glue but.. |
| 16:42.53 | kristianpaul | and tape works but get loose.. |
| 16:44.24 | antoniodariush | paul_boddie: is only mentioned in the IRC logs http://en.qi-hardware.com/irclogs/qi-hardware_2010-09-26.log.html#t09:13 |
| 16:44.49 | paul_boddie | I found it on the Wiki, too, on the Unbrick page. |
| 16:44.58 | antoniodariush | awh |
| 16:45.58 | paul_boddie | It's now mentioned on the USB BOOT page. |
| 16:46.00 | *** join/#qi-hardware urandom_ (~user@p548A1BC6.dip.t-dialin.net) |
| 16:46.45 | *** join/#qi-hardware pabspabspabs (~pabs@d175-38-169-197.per801.wa.optusnet.com.au) |
| 16:47.14 | antoniodariush | paul_boddie: I tried the unbrick page of the wiki, at that point I've almost gave up heheh |
| 16:47.28 | antoniodariush | bacause is a bit confusing |
| 16:49.21 | wpwrak | ah, mild detergent. so i guess boiling concentrated sulphuric acid is out :) |
| 16:49.42 | *** join/#qi-hardware woakas (~woakas@186.28.162.226) |
| 16:50.04 | antoniodariush | bacause there is the possibility that nothing happens when the Power button is pressed but u can load the USB BOOT, in my case I could not even load the USB boot |
| 16:50.11 | wpwrak | alcohol is pretty much THE universal solvent/cleaner for electronics. it's safe with virtually everything. |
| 16:50.16 | antoniodariush | so what is the definition of "bricked"? :) |
| 16:50.43 | viric | wpwrak: unless if it's very hot :) |
| 16:51.35 | wpwrak | viric: mulled wine ? ;-) |
| 16:51.44 | viric | no no :) hot electronics heeh |
| 16:52.01 | viric | as for electronic contacts, I found that a pencil eraser cleans very well too |
| 16:52.28 | wpwrak | ah :) well, up to some point, alcohol can act as a coolant, too. beyond that point, though, it has the opposite effect |
| 16:52.31 | paul_boddie | There's quite a range from mild detergents to concentrated sulphuric acid, though. |
| 16:52.38 | viric | wpwrak: exactly |
| 16:54.35 | wpwrak | regarding what to do when it doesn't work. i guess words of encouragement are in order. like "don't give up". or "trust our instructions. we know what you're doing." |
| 16:55.22 | paul_boddie | wpwrak: An opportunity for you to make a nice video tutorial? |
| 16:55.38 | wpwrak | perhaps not ;-) |
| 16:56.30 | wpwrak | my bens boot just fine. and the one that does get an unusual amount of abuse from time to time has idbg installed :) |
| 16:57.59 | wpwrak | considering all the unbricking sessions we've had here already (must be dozens by now), it's always persistence that finally wins the day |
| 16:59.19 | wpwrak | what basically happens is that the number of tries needed to succeed tends to greatly exceed what people expect before feeling certain that the device is dead |
| 17:01.29 | wpwrak | it's a bit like a medical doctor having a patient die on them, all the resuscitation attempts failing, then the doctor going back home, getting a good night's sleep, then coming back the next day, and, after some more hours of seemingly futile if not crazy work, finally bringing the corpse back to life. |
| 17:03.17 | wpwrak | (and making a full recovery, living happily ever after, etc.) |
| 17:34.38 | *** part/#qi-hardware paul_boddie (~paulbodd@hfaistos.uio.no) |
| 17:50.08 | *** join/#qi-hardware jluis (~jluis@2001:5c0:1000:a::769) |
| 18:00.27 | *** join/#qi-hardware fire_ (~fire@unaffiliated/codingenesis) |
| 18:14.25 | *** join/#qi-hardware viric (~viric@unaffiliated/viric) |
| 18:39.30 | *** join/#qi-hardware xdpirate (~xdpirate@213.138.174.137) |
| 18:44.55 | *** join/#qi-hardware Aylax (~Aylax@nat-wifi-alumnos.campus.utfsm.cl) |
| 19:02.04 | *** join/#qi-hardware lekernel (~lekernel@f052071117.adsl.alicedsl.de) |
| 20:16.25 | whitequark | check out these lithium batteries |
| 20:16.26 | whitequark | http://www.buyincoins.com/new_en/details/1-x-uf-18650-3-7v-rechargeable-battery-4000mah-with-tab-product-3059.html |
| 20:29.58 | *** join/#qi-hardware jekhor (~jek@46.53.195.142) |
| 21:38.45 | *** join/#qi-hardware dandon (~dandon@88.151.75.56) |
| 21:46.12 | *** part/#qi-hardware erikkugel (~ekugel@216.183.91.254) |
| 21:59.11 | *** join/#qi-hardware heberth (~heberth@190.6.162.167) |
| 22:03.23 | *** join/#qi-hardware Aylax (~Aylax@190.162.199.66) |
| 23:01.21 | *** join/#qi-hardware porchao (~hato@eatkyo313102.adsl.ppp.infoweb.ne.jp) |