Topic for #qi-hardware is now Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #qi-hardware
qwebirc47082 [qwebirc47082!4766dbba@gateway/web/freenode/ip.71.102.219.186] has joined #qi-hardware
<rjeffries>
reading the backlog, interesting to see the effort to identify USB mice that work ok w MM1. How much work will it take to improve USB driver so this hand matching is not required?
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
<wpwrak>
it will always be required. you'll just get fewer problem cases :)
<wpwrak>
think of it more as of a regression test: we want to be sure the things that work keep on working. that's why it's good to keep track of them.
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
<rjeffries>
wpwrak with great respect <g> do you think PC makers need to test random USB mice against their new builds? The answer is "no" they have USB ports that meet the standard.
<wpwrak>
well, if you give us one of those fancy test systems ... :)
<wpwrak>
or you can help with the work towards getting linux to run properly. that would also solve a number of usb issues.
<wpwrak>
don't have a usb tester ? no chip design or kernel hacking skills either ? no problem. a modest donation of only a few 100 kUSD would bring us a lot closer to being able to focus the next year or so on polishing things without the need to have anything that can actually be sold
xiangfu [xiangfu!~xiangfu@123.114.251.251] has joined #qi-hardware
<rjeffries>
wpwrak you speak with great eloquence sir. one hopes most mice past the test. this problem will solve itself in any case. move along folks, nothing to see here. ;)
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
xiangfu [xiangfu!~user@123.114.251.251] has joined #qi-hardware
<DocScrutinizer>
wpwrak: USB zeszer? no problem, I'm sure I could use the one on the desk of my colleague on weekend. Missing any hw to test though
<DocScrutinizer>
s/zeszer/tester/
<qi-bot>
DocScrutinizer meant: "wpwrak: USB tester? no problem, I'm sure I could use the one on the desk of my colleague on weekend. Missing any hw to test though"
<DocScrutinizer>
btw it's a cheesy little plastic box almost as ugly and cheapish as the Lauterbach ;-D
<DocScrutinizer>
meanwhile: it's kinda nice we see a new user of either N900 or GTA02 every other week lately. You could almost say open phone idea slowly gains a microscopic momentum again
* DocScrutinizer
makes mental note to start watching a few ebay auctions on weekend, to get his spare spare N900
<DocScrutinizer>
also a few keymats (they are really suffering from wear and tear)
jluis [jluis!~jpddb@83.247.136.72] has joined #qi-hardware
<roh>
DocScrutinizer: rather shop 6110... still real phones
<DocScrutinizer>
meh
<DocScrutinizer>
I'm indeed missing a "real phone" since all my 5pcs 6210 burnt down in that apartment fire before I joined OM
<DocScrutinizer>
but I'd rather buy some osmocom-bb compatible Cxxx than 6210. I guess I'll get a few 6210 again as gifts over time
<roh>
DocScrutinizer: hrhr
<roh>
i am still using my moto v3i
<DocScrutinizer>
ooh, actually there's still my "original" 6210 that served me right for almost 10 years
<DocScrutinizer>
just the battery is dead now
* DocScrutinizer
killed that battery by not recharging it for >12 months :-S
<roh>
reminds me.. i should charge the moko stuff from time to time again
<DocScrutinizer>
yeah, same here. Again 6 months since I last did
* DocScrutinizer
considers building a long term Li battery maintenance rack
<DocScrutinizer>
with a hundred slots with adjustable contacts
<roh>
i guess a cheap third market charger and a lot of relays would be enough
<DocScrutinizer>
well, not relays, too expensive. MOSFETs
<roh>
too fishy to get the charging logic not confused :)
<DocScrutinizer>
meh, what logic ;-D
<roh>
thermistor etc
<DocScrutinizer>
aaah, no way
<DocScrutinizer>
CC/CV
<roh>
i dont like unattended charging without thermistors anymore
<DocScrutinizer>
I.E a stabilized digitally controlled PSU with a series resistor
<DocScrutinizer>
I'll build the thermistorsa into the rack's slots
<roh>
well.. holler if you have something working
<DocScrutinizer>
:nod:
<roh>
i guess printing the battery holders with a 3d printer will be easy
<roh>
as in mill board, solder pogo/spring loaded connector, screw printed plastic frame on top or so
<DocScrutinizer>
the contacts and slots are the worst of the whle thing
jekhor [jekhor!~jek@leased-line-46-53-195-130.telecom.by] has joined #qi-hardware
<DocScrutinizer>
considering I want it to be universal, mechanically
<roh>
well... swap holder depending on type/series
<DocScrutinizer>
thought about getting 2 or 3 basically different universal holder designs
<DocScrutinizer>
or using Lego ;-D
<roh>
design em in openscad, send me the file
<DocScrutinizer>
k
Artyom [Artyom!~chatzilla@h6.net58.bmstu.ru] has joined #qi-hardware
Textmode [Textmode!~boneidle@adsl-syd-2-209.ozonline.com.au] has joined #qi-hardware
<Artyom>
Looks interesting. (At least for me). Especially untraditional SATA connector and cable usage for transfering high LVDS signals
<DocScrutinizer>
umm
DocScrutinizer [DocScrutinizer!~halley@openmoko/engineers/joerg] has joined #qi-hardware
mstevens [mstevens!~mstevens@ceres.etla.org] has joined #qi-hardware
mstevens [mstevens!~mstevens@fsf/member/pdpc.active.mstevens] has joined #qi-hardware
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #qi-hardware
<qi-bot>
Campus Sebastian: http://t.co/4EzeXhGw @mkroberson @Tiffany_Qi_T2K @qihardware ( 162825944871075841@campusl6 - 56s ago via web )
<wolfspraul>
Artyom: thanks a lot for the link!
<wolfspraul>
Artyom: if you find any interesting blogs, feeds, projects - especially if they are not in the Qi planet yet - please post here
<Artyom>
ok ;)
<wpwrak>
DocScrutinizer: (usb tester) hmm, conformance tester or just protocol analyzer ? the latter are more common. there's some windows usb compliance test that's reasonably popular. not entirely sure what it entails. i read often of people referring to it, but nobody actually having used it ;-)
<wpwrak>
DocScrutinizer: (charger with hundreds of slots) we don't know what burnt down your last apartment but we have an idea what will burn down the current one ;-)
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #qi-hardware
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #qi-hardware
dvdk [dvdk!~dvdkhlng@g225033008.adsl.alicedsl.de] has joined #qi-hardware
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #qi-hardware
fossrox [fossrox!~fossrox@unaffiliated/fossrox] has joined #qi-hardware
antoniodariush [antoniodariush!~antonioda@nat-sta-smtc2.tvu.ac.uk] has joined #qi-hardware
jivs [jivs!~jivs@nat-sta-smtc2.tvu.ac.uk] has joined #qi-hardware
mstevens [mstevens!~mstevens@fsf/member/pdpc.active.mstevens] has joined #qi-hardware
jirkab [jirkab!~root@pclph406g.vsb.cz] has joined #qi-hardware
jekhor [jekhor!~jek@mx2.promwad.com] has joined #qi-hardware
Ayla [Ayla!~paul@254.135.123.78.rev.sfr.net] has joined #qi-hardware
antoniodariush [antoniodariush!~antonioda@nat-sta-smtc2.tvu.ac.uk] has joined #qi-hardware
wolfspra1l [wolfspra1l!~wolfsprau@p5B0AD3D2.dip.t-dialin.net] has joined #qi-hardware
antoniodariush [antoniodariush!~antonioda@nat-sta-smtc2.tvu.ac.uk] has joined #qi-hardware
<qi-bot>
Pinguins Móveis: Pinguins Móveis 24x7 já saiu! http://t.co/A8NShcjv ▸ Principais notícias de hoje via @motorola_br @diariodoandroid @paulobrien @qihardware ( 162911276647989249@pinguinsmoveis - 54s ago via Paper.li )
woakas [woakas!~woakas@pcsp174-30.supercabletv.net.co] has joined #qi-hardware
Textmode [Textmode!~boneidle@adsl-syd-2-209.ozonline.com.au] has joined #qi-hardware
paroneayea [paroneayea!~user@fsf/member/paroneayea] has joined #qi-hardware
<whitequark>
wut
B_Lizzard [B_Lizzard!~havoc@athedsl-428276.home.otenet.gr] has joined #qi-hardware
<dvdk>
whitequark: btw got the money
<dvdk>
thx
<whitequark>
well, it's my bad that half a year has passed...
<dvdk>
not that i needed the money anyways :) btw how did you route the payment via wolfspraul?
* dvdk
closed down his paypal account before christmas, BTW
<whitequark>
he uses some credit card processing service, and while I do not have an actual credit card, I have an account in a Russian virtual money service Qiwi (not sure how this is actually called in English), I was able to transfer the money to him
<whitequark>
(qiwi) you have a "virtual wallet" which can you place money into with a terminal (think deposit-only ATM), which they have all over the city in almost impossible quantities
<whitequark>
then you can pay on the websites which support this system directly or through gateways
<dvdk>
interesting: the virtual wallet thing. who needs physical credit carts anyways?
<dvdk>
s/carts/cards
<qi-bot>
dvdk meant: "interesting: the virtual wallet thing. who needs physical credit cards anyways?"
<whitequark>
recently, they've added a virtual credit card service. you click a button, then pay $0.3 and instantly get a virtual credit card number
<whitequark>
easily disposable
<dvdk>
uh, even disposable. hmm, maybe there's something special about using credit cards with russian websites :)
<whitequark>
that's Visa btw, and every e-shop I ever bought something in accepted it
<whitequark>
eve digikey (sic!)
<whitequark>
s,eve,even,
<whitequark>
even more recently, they've added a plastic card service, which is still linked to the "virtual wallet"
<whitequark>
so you can retrieve your money back from the system
<whitequark>
(it _was_ possible before, but it was quite hard -- you were required to go to a special center -- and inconvenient)
<whitequark>
and now you can use any ATM (they'll collect 1.5% through)
<whitequark>
ah, one more thing
losinggeneration [losinggeneration!~quassel@71-34-161-176.desm.qwest.net] has joined #qi-hardware
<whitequark>
you actually need exactly one thing to register a Qiwi wallet -- a working mobile phone number
<whitequark>
no paperwork, no passport scans, it's instant and practically anonymous
<dvdk>
sounds very convenient
<whitequark>
you need to provide _some_ name and address when registering Visa cards, but they do not actually attempt to verify that
woakas [woakas!~woakas@pcsp174-30.supercabletv.net.co] has joined #qi-hardware
<whitequark>
I wonder which kinds of fraud can you commit with that and how long will it live the way it is
<whitequark>
but yes
<whitequark>
it is incredibly convenient
<whitequark>
there are some limits, like most payments are limited by $500 a time (not Visa ones, through)
<whitequark>
still very godo
<whitequark>
s,godo,good,
<whitequark>
crappy ssh link :/
<whitequark>
am I correct that there exists a working combination of software and hardware at #qi that implements a 802.15.4 WPAN, and that this combination is Ben+(whatever that atrf thingy was called) ?
<larsc>
for certain defintions of working ;)
<larsc>
but i don't know the details
<larsc>
wpwrak is the person you want to talk to
woakas [woakas!~woakas@pcsp174-30.supercabletv.net.co] has joined #qi-hardware
<whitequark>
wpwrak: ok, that's fine for me. Where can I buy two atbens, atusb and a NN? Preferably in a single package delivered by something like fedex.
<whitequark>
(where) I've seen the discussion about current state of tuxbrain above, hence the question
emeb [emeb!~ericb@ip72-223-81-94.ph.ph.cox.net] has joined #qi-hardware
<wpwrak>
(buy) hmm, i'd still try tuxbrain. else, maybe pulster.
<whitequark>
hm
<whitequark>
pulster is significantly more expensive than tuxbrain
<whitequark>
wpwrak: do you know if XBee's are free hardware?
<wpwrak>
seems only the interface boards, but not the xbee itself
<whitequark>
aha.
<wpwrak>
(zoom.html) fixed. thanks !
<whitequark>
so I'll go buy that stuff, and then explain what I want to do with it
<wpwrak>
hehe, ok :)
<qi-bot>
[commit] Werner Almesberger: web/Makefile: also upload zoom.html (reported by Peter Zotov) (master) http://qi-hw.com/p/ben-wpan/a642bfa
<qi-bot>
[commit] Werner Almesberger: Merge branch 'master' of projects.qi-hardware.com:ben-wpan (master) http://qi-hw.com/p/ben-wpan/762d33c
antgreen [antgreen!~user@70.50.65.30] has joined #qi-hardware
<whitequark>
re
<whitequark>
Que hay en mi Cesta?
<whitequark>
Tu Cesta de la Compra esta vacia!
<whitequark>
I don't know what this means, but I hope that it is "your payment was successful"
<larsc>
hehe
<larsc>
looks more like "your shopping cart is empty"
<wpwrak>
it means: "what's in my shopping cart ?" "your shopping cart is empty!"
<whitequark>
ah yes, fine then
<whitequark>
okay
<whitequark>
I think I've already told what do I want to do: a home automation system implemented as a wireless network of simple specialized devices on a common platform
<wolfspra1l>
Bruce Perens says "Qi is interesting, but will be important if they ever manage to break out of being a nerds-only product."
<wolfspra1l>
fair enough Bruce, only that you miss the fun of being part of it :-)
<kristianpaul>
oh, nice
<kristianpaul>
expect nerd part ;)
roh [roh!~roh@yamato.hyte.de] has joined #qi-hardware
larsc [larsc!~lars@eisbaer.ursus-maritimus.org] has joined #qi-hardware
zumbi [zumbi!~zumbi@77.224.206.23] has joined #qi-hardware
AwAyla [AwAyla!~paul@254.135.123.78.rev.sfr.net] has joined #qi-hardware
uwe_ [uwe_!~uwe_@dslb-088-066-186-052.pools.arcor-ip.net] has joined #qi-hardware
panda|x201 [panda|x201!~hzhang@221.219.114.76] has joined #qi-hardware
<wolfspra1l>
I can understand the sentiment though, products need to become more polished, easier to use.
losinggeneration [losinggeneration!~quassel@71-34-161-176.desm.qwest.net] has joined #qi-hardware
paroneayea [paroneayea!~user@fsf/member/paroneayea] has joined #qi-hardware
<whitequark>
>Arduino has some down sides. It does not use a 32-bit processor, so it cannot run complex software (like Linux, for example)
<whitequark>
ahem
<wpwrak>
whitequark: (home automation) sounds great :) i have such idea pending, too. never moved beyond general ideas, though.
<whitequark>
>Bruce waved around a DSO Quad, a pocket-sized digital storage oscilloscope. <...> one does not need a large corporation to create compelling mobile products
<wpwrak>
wolfspra1l: all press is good press ;-)
<whitequark>
while the statement about large corporations is valid, DSO Quad isn't the best example...
<whitequark>
and the statement about arduino and 32-bit cpus is just stupid
<wolfspra1l>
that's not really press, he did not mention Qi in his talk, but aware of it like most serious foss people
<wolfspra1l>
Google sent me a free 75 EUR adwords coupon, nice. I will use it for Milkymist
<wolfspra1l>
I will try things like video synthesizer, instrument, reconfigurable computer
<kristianpaul>
ha, adwords words race :)
<whitequark>
wpwrak: (home automation) I'll continue on that
<wpwrak>
funny. ads on that article on lwn: rambus and "global IP law group"
<kristianpaul>
whitequark: check mirko work around light control using 433mhz tranceivers, prerry interesting
<wolfspra1l>
oh I don't expect much good, but I've never used adwords and if they send me this free coupon, I'll throw it right back, why not
<kristianpaul>
or may be he also have some others plans, since the wireless network is almost ready to be implmented with more appliances i guess
<wpwrak>
interesting fusion of "very" and "pretty". is there "prey" in there as well ? :)
<whitequark>
I currently want to do basically three types of devices. First is basically a SSR, possibly with current measurement. I will use it to control light and wall sockets.
<wpwrak>
whitequark: how do the devices get power ?
<whitequark>
Second is a sensor acting as a switch. It may have more applications than I currently think of, but basically it's a replacement for a convenient switch. Why "sensor"? I think I want to try two variants, first as a conventional mechanical switch and second as a sensor one, by several reasons. Second one is more promising for me
<whitequark>
(power) I'm currently exploring how hard it is to get power from the 220V grid which is already there
<wpwrak>
good :)
<whitequark>
power supplies are harder than I thought
<wpwrak>
yes ;-)
<whitequark>
do you have any experience on that?
<wpwrak>
particularly if you don't have a lot of room and need more than 1-2 mA
<whitequark>
exactly
<wpwrak>
no. that's why my project didn't move
<whitequark>
and at the moment, I cannot say that I know how to do it...
<whitequark>
especially to make it safe and efficient
<whitequark>
(I'll finish on the device types) Third is an environment sensor. Humidity (to detect bathroom floods), gas, smoke etc. Some of them may very well be self-powered. I am quite sure that with right components and firmware a 3V lithium battery can last for months, if not years
<wpwrak>
what i'm looking for is: 1) user terminal (button, some indicators) 2) triac to switch lamps. must work with CFL.
<whitequark>
well, I basically want the same
<wpwrak>
the terminals would go where the light switches are. the triacs could either be on the same board (since the cables pass there anyway, most of the time), or go next to the lamps
<wpwrak>
i also want the terminal to be able to alert me when someone presses the doorbell or such
<whitequark>
yeah
<wpwrak>
(env sensor) yeah, that one can stay passive and maybe just ping the central once a day to indicate that it's still alive
<whitequark>
yes
<whitequark>
for phy/mac layer, I'll use 802.15.14 and I hope I find some upper level protocol to not reinvent the wheel
<whitequark>
the network must be point-to-point
<whitequark>
if I have two separate nodes with switch and a triac, the switch node should directly turn on the triac
<whitequark>
not relying on some central server
<wpwrak>
you probably need a mesh. but protocol issues are easy to solve. (well, from my pov :)
<whitequark>
yes, I don't see that as a hard task
<whitequark>
just the one which needs to be done right
<wpwrak>
(switch to triac) yup. sitting in the dark when the pc crashes sucks ;-)
<whitequark>
then, I want a control panel on which I could see the plan of entire network, sensor states, and maybe have more controls on the overall system
<whitequark>
like "switch to the 'owner absent' mode", etc.
<wpwrak>
you could use a ben for that
<wpwrak>
probably cheaper than building from parts
<whitequark>
actually, I want to get a device with touchscreen and hang it on a wall
<whitequark>
cost issues are not that significant for me anymore, as I've found a good job
<wpwrak>
touchscreen is trickier
<wpwrak>
;-))
<whitequark>
I could buy an ipad, if only it wasn't an Apple anal probe
<whitequark>
some cheap chinese android tablet would work perfectly
<wpwrak>
cap is usually around 2x the price of resistive
<whitequark>
hm
<whitequark>
well, maybe
<whitequark>
I don't need multitouch here anyway, I think
<wpwrak>
yeah, that would be a tad excessive ;-)
<whitequark>
at last, I want to have a piece software to configure the entire network: generate a config for terminals, OTA firmware for sensors, upload it, etc. I hope to reuse some FOSS SCADA system here, but I'm not sure if that will work.
<whitequark>
of course, I prefer the whole stack to be as free as possible: only OSS and OSHW.
<whitequark>
I won't trust some proprietary system to take control of my home
<DocScrutinizer51>
\o/ 30 lines of code today, first time in this ugly environment and also first time after 12 months. And only one missing ; then it 'just worked'
<wpwrak>
;-))
<whitequark>
wpwrak: on the hardware part, I think this will work the best: 1) a power supply as a separate block, yet to be found 2) a radio module aka atben with the SD part cut off and replaced by a pinhead 3) a customized mainboard
<whitequark>
mainboard will be based on STM32. Sorry Arduino fans, STM32 has significantly better power and cost efficiency.
<whitequark>
I've seen an example when a single low-power STM32V was displaying a counter on monochrome glass LCD display for several hours
<whitequark>
it was powered by an apple
<whitequark>
not that cupertino company, but a fruit
<whitequark>
you know, copper and zinc electrodes
<wpwrak>
(stm32) power doesn't matter. your supply needs to be able to provide a few mA anyway.
jekhor [jekhor!~jek@leased-line-46-53-195-130.telecom.by] has joined #qi-hardware
<wpwrak>
(rf) once the thing matures, you can also just integrate the RF circuit into your design.
<wpwrak>
the power supply is the tricky bit ;-)
<wpwrak>
also, you probably want to be able to squeeze this into the little boxes in the wall that currently contain the light switches, right ? about 5 x 10 cm
mstevens [mstevens!~mstevens@fsf/member/pdpc.active.mstevens] has joined #qi-hardware
<whitequark>
wpwrak: (power) it does matter for standalone sensors. anyway, STM32 is a vastly better controller than any ATmega.
<whitequark>
(rf) that can be tricky. I have no equipment to work with RF and it's still too expensive for me AFAIK
<whitequark>
(little boxes) yes
<whitequark>
(the power supply) yes. I'll ask a quesion on StackExchange.EE, and I'll try to find a ready one
<whitequark>
if I could find one that is made with accessible components (no custom transformers, etc.), I think that I can reverse-engineer it. Not sure how sensible is this, through, but at least it may give me some ideas
<DocScrutinizer>
those little boxes are round here
<whitequark>
here too
<whitequark>
the RF module is very small. STM32's are also not known for their large cases. power supply is the worst part
<wpwrak>
yes, power and shielding effects should be the worst bits
<whitequark>
I wonder what maximal current do we need
<whitequark>
certainly no more than 50mA
<whitequark>
@3.3V
<whitequark>
5mA should be enough for CPU; RF part is in range of 12mA if I remember that correctly
<whitequark>
there is also SSR and leds
B_Lizzard [B_Lizzard!~havoc@athedsl-428276.home.otenet.gr] has joined #qi-hardware
<roh>
whitequark: vastly better depends on what you wanna do.
<roh>
e.g. if you need precise bitbang timing, arm usually is worse than avr due to a muxed io bus (no full cpu core speed io possible on arm)
<roh>
so there is no 'cpu a is better than cpu b'. it _always_ depends on the specific usecase what is more reasonable and what not.
<wolfspra1l>
hey that's why we work on Milkymist
<wolfspra1l>
because I fully agree with roh, and in all the thousands of exciting embedded computing products we will want to have in the future, it will only be true even more
<wolfspra1l>
you pick a CPU for a project, you start working, and inevitable one day will be the 'big oh day'
<wolfspra1l>
then it gets interesting :-)
<roh>
hey wolfspra1
<roh>
l
<wolfspra1l>
;-)
<DocScrutinizer>
hi!
<whitequark>
roh: hm, interesting
<whitequark>
anyway, I only meant "vastly" in the context of this project, and not as a general statement
* roh
doesnt like generalisations on technology. there is always 'the right kind' for 'the right problem' .. but not one tech. which is solves all kinds of problems.
<wpwrak>
(milkymist) and you'll never get a custom PWM that's as precise as one you synthesize in an FPGA ;-)
<whitequark>
(through I do think that they are generally better than AVRs in most of the cases where AVRs are used, _if_ you ignore: a) compatibility b) absence of ARMs in DIP c) as you've noted, precise bitbanging d) maybe more, but not much.)
<wpwrak>
(besides, best of luck finding a device with a combined pwm and led matrix controller :)
<roh>
i dont like arm because the io is usually much more crappy
<whitequark>
define "io" ?
<roh>
i really like the avr io banks.
<roh>
io. gpio, usarts, etc.. everything NOT a cpu core
<whitequark>
well, then you should definitely take a look at stm32
<roh>
arm has _really_ crappy ones.
<roh>
also stm.
<whitequark>
hm
<roh>
stm sucks even more when it comes to pricing and packages.
<whitequark>
what do you not like in STM IO?
<roh>
i usually use arm when its 'grown up'., means arm9, arm11 cores WITH mmu.
<roh>
if i dont need an mmu, i dont need a such fast cpu usually.
Greer [Greer!~greer@gateway/tor-sasl/greer] has joined #qi-hardware
<whitequark>
(pricing) I'm not sure about %countrynamehere%, but here in Russia I know a real company which assembles, locally, atmega-based devices. And Atmel pricing sucks a whole lot compared to STM in practically every place you can get both kinds of controllers here.
<whitequark>
like 3 times more
<roh>
means i use arm when i need a full fledged os and i can run linux on the cpu. smaller stuff i usually always solve with avr stuff..
<wpwrak>
pigs seem to be pretty cheap. if you can stand the smell :)
<whitequark>
wpwrak: do you hate STM too?
<roh>
around here a phillips i2c io expander is more expensive than a avr cpu which can do the same and much more.
<wpwrak>
i haev no opinion on STM. haven't looked at them for a while
<roh>
so guess what people use to get more gpio from i2c? not a pcfxxx chip
<whitequark>
roh: I still want to hear what's so wrong with stm ios
<roh>
wpwrak: well.. same as the lpc stuff.. boring small arm cpus with 'another io paradigm again'
<wpwrak>
ARMs used to have overly picky power supply requirements. but maybe this has changed.
<whitequark>
because I worked with both stms and atmels, and I don't quite understand your point
<roh>
whitequark: whats wrong? with arm? usually the manufacturer mostly. even atmel fails on arm.
<roh>
e.g. initial bootloader. its a _mess_
<whitequark>
wpwrak: (arms) atmels can work with 12V Vcc, heating like an iron. I don't really need that modus operandi, so again, I'm fine with stm
<wpwrak>
fwiw, i'm not too fond of avr either. too many legacy quirks for my taste.
<whitequark>
roh: not generally with ARM, of course. LPCxxxx's are quite crappy
<whitequark>
roh: I want to know what's particularly wrong with STM compared to atmels.
<roh>
regardless if you look at SAM-BA, broken dfu implementations, crappy shit emulating fat-fs on usb on lpc or whatever.
<wpwrak>
whitequark: i was more thinking of variable supplies like a battery
<roh>
whitequark: i havent seen a single decent small arm cpu.
<roh>
and i have them all around.
<wpwrak>
whitequark: and many arms even need separate core and i/o. but again, maybe they fixed this for the embedded ones.
<whitequark>
wpwrak: stm32f only needs a single 3.3v supply
<wpwrak>
roh: all that looks like software problems :)
<wpwrak>
whitequark: does it have to be exactly 3.3 V ? or can it be, say, 5 V ?
<roh>
the 'magic' of avr is their extemely good io, and that they are extremely easy to get up and running (in sw as well hw).
<whitequark>
roh: if you have problems with that, just write your own bootloader. you'd do that on AVR anyway.
<roh>
wpwrak: no. it would be sw but the arm bootloaders are in a ROM page they map into their memory on boot depending on the bootmode pins
<roh>
whitequark: people do that. i just use cpus which NOT make me puke on trying to boot.
<whitequark>
wpwrak: it works on 2.0 to 3.6V
<wpwrak>
i think their magic is that they have a decent free toolchain ... and that they're popular ;-)
<roh>
wpwrak: that too.
<roh>
without gcc you basically cannot sell a mcu.
<roh>
ah.. and 5V tolerance is a must for some projects.
<wpwrak>
well, sdcc is an option ... it's tolerable
<whitequark>
roh: (gcc) of course that's why we have billions of PIC8 in the world. wait, pic8 has no gcc.
<whitequark>
roh, wpwrak: almost all I/Os are 5V tolerant
<roh>
whitequark: i am not talking about boring industry projects. i am talking about creative people like here.
<wpwrak>
whitequark: 2.0 V is good. that means that you can probably use CR2032 cells
<roh>
whitequark: just stop argumenting. you cannot persuade people that way.
<whitequark>
roh: you sound like a troll, actually
<whitequark>
a bad bootloader is definitely a reason not to use a particular chip, yes
<wpwrak>
knives ! we need knives ! :)
<whitequark>
and apart from that you have not mentioned any facts.
<roh>
whitequark: i do electronics for >15 years now. i speak from experience. and the latter isnt always nice.
<whitequark>
and, through that may sound strange, I'm still interested in what do you say. For example, I will recall your words about bitbanging when I'll encounter it
<whitequark>
sure
<whitequark>
then, can you say what exactly is wrong with the io?
<whitequark>
I'm genuinely interested
<roh>
whitequark: well.. i am not interrested in aguing with you.
<roh>
and mostly: arm io is muxed. so i CAN NOT wiggle pins on 1/2 cpuclock like i can do on a avr.
<roh>
and thats only one thing.
<roh>
on ti or lpc arm i dont like the register layout because its annoying to program simple stuff with it and has lots of side-effects (and or masking which eats cycles)
<whitequark>
yeah, you've already said that, and I never argued with that. any others?
<roh>
some machines have registers for bitwise operations.. which suck again if you need some bits switching sync. which is NOT POSSIBLE on muxed/banked io.
<roh>
means .. arm CAN NOT do some of the stuff i do a lot with avr chips very easily
<roh>
the completely broken bootloader situation is the next thing.
<roh>
then you usually need multiple voltages, external clocks, complex pll boot procedures and bad documented details to get stuff working even if you get code executing... why? because manufs are really braindead when it comes to documentation and open tools.
<roh>
when i need to use a different tool to flash 2 different arm cpus from the same manuf. that manuf FAILED.
<wpwrak>
roh: btw, i have my doubts about your bit-banging argument. remember that i even got reasonably precise video out of MIPS, with caches, mmu, etc. ? i doubt arm is worse. and yes, you have to work harder than on an avr to get this right. but that's the cost of having a fast cpu.
<roh>
and that i cannot switch code from one arm cpu to another easily because every manuf used different io blocks. thats just plain stupid and breaks all portability.
<roh>
wpwrak: arm only works when you run it at siginificantly higher clocks than avr.
<whitequark>
roh: you cannot switch several bits with one I/O instruction on AVR without explicit read-modify-write
<wpwrak>
which is what you have anyway. of course, if the clock was as slow as avr, all the things needed for optimizing speed would just be obstacles
<roh>
whitequark: i can do a read-modify-write in the same time an arm on the same clock does half that on banked io.
<wpwrak>
roh: can't you just load your own boot loader into your SAM ?
<roh>
wpwrak: yes and no.
<roh>
the romloader is rom.
<roh>
nothing to flash there
<wpwrak>
and you cannot implement bootloader-like functionality in flash ?
<roh>
only if you have a part with internal flash
<whitequark>
that's just the same on avr
<wpwrak>
internal flash would seem the norm in this class of devices
<roh>
whitequark: true. but there you get fucking working tools. not broken garbage from the manuf.
<roh>
wpwrak: some try using serial flash now. also sdcards etc.
<wpwrak>
roh: are you using an atmel-provided DFU on avr ?
<roh>
and booting from such stuff works by romloader
<roh>
wpwrak: no. i do not use usb usually.
<roh>
very few of my devices get usb ports at all.
<wpwrak>
roh: which avr do you use that has no internal flash and boots from external serial flash ?
<wpwrak>
so why do you need DFU then, if you don't have USB ?
<roh>
all avr have internal flash. i was talking about arm stuff.
<roh>
wpwrak: when i get forced to use a proprietary mode via serial or usb by a manuf, i rather like a standard way like dfu.
<wpwrak>
for devices where you use an avr, would there be only arm-based choices that require external flash ?
<roh>
on avr nobody forces me to use the serial or usb. i an happily develop via isp
<roh>
isp seems to be out of the arm comfort zone nowadays...
<wpwrak>
do the SAMs have no other way of flashing than USB ?
<roh>
its either fully blown jtag with endless pins, or broken loaders.
<wpwrak>
i've heard of something called JTAG
<wpwrak>
yeah :)
<whitequark>
roh: if you do not want to look at stm32 due to your belief or anything, then fine. I have actually used chips from these series. I co-authored a FOSS flashing tool for the entire line. It does not need multiple voltages, it has internal oscillator, its PLL init is not complex and well-documented, and the docs are roughly the same quality as for AVRs. I'm curious about the real details of bitbanging stuff, so I will look into that and pos
<roh>
documentation is mostly only explaining the broken serial or usb loaders. not jtag, not speaking of working gpl toolchains to do jtag properly with affordable tools NOT supplied from the mcu vendor
<whitequark>
(flashing tool) this "flashing tool" is an in-circuit debugger, which (also) supports flashing through gdb.
<whitequark>
all FOSS, and not broken.
<lindi-_>
whitequark: your line got truncated by the evil ircd...
<wpwrak>
roh: i guess we'll have to wait and see what happens when whitequark hits the point of wanting to load his first hello.c :)
<roh>
whitequark: the point is: i am happy with avr for what i do with avr. when its 'a bigger task than the avr can handle' then one can use 2 or more avr very easily. for anything which needs a display or networking i just use a fully blown linux on a grown up arm cpu.
<roh>
whitequark: i dont see avr as 'mcu' only anymore. its 'programmable io part' for me.
<roh>
i do keyboard debouncing and preprocessing on there if neccessary. leaving the memory load heavy stuff to a real arm cpu.
<roh>
if you ask me. arm7 isnt needed anymore.
<whitequark>
roh: your approach works well until you want to make an UAV (an actual task I've attempted). you either need to stack avrs one on another, or just use a chip with hw multiplier and fast 32-bit arithmetics.
<whitequark>
and stm32 is cortex-m3 and not arm7.
<roh>
whitequark: a uav has more than one cpu core and not only a simple arm7
<roh>
or cortex m3
<roh>
from my pov thats not an improvement
<roh>
cortex m is the same as arm7 to me. not better. just new name. marketing.
<whitequark>
lindi-_: thanks
<whitequark>
that line was truncated. <...> I'm curious about the real details of bitbanging stuff, so I will look into that and post the actual result. I have not looked into serial bootloader, SWD and JTAG are standard interfaces where you have FOSS tools to work with the chip, so I won't comment on the internal boot either. SWD is 2-wire by the way.
<roh>
whitequark: so.. thanks for the links, but you CAN NOT win this by argument, simply because there is nothing to win.
<roh>
the mcu market IS full of 'duplicated usecases'
<roh>
and cortex Mx has to fight against avr. i dont need to have one win over the other.
<roh>
avr was there before and i know it quite well and whats possible with it and what not. THATS the real gain. its like the 8086 for the mcu possie.
<roh>
when we get up to processing power demands of avr32 or cortexA8, A9, the picture changes.
<whitequark>
I'm not trying to convince you that STM32 is better than AVRs (through I do state that myself), but I can't stand to see someone saying clearly false statements. (Yes, that whole "someone in internet is wrong" thing).
<lindi-_>
that reminds me, can you suggest any good software for using JTAG and ARM? I've used only openocd and it seems somewhat unfinished
<roh>
then it may be more feasible to use an arm cpu (as i would)
<lindi-_>
maybe I'd need to configure it more or something
<lindi-_>
but for example it can not read physical addresses if MMU is enabled
<roh>
whitequark: i am not saing one is better than the other. i am saying that there is more than 'i got the same features 10 years late, please all switch to arm now'
<roh>
avr killed the pic for the most part of the market here. remember that.
<lindi-_>
(sorry to hijack the thread so to speak..)
<roh>
lindi-_: openocd is it.
<whitequark>
roh: (avr killed pic) for good
<whitequark>
I heard different things about pic, through. I.e. that it still is in every small consumer device like tv remotes or car keys. Not sure about that.
<wpwrak>
lindi-_: for jtag in general, i find urjtag considerably better than openocd. but i don't know it implements the specific features you need.
<roh>
whitequark: pics are nowadays nearly extinct
<roh>
whitequark: atleast compared to avr, small arm and 8051 cores
<roh>
the latter ones having the majority afaik
<whitequark>
roh: nice to hear that. that's an arch worse than 8086.
<roh>
8051 i really not like.
<whitequark>
I was unfortunate enough to begin my mcu programming experiments with pic. it was awful.
<roh>
but its really cheap and chinese companies use it afaik without any licensing
<wpwrak>
roh: pics exinct ? you wish :)
<roh>
wpwrak: for the majority of stuff.. yes. i see >8 avrs for one pic
<roh>
and about a dozend 8051
<roh>
thats the ratio in commodity hw
<roh>
every usb device usually has atleast one 8051
<wpwrak>
yeah, 8051 still rule the world :)
<whitequark>
roh: I'm not "everyone switch to ARMs now!!111", but more "let's not ignore cortex-m3 where it's better than avr." anyway.
<lindi-_>
wpwrak: currently debugging openmoko suspend issue
<whitequark>
roh: how do you determine which cores are present in commodity hw? if we mean those small consumer devices with epoxy blobs and so on
<whitequark>
I suppose that by 8051s in USB HW you mean Cypress chips, right?
<roh>
whitequark: the reason i seems ignored is that its difficult to learn about mcu when you get confused by manufs all the time
<roh>
not in the io, not in the loaders. nothing besides the asm (and that nobody gives a shit, they all use compilers from c or higher)
<roh>
so learning about programming and hardware and mcu is much easier on avr. everything has a history and can be easily explained, is portable easily between basically ALL 8bit avr cpus from the forst at90s1200 to the lastest avr8u and similar stuff
<wpwrak>
lindi-_: phew ... may be tricky :)
<roh>
whitequark: documentation tells you a lot about included cores
<roh>
whitequark: arm is simply not used because it costs money.
<wpwrak>
lindi-_: i use jtag mainly for flashing these days. on milkymist. there, gdb runs over serial, so we don't need to use jtag for it
<lindi-_>
wpwrak: gdb over serial means you are using kgdb?
<wpwrak>
lindi-_: no, just regular gdb with a little gdb stub in the FPGA. don't know exactly how it works. but it does quite well ;-)
<whitequark>
roh: that's when you have it. may I ask what job do you have so you examine lots of such devices routinely?
<lindi-_>
wpwrak: fpga. ok that won't help me then :/
<roh>
i am a freelancer
<roh>
the job depends on the customer, but i also to custom reverse-engineering
<roh>
e.g. flash dumping for embedded devices etc
<lindi-_>
wpwrak: urjtag can not be used to single step or set breakpoints?
<whitequark>
roh: aha, I understand now
<roh>
even a usb hub has a mcu embedded ;=)
<wpwrak>
lindi-_: afaik, not easily. at least not for arm.
<roh>
also 8051 usually
<whitequark>
yeah I know
<whitequark>
8051s are everywhere
<wpwrak>
lindi-_: it's more for the boundary scan / flash / etc. kind of stuff. it can be extended, though. so there could be more features.
<whitequark>
I wonder how much of these little cores are embedded in my notebook
<whitequark>
5? 10?
<wpwrak>
lemme see if there's anything new ...
<lindi-_>
wpwrak: right.
<wpwrak>
what's nice about urjtag is that it's just one program. not some quirky client-server thing.
<roh>
whitequark: i guess a common notebook has something between 1 and 4 dozend cpus inside
<lindi-_>
wpwrak: the problem is that while gdb + openocd works it is not very elegant for debugging linux since gdb does not understand anything about linux threads for example
<whitequark>
roh: yeah, I've expected something like that
<lindi-_>
currently I have one bug where I just seem to always be in some interrupt handler if I halt the cpu at regular intervals and check where it is
<lindi-_>
and I'd love to see what the other threads are waiting for
<wpwrak>
lindi-_: a case for printk debugging ? :)
<whitequark>
roh: (learning) absolutely. I myself learned that on AVRs, and they're very good for that purpose. Then, it took me a few days to get up and running on stm32. I don't see that as a problem.
<lindi-_>
wpwrak: that's very painful :(
<whitequark>
they have quite similar peripherals and so on.
<whitequark>
lindi-_: what about kgdb? is it applicable in your case?
<wpwrak>
(urjtag) still only blackfin and xilinx (for "fancy" features)
<lindi-_>
wpwrak: not sure
<lindi-_>
wpwrak: it relies on interrupts to work at least
<roh>
whitequark: dont get me wrong.. but when sombody asks me what stuff to use for mcu and cpu on a openhw project i'll tell them avr for the small stuff, arm for the big
<lindi-_>
google has written some FIQ based debugging system afaik, that should work even when interrupts are disabled
<roh>
arm for the linux, avr for stuff like power rail management etc.
<whitequark>
roh: I understand your reasons
<roh>
simply because that way one can piggyback on a much bigger userbase which actually CAN tamper with stuff without destroying it
<roh>
didnt gta02 use fiqs also for pwm, hdq and more evil stuff?
<wpwrak>
for me it's usually a question of the hardware feature set. with the provisio that tools must be open source. very often, this narrows down your choices rather quickly.
<roh>
wpwrak: ack
<whitequark>
roh: but I'd say that if someone asks that, then he/she does not have enough experience to work with Arduino+shields on AVR and preassembled boards and peripherals from some particular vendor for ARM
<whitequark>
and it is probably the correct answer in both cases, and I'd say the same too
<roh>
question of usebase and how to intregrate people
<whitequark>
roh: if you are not learning and/or blindly copy-pasteing snippets in a fancy IDE, then the only major advantage of a big userbase is that all weird corner cases which bite you painfully are already discovered
<roh>
from my pov: when a system needs an ide to be understandable, you failed
<whitequark>
roh: that was about Arduino.
<roh>
arduino i do.. by using makefiles and vim
<whitequark>
I just don't use them--I'm fine with plain atmegas
<roh>
that way i solve my problems in a way i can have less experienced people be able to replicate my results.
<roh>
by .. well.. i dont care if they use the ide or not. they get a pde file with pinout commments
<whitequark>
I have an opinion here--that a lot of people tend to disagree with--that if you can not understand C, then you don't need embedded programming, and if you cannot draw schematics by hand, then you don't need EE
<whitequark>
(by "understanding C" I do not mean some of its worst features, but rather some very basic things like pointers and such.)
<whitequark>
because if you don't understand pointers, then a blinker is the most complex thing you can do
<whitequark>
or you may be able to successfully combine high-level blocks someone did for you, but you will utterly fail when the whole thing will stop working by some reason
<roh>
its not only about understanding. its about makeing sure people do not stand still
<whitequark>
hm?
<roh>
if you get the learning curve flat, and not too steep. everyone can do it.
<roh>
if the learning curve is very steep, only very few people will like it. the rest will be frustrated and annoyed.
<whitequark>
even if you have a flat learning curve, a huge amount of people will never actually learn more than, say, 10% of thing. at least that's my observation
<roh>
yeah. maybe. but thats 10% more than nothing
<whitequark>
they will never manage to do any of the actual work. that's what is wrong with the whole Arduino (and Python) ecosystems, I think.
<whitequark>
you've displayed that quite well
<roh>
there you are wrong
<whitequark>
if you have an arduino, then every problem seems like it needs a shield. if one arduino is not enough, then let's stack three of them
<roh>
i know people who before arduino were convinced they are too stupid for mcu and electronics, programming etc.
<roh>
but arduino made the start so easy that they developed fun hacking on stuff, even writing libs and so on.
<roh>
fun is a much better motivator than money or anything else
<roh>
especially electronics guys who can't program yet can use it as a huge booster to get started
<whitequark>
it is not bad that it lowers the barrier. it _is_ bad that it makes people think that everything in the world can be done with a certain amount of arduinos
<whitequark>
I'm not that good in hardware, so I will show you a very real example from software.
<roh>
they understand all the parts etc. but the sw barrier is lowered and removed and they can explore step by step
<roh>
somebody who thinks everything in the world can be done with a certain amount of arduinos is plain stupid. havent heard that before
<whitequark>
there's Ubuntu and it is good and stuff. And it has some of its core components written in Python, presumably because the author of them was a "Python programmer" and no one bothered to step in and stop him.
<whitequark>
and then Ubuntu work_ed_ (that was in 2009, I think they fixed that long ago. But it was so for a year or like that) way faster after I've added * * * * * killall -9 python in my crontab.
<roh>
bbl. need to run (fetch food)
<whitequark>
so with arduinos. they're an excellent learning tool -- I myself recommend them each time, but hell it is so wrong to think that world ends on arduinos, or on a particular kind of MCU used in arduino, or in a particular form-factor of Arduino shield
<whitequark>
and still this mindset is surprisingly prevalent in arduino-related world
<whitequark>
there, they go and put three avrs where one STM32 would suffice and you still will have some room (yes, that UAV. this is the project which my high school teacher currently leads. I know the hardware requirements, and I know for sure that it could fit in one STM32. And still...)
<lindi-_>
we just bought some 30 arduino mega 2560 boards and ethernet shields for to replace custom ISA cards :)
<lindi-_>
(need a lot of spares so that we can stick to this solution for the next 10-15 years)
<whitequark>
hm
<whitequark>
do you connect arduinos to ISA slots?
<whitequark>
or what?
<lindi-_>
no, the previous solution was based on ISA cards
<whitequark>
what did the ISA cards do?
<lindi-_>
now that ISA is getting quite obsolete it's time to port the system to new hardware
<whitequark>
some kind of industrial automation?
<lindi-_>
sort of, I work in a radio observatory
<lindi-_>
ADC, PWM generation, plain digital IO to hundreds of little switches here and there
<lindi-_>
we are also looking at ethercat enabled motors make everything just talk ethernet/ethercat
<whitequark>
lindi-_: if the tiny bandwidth the avr ethernet solutions provide is sufficient for you, then it's fine
<whitequark>
apart from ethernet, that's what atmel shines at
<lindi-_>
whitequark: yeah the protocol used by the ethernet shields is kind of inefficient
<lindi-_>
you need to send four bytes over SPI per every payload byte
<lindi-_>
but since everything is modular like this we might be able to upgrade in the next 10 years :)
<whitequark>
if it is not, I personally would go with this premade board (http://olimex.com/dev/stm32-p107.html, 40 euro/part, 1st link in Google. there may be better ones.) or made my custom ones. the latter would even be cheaper.
<lindi-_>
currently there's some industrial x86 box that has some PCI-ISA bridge where we see lockups when the temperature drops below 17 C
<lindi-_>
whitequark: the problem is that people need to be able to understand and debug these in the future too
<lindi-_>
whitequark: we do have a custom board that adds more accurate ADC chip to the arduino as a non-standard shield
<lindi-_>
(so we can have both ethernet shield and our ADC shield at the same time)
<whitequark>
lindi-_: it depends on the kind of people which will need to work on the system. if that's someone who has several years of experience with EE, then it will not be hard, provided you'll make all of the documentation available. if that would be a side job of someone whose main task is something sky-related, then you have a problem anyway
<lindi-_>
whitequark: as usual we are understaffed of course
<lindi-_>
the ISA cards had some PLD chips that could only be programmed by running some ancient version of windows, I think AVR is a lot better in this regard :)
<whitequark>
quite definitely
<lindi-_>
and nobody knew about version control so you never knew which version they actually ran
<whitequark>
your problem isn't within the hardware then, and it cannot be solved by different kind of hardware--only postponed
<lindi-_>
anyways, this decision was definitely not easy. we did explore many alternatives like fpgas
<whitequark>
(hides from wpwrak) fpgas are not the right thing for this imo
<lindi-_>
whitequark: I guess windows just was hostile towards version control use in the 1990s
<whitequark>
uh
<whitequark>
so it wasn't maintained for the last 10 years?
<lindi-_>
correct :)
<lindi-_>
I think there were maybe two bugfixes
<whitequark>
well, if you will hit the ceiling on ethernet bandwidth, then you will be an unfortunate example for my words. if not, you were lucky.
<lindi-_>
most of the stuff doesn't really require much bandwidth, the ADC stuff is the largest challenge but I think we did the math and benchmarks
<whitequark>
it's ethernet anyway, so if the network is heterogenous, you'll be able to replace underperforming nodes with something different
<whitequark>
if this wasn't in Science, I'd say that it is april fool's joke
<wpwrak>
i sense that there will be enormous demand for this in russia :)
<whitequark>
you sense it right
<whitequark>
unfortunately
<wpwrak>
why ? it will improve the health of the population. great reduction of back pain from carrying those heavy low-grade vodka bottles. with the graphene-enhanced high-grade vodka, the bottles will be much lighter and easier to carry around.
<wpwrak>
kinda like mobile phones got smaller with time ;-)
<whitequark>
heh.
<DocScrutinizer>
lindi-_: just do a "push *" as the first few cmds in your wd-irq
<DocScrutinizer>
this way you should get all the registers in your memory dump
Greer [Greer!~greer@gateway/tor-sasl/greer] has quit [#qi-hardware]
<DocScrutinizer>
or did I miss something?
<lindi-_>
DocScrutinizer: I have no wd irq
<DocScrutinizer>
err, what else does wd then? simple hard reset?
<lindi-_>
DocScrutinizer: reset
<DocScrutinizer>
ooomph
<lindi-_>
I think the hardware could also generate an interrupt
<lindi-_>
but interrupts are disabled according to openocd
<DocScrutinizer>
we're still talking GTA02?
<lindi-_>
yep
<DocScrutinizer>
fsckng samsung SoC
<lindi-_>
there's a task in "R" state, it is in svc mode and asm_do_IRQ gets called a few times per second
<lindi-_>
openocd unfortunately seems so incomplete that I'm not sure what to trust
<lindi-_>
DocScrutinizer: I guess it could be configured to generate an FIQ too
<lindi-_>
I guess I could put my two jtag boards to use so that I can compare both working and non-working states :)
<lindi-_>
I was assuming that IRQ handler would run in irq mode and not svc mode
<DocScrutinizer>
anyway if you got problems with GTA02 IRQ, check the rotten braindead IRQ service code
<DocScrutinizer>
it's about the most fsckdup code I've ever seen
<lindi-_>
I doubt I have the time to understand that fully
<DocScrutinizer>
enabling edge IRQ on both edges, then reading in the GPIO(!!!) to determine the current state and compare to a sored value to see what to do