Allee, u noemt Lambiek en ge spreekt geen woord buiten Nederland?
Dit topic is gesloten
Allee, u noemt Lambiek en ge spreekt geen woord buiten Nederland?
vandaag weer een kemel van jewelste afgeschoten.
maak ik vandaag men prototype om 2 voedingen + de backup accu te monitoren via een arduino, die alles zal doorcommuniceren naar de rpi server.
heel de ochtend krijg ik mijn sampling maar niet juist.
de ene meting zegt die dat de accu 2.6V heeft, erna 4.2V, dan weer 3.3V,... schommeld heen weer.
vertragingen bij gestoken, meerdere samples, code geschreven voor de uitschieters eruit te filteren, interne, externe en default regerantiespanningen gebruikt, ...
andere arduino erin en de code erin gepompt van mijn car dashboard project, andere code erin van mijn li-ion BMS programma
... alles schommeld op en neer.
en dan zag ik het.... alle massa's van de meet batterijen hangen aan elkaar (kan niet anders als ik met een arduino meet), maar had de massa van die inputs wel niet aan de massa van de arduino gehangen...
draadje erbij, alles zuiver
Special Member
Dat hoeft ook niet....
Als je een differentiaal adc hebt
Special Member
Op 12 februari 2016 15:06:15 schreef maartenbakker:
Allee, u noemt Lambiek en ge spreekt geen woord buiten Nederland?
Allee zulle, het is een straalkacheltje.
Op 30 januari 2016 00:57:57 schreef vincent1971:
https://www.youtube.com/channel/UCJ0-OtVpF0wOKEqT2Z1HEtAVolgens mij spant deze man absoluut de kroon.
Electroboom weer helemaal vergeten, heb de laatste maand het meest naar Big Clive en Louis Rossman gekeken en naar Dan Savage geluisterd (aflopend gerangschikt op electronica-inhoud en op noodzaak om tegelijk ook te kijken wat ze doen). Alle drie alsnog prettiger en vaak kundiger vertellers dan Dave Jones.
Ik had laatst een leuke op een stm32..
uint8_t aubyArray[10];
*((uint16_t*)&(aubyArray[5])) = 0;
Duurde even voordat ik doorhad waarom mijn processor in een hardfault dook...
Ik zie het niet direct, eigenlijk; je schrijft, waarschijnlijk onbedoeld, elementen 5 en 6 (adres van element 5, cast naar uint16 pointer, schrijfactie), en dat valt nog binnen de bounds van de array. Als je hetzelfde probeert met element 9 gaat het natuurlijk wel mis.
Special Member
en het duurde dan even voor ik sparky begreep met plaats 9.....
het was al laat zullen we maar zeggen...
Op 21 juni 2016 22:24:11 schreef SparkyGSX:
Als je hetzelfde probeert met element 9 gaat het natuurlijk wel mis.
Dan overschijf je een byte van een andere variabele. Maar of dat meteen mis gaat weet ik niet. Of eigenlijk dat weet ik wel. Dat gaat natuurlijk NIET meteen mis.
Ah. Ik had in m'n andere browser al iets zitten tikken over unaligned access....
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0497a/B…
Ah, dat mag blijkbaar niet, daar had ik nog niet aan gedacht. Ik snapte ook al niet hoe dat tot een hardfault zou leiden, tenzij je bij toeval ook over het einde van een RAM blok zou gaan.
Omdat een stack meestal naar beneden groeit in moderne stack implementaties, zet je vaak je stack aan de bovenkant van het RAM en de variabelen aan de onderkant. Eigenlijk is er natuurlijk niets op tegen om je variabelen tegen de bovenkant van het RAM aan te duwen en daaronder aansluitend de stack. Heb je een stack-overflow, krijg je een fault als de CPU onder begin-ram een access doet. Fijner dan "soms" een variabele overschrijven doordat je callstack soms diep is of er soms een interrupt plaatsvindt. Dus inderdaad, je kan eigenlijk nooit bij zo'n 1 byte overrun voorbij het eind van het geheugen gaan.
De grap is dat het een 32-bits microcontroller is met dus 32-bits registers. Index 5 ( net als de rest van de oneven indexen) is dus niet uitgelijnd en in dat geval moet de processor beide bytes apart benaderen... In dit geval was de compiler niet op de hoogte van mogelijke niet uitgelijnde data en ging het dus fout.
De oplossing was het gebruiken van een packed pointer, of een packed struct eroverheen leggen. Helaas kun je de data dan niet meer meegeven aan een andere functie.
Edit: Normaal gebruikt de compiler trouwens padding om al het geheugen per 4 bytes uit te lijnen (als je 3 8-bits waarden hebt, plaatst de compiler er een 4e achter). Dit kun je voorkomen met packed structs
[Bericht gewijzigd door r3dnax op donderdag 23 juni 2016 08:26:12 (18%)
de crux is dat de processor geen support voor unaligned access heeft.
Dan kan je compiler daaromheen werken. Of je OS kan een "unaligned access" handler hebben.
Als je met een struct moet werken waarbij 16 bit halve-woorden op oneven adressen staan, dan zou ik:
aubyArray[5] = aubyArray[6] = 0;
schrijven voor de code die je postte. En om de waarde er weer uit te halen:
myvar = (aubyArray[5] << 8) | aubyArray[6];
De lol is dan ook dat je niet afhankelijk bent van de byte-volgorde van je processor.
Als je dit meer dan 1x nodig hebt, schrijf je:
#define GET_SHORT(x) (((x)[0] << 8) | (x)[1])
en dan krijg je:
myvar = GET_SHORT (aubyArray+5);
Golden Member
Op 21 juni 2016 17:18:59 schreef Lambiek:
[...]
Allee zulle, het is een straalkacheltje.
Goed!!!
En ken je ook een wasmachien, een afwamachien, en een droogkast?
En ken je de functies procureur en schepene?
Golden Member
Ik moest een 2 ohm en 20mohm variabele weerstand hebben om een Milliohm meter te controleren en te justeren. Aangezien dat kreng met 2A leek wilde ik daarvoor niet een van mijn standaards gebruiken.
Geen probleem, even in de bak "lomp weerstands spul" gedoken en daar zat een ding in wat bestond uit een klosje met twee soldeerlippen en montage beugel met de opdruk 1 ohm. Dus ik haal de draad eraf en monteer hem tussen twee studs zodat verschuiven van de kelvin klemmen de waarde verandert.
Alles goed en wel, de clips op 20 mohm gezet met behulp van een 7,5 digit meter maar de Milliohm meter week mega af en bleef veranderen maar ik kon geen fout meer vinden. Alle componenten waren goed en binnen de specs. Ik pak er een tweede 7,5 digit meter bij. Die week af van de eerste, idem de andere twee 6,5 digit meters die ik daarna probeerde maar geen van alle veel terwijl een short wel gelijk..
Kom ik er uiteindelijk achter wat het probleem is. Dat klosje draad was een PTC
Buiten de deur laten bestukken of zelf de bril niet opgehad???
Opto zit ook scheef. Is voor de werking niet erg, maar kan ik niet tegen
Special Member
Hij zit niet netjes, maar zou wel moeten werken.
Ik ruik 2 opties.
.1 pick en place machine beetje de weg kwijt
.2 stagiair die niet echt kon/kritisch was
Het echte probleem is die tor die op z'n kop zit natuurlijk he..
Zoiets kan eigenlijk niet als je het met de hand gedaan zou hebben, ook niet als je alleen plaatst met de hand en daarna reflow doet (immers, je zet hem toch met z'n pootjes in de pasta hetgeen op deze manier niet lukt; dat moet toch opvallen).
Maar als het door een machinale pick-and-place gedaan is (tor ondersteboven in de tape dan neem ik aan, hoewel dat ook niet iets is dat je dagelijks ziet), dan snap ik die scheve componenten vervolgens niet. Niet alleen die opto hoor, alle andere componenten zitten ook schever dan dat je in een machinaal proces zou verwachten (zowel qua draaiing als offset).
Dus gezien die tegenstrijdigheid ben ik erg benieuwd naar het assemblageproces.
Golden Member
Een prachtige schakeling gefabriekt met ttl...
Foutje, stond op 12 volt....
componenten die er op de kop op liggen kom ik helaas vaak tegen.
Geen stagiair, meer een pick & place en vooral de eind controle die niet altijd even goed werkt.
Dit topic is gesloten